This week on the HIPAA Vault Show, we talk about the challenges that healthcare companies face when scaling their IT infrastructure, and some of the emerging technologies that are changing the way companies approach this issue.
Transcript:
Adam
Hello, and welcome to The HIPAA Vault Show, where we discuss all things HIPAA compliance in the cloud. My name is Adam Zeineddine and I’m joined today by the CTO and founder of HIPAA Vault, Gil Vidals. Hey, Gil.
Gil
Hey. I’m looking forward to another podcast with you.
Adam
Absolutely. So last week we talked about data retention for HIPAA. What kind of data needs to be retained for HIPAA? How long does it need to be retained? This week, we’re going to talk about cloud architecting for HIPAA. Before we get started, please like, share and subscribe to this for more HIPAA cloud related content. As healthcare businesses grow, their websites and applications get more complex and in demand. One of the most important things for any modern organization is its application servers. These servers are responsible for running the software that keeps businesses running smoothly, whether it’s internal processes such as electronic medical record systems or external websites and patient portals. However, as more people start using applications and the data volume increases, these servers can get overloaded, and this can lead to performance issues and even downtime.
Adam
To avoid these problems, it’s crucial for organizations to scale their It infrastructure. But this can be quite challenging, especially when dealing with healthcare applications that require compliance. So it’s important to be prepared and have a plan to ensure that everything runs smoothly as the business grows. Gil, what are some of the common challenges that companies face when scaling their It infrastructure? And maybe how can they overcome them?
Gil
Yeah, this is a great topic. Thanks for bringing this up. It is challenging. Scaling is challenging because it has to do with timing. So you have an application, it’s something that the company spent time developing, and the application is running It’s, generating revenue. Things seem to be going well, and then there are occasions where they say, well, things are slowing down. And then you see the business is growing, they’re getting more visitors, more customers using the application. And typically what I see happening is, oh, let’s just throw some more hardware at some rancid view. So the challenge is to properly scope out the scalability. Like, when do I need to scale up? Do I just add more hardware? I mean, at what point do I have a good architecture? At what point do I have a bad architecture?
Gil
So at a high level, the challenge is to develop an architecture that can scale as the demands grow.
Adam
Interesting. Yeah, and I think one of those key points is, like, how can companies determine or know when they’re facing that challenge? Specifically, do you have any kind of best practices on determining when they have an It challenge and maybe some ways to deal with that effectively?
Gil
Yeah, I think KPI is a good buzzword, the key performance indicator for your application. So it’d be good if you kept a record of how many visitors you have per month. And of course, there are tools that can automatically record that information for you, but review that information once a month and say, hey, in January we had 1000 visitors and now it’s February and we have maybe 900 visitors actually went down. Or you’re lucky. In March you had 3000 visitors. So you’re paying attention to that. You’re knowledgeable, you know, and you’re able to then say, well, our application at this level seems to be functioning well. But then you could do a trendline. You can see, hey, we’re growing at this rate. And then you can think to yourself what’s going to happen next year, january of next year.
Gil
You might say, oh my gosh, we’ve tripled our visitor count. And unfortunately, what I see happening all too often, Adam, is that not necessarily just our customers, but in the industry in general, everybody’s busy. Their owners of companies are very busy and they don’t give enough mind share to planning. So what happens is they come like the house is on fire and say, oh my gosh, I just closed a new customer. I’m going to have 10,000 more visitors next Friday. And you’re like, well, good luck with that because your architecture is going to collapse. It’s not structured to handle that load and so it’s a big surprise. And that’s because there’s no planning. So it’s better to plan it out and think, how do I evolve my architecture to handle the load as it grows and how can I do that? Affordably, right?
Gil
It’s always a challenge because if you had all the money in the world, then who cares? But you don’t. So you have to really think hard about how to do that.
Adam
Okay. And you touched on planning is key to face and overcome these challenges. Best plans in the world. Could you talk a little bit about with having the plan, what the key distinctions are? And I’m asking this question because I know you have a lot of experience with both more traditional server setups that are maybe in private data center somewhere and then also, as is becoming more recent, cloud based server architecture and architecting projects for clients that are cloud based. Could you share a little bit about your insights, maybe in terms of your past history, what you found the drawbacks or benefits of each would be and why? We’re very much moving onto the cloud side of things.
Gil
Yeah, I think if I had to give you one word, it would be flexible or elastic. So in the old world, if we go back many years ago, everything was rigid, right? You bought literally a piece of metal or chassis and you have CPU Ram and you assembled it. We used to assemble those and put them in a rack and boy, that was client X. There they are. Well, this is rigid. Literally, if they want more Ram, you got to ship it in and physically pull it out, put in. So everything started very rigid. Now you go to the other extreme where we are today. And there’s none of this stuff about hardware. It’s all in the cloud. You want more Ram, you hit a button and boom, it’s there. You want more CPU, boom it’s there at a cost.
Gil
But I mean, it’s easy if you need disk space, it just grows infinitely. So flexibility is on this side, rigidity is on this side. In general, if you’re wanting to be more flexible so that you can evolve, then that’s newer technology. And typically, again, generally speaking, that costs more. That costs more. So the more flexible you want to be. So an example would be if you want a virtual machine that’s just rigid is sitting there in the cloud, you could pay a certain cost and you say, hey, I know what my costs are. But then if you say, well wait a minute, we want to scale for an event. Let’s say you’re having a huge event, you’re going to have all these visitors, you want to scale, well, then you need something sophisticated like containerized clusters using Kubernetes, very fancy buzwords, but that’ll scale.
Gil
And then it’ll actually scale down automatically. Auto scaling, but all that comes at a price. All that sexy technology comes at a price. But really, in summary, I’d say that’s the key thing in today’s world. We have this unbelievable flexibility. We’re elastic with the demand and that is a great thing. If it’s architected properly, then it’s a great thing.
Adam
Important points there. And I think on the cost front, maybe you pay more per hour on the cloud, but you don’t have to use 24 7365 of those hours. So there is a good way to manage the cost there. So, technology wise, what are some emerging technologies or trends that are changing the way companies approach this kind of scaling and architecting for success in the cloud.
Gil
Technology wise? Well, this is new to our audience, but it’s not necessarily new to the industry. But having what’s called the CI CD pipeline, the continuous integration, continuous development, that is another buzzword that you can talk a lot about, but essentially that boils down to a much more efficient way, less of a headache to have developers coding, making incremental changes and checking them into their source code and then deploying that. So in the old days that was much more laborious and a lot more coordination between a whole bunch of developers and choose the day that you want to push your production code, a new version, 1.0 and so on. But now with CI CD, you can push code out small incremental changes very rapidly and very elegantly. So that’s a big one.
Gil
As far as technology goes, kubernetes been around for a while, but Kubernetes is very sexy. And auto scaling, all of it’s complicated. So now, especially in Google, there are tools that can be used that put most of the hard and challenging parts of Kubernetes on autopilot so that you don’t have to make all these decisions, it automatically does a lot of the work for you so you can focus more on just deploying your container. And that’s the other thing I want to mention, is containerizing an application is really a key thing. Once you containerize your application, what’s the container? Okay, the container is really a static image of your application. So if you have your application, the code is written, it’s sitting there. If you containerize it means that it’s still your code, it’s still your application, but it’s cloned from a golden image.
Gil
So you have your server, everything’s tested and running. You take that, you make an image copy, you put it in a container. And the reason that’s different than a virtual machine is that a virtual machine, if it breaks, like your car, if your car breaks, you’re going to fix it. You typically don’t break your car, go, I’m going to go buy a new one. Nobody does. They go fix it. It’s too expensive to go buy a new one every time it breaks. But a container is different. A container is, hey, my car is broken. Here’s a new one. Oh, my car broke again. Okay, here’s a new one. And it’s like, by the way, the cost is almost zero. You’re like, wait, did I get a new car for free? Yeah, that’s right. So that’s what the containers do.
Gil
It’s a clone of your application. And every time it breaks or if it does break or gets an attack, you just push out a new one, brand new one. Just push it out. So I think that gives the audience some semblance of that. But scaling is really important for those entrepreneurs that have written an application that seems to be growing and they want to scale. If you have a small application that has a set user base that seems static, then you don’t really need to be all concerned about scaling. So I would say keep an eye on your user base. Like, how fast are you growing? Or maybe you’re not growing in some cases. We have some customers that have been shrinking because in one case, we had an older gentleman. He didn’t want to be that busy.
Gil
He was like, happy to have a smaller footprint. And so he was letting some customers go or selling part of his business. I don’t remember the detail, but he was actually shrinking well known patients.
Gil
He was just keeping it steady, and he was very happy with that. So think about what your demand is on your application. What’s the demand? And also another dimension that you could say for another podcast, but also what’s your recovery time objective? Like, how long can you afford to be down? Because in technology, something breaks all the time, right? We can’t pretend that technology doesn’t break. We know it’s going to break. So how long can you be down? And that’s part of your scaling and part of your it kind of goes hand in hand. The technology of scaling is also melted or melded together with business recovery. If you want to recover quickly, then you want to design the architecture so if something goes wrong, you can recover rapidly. And so those are some more thoughts there on how to do that correctly.
Gil
I welcome the audience. If they want to meet with us or engineers, we can sit down and whiteboard a solution for them if they’re looking for that. And we can architect something that would meet their budget so it’s affordable and also so it’s scalable and so it also meets their recovery time objective.
Adam
Great. Yeah. And I think I’d echo the point that we could go a lot further on this. Maybe we should save it for another podcast. But are there any other touch points that you’d like to talk about on this show in particular?
Gil
Yeah, I watch a lot of podcasts and I like the ones where I have a takeaway, like something I can actually do myself. And so a lot of our audience is non technical with technical and non technical, but either way I like to have that. So you have something you can actually do. So we already mentioned one thing, right? We’re keep an eye every month on your visitor count using Google Analytics most of the world uses. So make sure that you log in, you as the owner, don’t just get a report from your marketing team, you log in yourself. It’s not hard to do and look at the report every month. So that’s a good idea.
Gil
The other thing is I would spend a little time as an owner who’s not technical, reading a little bit more about this whole idea of agile development and CICD continuous integration. Continuous development, I would read a little bit about that. From a manager’s point of view, it’s not good. When we talk to owners, managers, when they say, oh yeah, I don’t know anything about that. You have to talk to my tech guy. It’s like, well, I get it, that’s their world, this is your world. But in leadership, you still have to know enough to be dangerous enough to understand the concepts so that you can make good decisions, right? If you don’t know anything, then how are you going to make a decision?
Gil
So I would spend a little bit of time learning about that so that when we talk about these buzwords and architecting, you’re like, okay, I understand generally how that works and then you can take advantage of it. When you understand something, you’re more comfortable with it. Typically you’re not scared and you’re willing to try it and you’re willing to go in that direction. But if it’s something completely foreign and it’s like, oh, that’s just for the tech nerds, then I feel that it’s not going to go so well because leadership needs to buy into it, needs to understand it absolutely.
Adam
Well, I think we’ve covered a fair amount there. We’ll leave the viewers and listeners to soak that in Gil, like you said, I’d like to echo that if you have any questions, feel free to reach out to us at hipaavault.com, whether it’s regarding some challenges that you’re facing with scaling or anything else to do with HIPAA compliance in the cloud, you can also email us at podcast@hipavault.com or tweet us at @hipaahosting. And other than that, make sure, please, to subscribe and leave us a review if you enjoyed the episode. And until next time, thanks for stopping by.