1: Out of the Datacenter and into the Cloud Artwork

Runtime Arguments

Conversations about technology between two friends who disagree on plenty, and agree on plenty more.

Runtime Arguments

1: Out of the Datacenter and into the Cloud

May 03, 2025 • Jim McQuillan & Wolf • Episode 1

Have you thought about moving your computing into the Cloud?

This episode takes a look at a real-world adventure that Jim went through when moving his computing infrastructure from purchased servers in a rented rack in a datacenter to a VM Running in a cloud service provider using Docker, Linux, managed PostgreSQL. He covers the steps he took to get there, how it's going, the good stuff and the challenges in making it work.

Show notes:

Cloud service providers:

Technologies used:

Hosts:

Jim McQuillan can be reached at jam@RuntimeArguments.fm
Wolf can be reached at wolf@RuntimeArguments.fm

Dawn by nuer self, from the album Digital Sky

Wolf: 0:05

Howdy everybody and welcome to another episode of Runtime Arguments with Jim and Wolf. I'm Wolf. And I'm Jim. Um we're still figuring this whole thing out. Um, but we're both uh software engineers, we're friends, we talk about stuff, um we're going to present to you topics that we're very interested in, or that we've done, or that users have sent to us and that we care about. Um sometimes uh it'll be stuff that we'll have to research, sometimes it'll be stuff we actually have experience in, and our plan is that uh we'll alternate back and forth. Each week, one of us will be the one who does the research or talks about their experience. Um last week I talked about past keys, and this week Jim is gonna talk about his transition from a data center into the cloud. Um I uh I I I think I'm just gonna hand it over to Jim. Jim?

Jim: 1:17

Thanks, Wolf. Uh this episode we're gonna talk about, like Wolf said, my the transition of uh my business from a data center into the cloud. Uh a little bit of background. Back in 2012, I've got a small company. There's only uh three developers and another uh administrative person. Uh back in 2012, we were running, we had an office. We had real office space, uh, and we were all working there. Uh but uh we the rent was going up, and we had decided we could uh go go virtual. So we rented space in a data center not too far from us, uh, put some computers in that data center, and each of us just worked from home. And it worked really, really well. You know, in 2020 when when COVID hit and everybody went virtual, we had been doing it for eight years. And and uh so we were we were pros at it at that point. But uh we were doing the data center thing, uh renting uh some rack space, paying for bandwidth and power, and and uh we put our own computers in there. Uh and we we had three servers. Over the years we had various servers, and every time a server would go out of warranty, we'd buy a new server and uh demote the old server, uh take it out of out of rotation. Um but it uh come uh just a couple of years ago when uh rent was gonna go up on the data center, uh we decided we didn't want to pay that kind of rent anymore, and we we also didn't like the the uh the the responsibility of having our own hardware, being responsible for our own hardware. If there were a hardware failure, uh we were on the hook for it, right? We would have to um we were using Dell servers, we'd have to get somebody from Dell in into the data center to replace whatever failed or have them ship us a hard drive if we had a hard drive failure. And really over the years we had very, very few failures. I think we lost two hard drives and a power supply in the entire time. But you know, hardware failures don't happen when it's convenient, uh, they happen when they want to happen, usually when it's least convenient time. When I'm out of town or somebody else is out of town, or the customer is is trying to get some work done. You don't want a hardware failure. So we decided we were gonna get away from that. So three years ago, we signed our last lease for the data center. Uh it was a three-year lease, so we'd get a decent rate, and that gave us three years to engineer a plan to get out. Um we were pretty sure we wanted to go into the cloud. Uh basically another data center, just not our data center, not our hardware. Uh so three years ago, we decided we were gonna go to the cloud. So we started uh uh trying different things. We had uh we had been using Docker for a few little things, so we were very familiar with it. Uh we hadn't really deployed it much in production, but we we kind of knew how it worked. Uh and we're a Linux shop, everything we do is run it in Linux. Um so uh we we we started working towards Docker for everything. Um our our our our situation was we had three servers, one of them was running Postgres. That's all it did. It ran Postgres. Lots of memory, lots of CPU, lots of fast disk. It just ran the Postgres database. The other two servers were both running VMware ESXi. Um we weren't clustering them, we just had two VMware servers, uh, each of them running uh a dozen or so virtual machines. Um and that worked pretty well. It was really nice to spin up a virtual machine to to you know try out a new version of Linux, to load some new software, to give it a try, and when we're all done, we could just throw it away. It was a really nice, simple way to do things. Um we we the way we run our business, we have customers who have their own systems, their own data center, and we have customers that we managed their their servers for them in our data center. And when I say servers, I mean a VM. The the customer would run on a VM, and that VM would be Linux, and it would be running Apache, and it would be running Node.js and uh several other things. Cron jobs would run, mail would run, all that kind of stuff. So we decided we were going to Dockerize all of that stuff, all the stuff that we ran locally. Our customers who run their own servers, they would continue to run their own servers.

Wolf: 6:08

Um can I can I interrupt you for a second? Certainly. So you talked about having a ton of VMs. Yeah. Um sounded like you you said a dozen on each of your two uh VMware uh boxes. Yes. Uh and then you started talking about Docker. Um what exactly is the difference between Docker and a VM?

Jim: 6:34

Great question. Um I I I think of it as uh a virtual machine is uh uh a whole instance of Linux with the kernel, with with uh uh disk space reserved for it, with uh an IP address, and uh it's just it's it's like having a whole box uh running Linux with a kernel. Docker is not that. Docker is a a uh a collection of things, libraries, uh scripts, um uh programs, all of the things, but not a kernel. Uh Docker containers use the kernel of the host. They all interact with the one kernel that's running on the host. Now, there's ways to run Docker where you do need a kernel, and that would be like if you wanted to run Linux, a Linux Docker container on a Mac OS host. Uh in that case, you're gonna run some virtual machine like VirtualBox, and you're gonna run a Linux uh kernel, and then your Docker container is gonna connect to that. But if you're running Docker Linux Docker containers on a Linux server, there's only one kernel running. So it's much lighter weight than uh than a virtual machine. Is that does that help answer your question?

Wolf: 8:03

I think that tells me what I need to know. Um but while I've interrupted you already, I have another question, and that is um there's a lot of compute power differences between a data center of your own where where you control how much hardware you have, and uh maybe there's a negotiation between you and the data center to control how much bandwidth you have. Uh and it's a totally different deal in the cloud, of which I'm sure you'll explain to us. Uh but my question is, in your data center, was there more than just cost driving you to the cloud? Uh was there something else about the data center that wasn't good enough? Uh were you bumping up against limits? Uh were there too many VMs? Uh what was what else drove you, if anything?

Jim: 8:59

Uh the hardware we had could easily run a lot more virtual machines. We could have we overspecked the hardware. We we we could have run a lot more than we did. Um the biggest thing though really was the responsibility for running our own hardware. For uh, you know, worrying about hardware failures. I I didn't want to do that anymore. I just didn't want to be the guy that has to run down to the data center and swap out a hard drive or a power supply. We we always ran redundant, you know, we had RAID uh uh disk systems, we had redundant power supplies, everything we had was redundant. But, you know, we just didn't want that. And the, you know, the longer you go, the greater your chances of having some failure that's gonna take down the server.

Wolf: 9:45

I hear you. I uh I personally really like my sleep.

Jim: 9:50

Yes. Yes, because like I said, failures never happen at a convenient time, right? So uh so that's that was the the biggest driving force. Plus, I felt like we were paying too much for that data center. It at the time you know what that we started doing it, it seemed like a great idea. We'd have plenty of room to grow, but you know, we've been in business for a long time. We're not growing that quickly. It's a pretty stable business for us. Turns out we didn't need that kind of horsepower to run our business and to satisfy our customers. So we we decided data center really wasn't the model that was gonna work for us. Does that cover it? It does. Alright, so I I said we had like a dozen VMs running on the two uh servers. Uh not all those things were business critical things. We had lots of lots lots of extra virtual machines running. Uh but primarily uh what we had that we did have to keep running. We we had an asterisk server running our phone system, we had we were using request tracker to handle support issues, we had development servers, uh, we had uh two customers running. We'll we'll just call them customer A and customer B. Uh we had our corporate website, uh, had a Nagios server running to monitor all the other servers. Uh we had our own internal wiki uh utility server for just handling things like relaying uh email, you know, an SMTP server that would just forward uh we we run our mail through Gmail. We have one of those uh uh Gmail actually hosts our domain uh for email. And we had a server that just had to forward that stuff out to there. Uh we had a backup server on each VM so that each VM would would backup all of the VMs. You know, so so uh the backup server on each server uh we basically had two backups of everything, right? Plus, I I've got a small server here at home that was also connected up to the data center through a VM or through a uh VPN, and that was running a backup server. So we were plenty well backed up. Um uh and then of course, you know, the third server was running Postgres. Um and we were doing replication of Postgres, uh streaming replication. So we had a virtual machine running Postgres on each of those two servers that was also replicating the database, and I had a VM back here at home running Postgres, replicating the database. So we were well covered for backing up the database.

Wolf: 12:37

Uh a man after my own heart.

Jim: 12:40

Yeah, yeah. We were you know paranoid. The last thing I want to lose is is a customer's data. You just don't want to do that, right? And uh, you know, people people think, you know, well, if it's if it's got replication, you don't need to back it up, right? Well, yeah, you still need to back up your database. So we we had a mechanism set up to to dump the database. And along with replication in in Postgres streaming replication, you also have log file generation. So we were doing a weekly backup of the database and then backing up every log file. And and these aren't these aren't like log files that you would analyze for problems, these are database transaction log files. So we backed up those as they happened. So every every few minutes uh uh another transaction log file, a wall file would would uh would get backed up. So we we were well backed up. So that was that was pretty good. In 2022, that's when we made the decision we were gonna sign the three-year lease, um, and and then figure out how to how to move out. Um before we actually went to the cloud, we we built uh we engineered all of our Docker stuff uh on one of our own VMs. I built a virtual machine, I allocated four CPUs to it, 16 gigs of RAM, um and enough disk space to do this. It doesn't take a great deal of disk space to for these Docker containers. Um but I set up a single virtual machine to run all of our stuff as Docker containers. And it took us, I don't know, about eight months to get uh all of our services moved over to Docker containers. So I think around January of this year, I actually had our entire environment running in Docker on a single uh VM.

Wolf: 14:45

Let me let me make sure I understand this. Yeah. Uh my understanding of Docker, uh, which is a little limited because I don't use it myself, but my understanding is one Docker container is one service. You're usually running one main program on that. And what you're saying is all of those services that you named before, everything you were talking about, which seemed like an awful lot to me, uh, they were each one their own Docker container, and you were running this all on one four CPU 16 gigabyte um VM. That all fit in there.

Jim: 15:28

That's right. That's right. Uh we we did it kind of, you know, we we we started, you know, moving one one of our services over to Docker, and that ran pretty well. And we moved another one over to Docker. And you know, like Wolf said, uh each service is uh is a separate Docker container. So what we did, like uh we use Apache. So Apache ran in a Docker container. That was all that ran. Um we had cron jobs, or we we have cron jobs, things that have to run in the evening or during the day or or whatever. So we set up a Docker container just to run cron. Um we have print services. Um our customers like to print to their printers. Um so we have cups running in a print in a Docker container to handle print jobs. Uh that cups server, uh there's there's some of our software on that as well that that runs uh a daemon that reads the database, sees uh jobs that need to be printed, and then feeds it off to the cup server. And then through a VPN back to our clients, uh they end up on their printer. Um so yeah. Around January, we finished moving everything to Docker. Uh it turned out we had 18 Docker containers running. Now, if you do the math, it doesn't fit, right? Because we had two two VMware servers with a dozen virtual machines on each one. There was a lot of those servers that just weren't doing anything important. Uh so we we didn't do that. And our development machines uh didn't weren't weren't part of that. Uh for development, we just brought development uh uh into our own uh our own homes. Uh I I run my development here at home. Uh my other two guys, they run their development on their hardware sitting on their desk. Um so where it used to be in the data center, now it's local. Uh we did not move that to the cloud.

Wolf: 17:32

Uh but we ended up with change your development style. Um if your old development environments were in the data center, that sounds like you were um VPNing into those boxes and then probably editing with some terminal editor like Vim uh and and working on uh repos that were there, but now you're working in your on on hardware in your own office? Yes. Did that change?

Jim: 18:05

Well, for me it didn't change that much. There's a there's a few things that obviously did change. One of the things we're really, really aware of is we're in the medical business. We write software for doctors. I'm very, very sensitive to the fact that uh we have uh patient information in our database. We run uh in the data center, our database uh existed on an encrypted file system. And one of the requirements for HIPAA uh when you're dealing with PHI is you have to uh uh data at rest needs to be encrypted. So our backups were encrypted, our file systems were encrypted, so the database was uh running on an encrypted file system. Uh if somebody, if we shut down the disk, uh shut down the server and somebody swiped a hard drive, they wouldn't be able to get anything out of it because it was really strong encryption. Uh so you know, we made sure we had we were like I said, we're sensitive to that. I didn't want to bring any patient information into our homes. I didn't uh you know I I I I trust my guys, but I didn't want you know uh somebody breaking into their house and making off with their with their computer or my computer. So we we we have a firm policy now. The development that we do in our own homes, there's no PHI. We have we we developed some tools to dump our database and strip it of all patient information. There's an awful lot of configuration information in our system, uh, but we s we wipe out any patient information. So we're dealing with much smaller databases now. Because, you know, like like our our our big customer, the database is three and a half terabytes. Uh strip out all of that PM. And it's like 120 gigabytes of stuff. Yeah. Get rid of all that patient information, that pesky patient information, right? So it presents a challenge. When we're doing real testing, now uh when it deals with PHI, like uh most of our development is done for for one of our customers. They have their own data center. So when we get around to testing, we do it on their server where they have PHI, and they're responsible for the privacy, protection of the of the private data. So that changed. I still use Vim. I SSH to I've got a little box here. I SSH to it. That's how I do my editing and and developing. Uh the other two guys, they're they're a lot more progressive than I am. They'll use like uh desktop editors, uh, VS Code or or whatever. Um so they're you know, they're doing it the new way. So it changed for them. You know, they couldn't really do that very easily before when the data when the source code was remote. Um there's ways to do it, but they they didn't. And now they are. They're both using uh uh much much uh I don't want to say more modern editors because I think Vim is is is fine, but uh they're they're using the um more full featured editors. Um so that changed for them. IDEs, yeah. They're they're they're doing that kind of stuff. Uh I I haven't switched to that yet. Um so anyway, where was I? I uh uh we had our basically our entire business running uh in 18 Docker containers on on a single VM. And like I said, that VM was uh uh four C I had allocated four CPUs, 16 gigs of RAM. Um that's not a very big server. But what we found was and we were in production with this server. We our customers were were using that. Our website was there, our wiki, our our uh uh um uh tracker software was all there, and it was running just fine. Every bit as fast as it used to be. Nobody noticed a thing. Um so we were pretty happy with that, so we thought let's see how small we can go. So I cut that in half. I went down to a small VM with two CPUs and eight gigs of RAM, and it still ran fine. So, okay, now we've kind of figured out what size we need when when we go to the cloud. Um, so uh uh we moved to the cloud. I uh I chose Azure as our cloud provider. Um not because it was any better technically than AWS or or Google Cloud Services. I had some experience with Azure with another client that I had. They were running some stuff in Azure. So I had some real experience there. I knew the the portal, I knew the command line, uh the CLI utilities for dealing with it. So I chose that. I I looked at AWS, I I had some experience with AWS as well, but my most recent experience was really with Azure.

Wolf: 23:16

Um I think you've just answered the the next question I was gonna ask. Okay. Uh, which is why did you pick Azure? It sounds like you just told me why.

Jim: 23:27

Familiarity. Yeah.

Wolf: 23:29

What I want to know is uh if Azure turns out not to be the right thing, are you set up so you can switch?

Jim: 23:38

Yeah, we really are. Um at first when I was looking at at Azure, they have a hosted Postgres solution. They will manage Postgres for me. Um I I've been using Postgres since, gosh, I don't know, 2000, maybe maybe before. So I've been using Postgres for like 25 years, so I don't have a problem managing Postgres, but they would manage it for me, they would manage the replication. Well, that's pretty good. Uh and I looked at um AWS, they also have a hosted Postgres solution, and they have something called Aurora, which is Postgres compatible, and that that worried me. I I wanted Postgres, not Postgres compatible. Uh I I I've since looked at it again, and they do have Postgres for RDS or RDS for Postgres, which is basically what Azure is doing. So that's really kind of the same. But their price was just a little bit higher for the database than Azure was. I I'm talking like 10% higher, not Showstopper higher. But again, uh I had the familiarity with Azure, so I I I went with Azure. You know, use what you're familiar with if you if you want to guarantee you're you're gonna have success. So yeah, we chose Azure. Um I I I built up a uh a little environment in Azure. I created a virtual machine, two CPUs, eight gigs of RAM. Um it comes with like 30 gigs of disk space, I think, which is way more than enough for what we're doing. Uh, and then I went with the Azure uh uh managed Postgres. We uh told our customers we were gonna be down on a Saturday, and we pushed the data. Uh we we we we had to dump the data from our database and upload it to the Azure uh Postgres database. Did that, um started up the VMs, configured the Docker stuff, um, started up I uh we use HAProxy to handle the to terminate the SSL uh endpoints, uh to handle the multiples domains. Um so we set up HAProxy and you know several other little things. Fired it all up, and it it really came up very easily. Very little tweaking had to be done because we'd already gone through it in our own test server. We we knew what we needed. Um there's not a lot of software installed on on the Linux box, the the VM, other than Docker, which loads everything else. Um we we fired it up, did a whole bunch of testing to make sure it was okay, and uh made it live, put it into production, pointed DNS at the new server.

Wolf: 26:39

You're at the point in the story where if it was me, I I would be afraid. And the thing I'm afraid of is I I've heard good things and I've heard bad things about the cloud. I hear these scary stories about uh starting a job and never remembering to stop it and costs going out of control and the cloud not ending up being cheaper than what you were on before. Right. So my question for you at this scary point in the story is um did you know right then, when did you know what you would be paying, and when did you know this was a right a good decision? Um and and can you tell us anything about costs?

Jim: 27:28

Well, well, yeah, the the the thing about the cloud is you can't get a straight answer of what it's gonna cost you. Right? You can you can look on the on the price list for the hardware, and you know, is that the only cost there's gonna be? You know, you set up a VM. Uh uh I'll tell you what, a s a small VM on Azure, uh, two CPUs, eight gigs of RAM, 30 gigs of disk, um you know, it's gonna cost you 70 bucks a month, something like that. Um that doesn't seem so bad. Um maybe 80 bucks a month, uh something like that. Um so that didn't seem too bad. But then it's like, well, you know, are they gonna charge me for throughput for data? You know, uh for data in and out of the server? How much data do I pass? How much how much data do our customers you know suck down from our system? We didn't really have good numbers on that stuff, and I you can't really understand uh uh the cloud provider's cost structure for that kind of stuff. Um so at that point, you know, this is really now March 1st is is when we went live. Um we just kind of had to say, all right, let's do this for a month. We hadn't pulled the plug on the data center yet. We uh uh really May 1st, in fact, right now, uh is when our uh lease was up on the data center. We wanted to get into the cloud with plenty of time to change our mind. Um so really, March 1st, we went live in the cloud, and uh believe me, I I was watching the the uh cost every day. Um at least with Azure, it does a pretty good job of showing you uh what you're you know how much you've consumed so far and it how much it's costing you so far and what the projected cost is gonna be. And I watched that thing every day, and I was really surprised it followed exactly what I had computed. Like within$2 of what I had expected it to cost is what the what the cost was at the end of March. I was I was really happy. And then April, the same thing. Our costs are, you know, April's only got 30 days, so it was uh a little bit cheaper for April than it was in March. Um uh our uh so our costs were really good. And and it turns out that the way we set it up, uh our cost is just about half of what we were paying at the data center.

Wolf: 30:05

That sounds fantastic.

Jim: 30:06

Yeah, I was I would have done it if the cost was the same. In fact, you know, for the ease of mind or the the peace of mind of not having to worry about my own hardware, I could have handled it if it was slightly more expensive.

Wolf: 30:22

And you and you're just talking about the monthly cost. Exactly. You're not even talking about the hardware.

Jim: 30:28

Right. I'm talking about our our our monthly payment to the data center versus our monthly payment to Azure is just about half. Within a few dollars of half the price. That doesn't count for the hardware investment that we had had. You know, we were buying new hardware every three or four years. We were buying a new server, retiring an old server, and for the other two servers we were paying for for uh service contracts for them. That costs real money. Um uh you don't think about it because you're not paying that bill every month. But if you look at your costs over a couple of year period, that's some serious money. Uh and it turns out, you know, I said we our our monthly costs were half of what they used to be in the data center. When you factor in the cost of our hardware and service contracts, our cost is about a third of what it used to be. Because we don't have to pay for service contracts or hardware uh at Azure. They take care of all that stuff. So, yeah, we were really, really happy that uh our costs are are much less. That's that's tangible. That's you know, that's something you see every month, and I'm and I'm really happy about that.

Wolf: 31:39

All right. I have an unrelated question, but it's very important to me, and you'll see why, because we're friends and you know me. You spent a lot of time talking about all the backups that you made. So my question to you is in the cloud, how do you do that? Is it this wh what do you do?

Jim: 32:02

Okay, in the cloud, uh Azure has a backup solution. We're paying for them to back up our our server. Um also, like I said, we're doing a managed Postgres installation or instance, and they are handling replication. So our database is replicated. And with that managed solution, they back up the data. So we can we can do res you know that we can pick restore points and stuff if we ever had to restore the data. If a server, if the database server ever failed, it would automatically switch over to the to the replicated server, and then magically, automatically, uh they would start up a new replica. And and uh so it would always be replicated, always be backed up. So they're handling that for us. Now, our we don't have a lot of data stored on the on the server, on the VM. Our configuration, you know, it's a bunch of Docker uh uh uh uh Docker Compose files uh for starting up the the Docker containers. Uh there's some configuration for HAProxy, there's some configuration for a few things. Um that's getting backed up constantly. Uh many times a day that's being backed up, uh, but it never changes. Uh we also store all of our configuration in uh GitHub, in a GitHub repo. So we have that. You know, we make a change and we'll we'll we'll commit it and push it up to GitHub. So all of our configuration is backed up really, really well. Um that means that should we have a hardware failure at Azure, should the the the the somehow they just crap out, it would be fairly simple for us to build another VM and you know do a get pull uh to pull all of our configuration. And away we go. Maybe some IP addresses would have to change, but that's that's it. That's that's really simple. Um does that answer your question? How we handle that?

Wolf: 34:16

I think it does. I I just want to uh put in there I'm so glad to hear that your uh configurations are all in git. Just hearing that makes me happy.

Jim: 34:29

Now, I had said we we chose Azure, uh and we could have chosen AWS. Uh the way we've done this now, the only thing we're taking advantage of from uh Azure is they're hosting our Postgres database. AWS can host a Postgres database. Um if we wanted to move to AWS, basically go to AWS, build a VM of similar specs, uh set up Git, do a Git pull. Uh it pulls down all of our configuration. Uh I'll bet in 30 minutes we could be back up and running, aside from the time to copy the data to the uh database uh uh on AWS. We could move to AWS really easily. And the same for for uh Google Cloud Services. I I haven't even looked at Google to see how they handle Postgres, but I'm sure there's a Postgres solution on Google. Um so you know it turns out we're running uh two CPUs, eight gigs of RAM, and when I when I look at the stats on that thing, you know, you can you can see the statistics of of what's happening. Um we are using 25% of the RAM and about 5% of the CPU. So that machine, that that two CPU uh uh VM is turns out it's overkill. We could go smaller. I don't really want to go, you know, the next choice is one CPU, four gigs of RAM. I don't want to go that small. I like having a little bit of overhead. So overall it's working great. I I I will tell you about it uh some annoyances though. Uh things that we learned in doing this, we overcame it, but uh what we did have to learn. When you set up a virtual machine, or when you set up anything in the cloud, you pick a region. Uh we picked uh uh for our VM, we picked US East. It's somewhere in Virginia as our region. So I set up the VM, and then I've got to set up the database, and I didn't really notice, but when I created the database, it allocated it in US East 2. That's a different data center than US East. I I believe they're both in Virginia, they're probably across the street from each other. They might even be in the same building, but they're they're not the same data center. So what we had was our our services were running on in one region, and our database was running in another region. It caused some latency in the database. Uh it just wasn't as fast as it seemed like it should be. Uh and I learned this after two days. Uh uh figured that out. So I thought, well, that's okay. I'll just I'll just create a new database in US East. Well, Azure currently isn't allowing you to create Postgres databases in US East. Apparently they're they've got enough databases in US East. The only choice was US East 2. So I couldn't move the database to US East, I had to move my VMs to US East 2. So if you're gonna play this game, if you're gonna if you're gonna go to the cloud, watch out where your where where your region is. Um, you know, I I could have I probably could have put the database in US West. That would have been even worse. Um I could move everything to US West, but we're you know we're in Michigan, I really wanted it, you know, Virginia is not exactly close, but I wanted it somewhere on this side of the country. Um so that that that was an annoyance. Uh the other annoyance is when Azure manages your Postgres database, they manage the replication. You don't get to make your own replicas. I I I always like to have multiple replicas of my database. And Azure will let you do multiple replicas, they just won't let me replicate it. I just have to go to their portal, click the the proper buttons, and it'll create a new replica for me, and it'll they'll manage that. I like to run my own replicas sometimes because like I I might want to uh make a snapshot of the database for uh for doing some development or for doing some testing. You know, we have a customer that's having a problem. Usually the the first thing I'll do is I'll make a snapshot of their database. Then I can play with that snapshot. I can do all the testing I want with that snapshot without affecting their production environment. I can't do that when Azure manages my database. So that's pretty annoying. Um I would also like to have a copy of the data uh somewhere on a on an encrypted file system, even you know, back here in my house, as long as it's an encrypted uh file system, I'd like to have a copy of that data just to have a copy outside of Azure. Um I can't do that the way we've got it set up. It also turns out that all of our costs for having the the uh the cloud, 73% of that cost is the database. 27% is everything else networking, backup, VM, all that stuff. 73% is the database. Uh when you opt for replicated data. Database, you set up what size database you want, how many CPUs, how much disk, all that kind of stuff, how much RAM. And you say, I want replication, it just doubles the cost. And that's how we ended up at the database costing so much. I'm considering now, after running, we've been running for two months, and it's running great. I'm considering now running my own Postgres. Like I said at the beginning of this uh conversation, I don't have a problem running replication myself. I've been doing it for years. And and while I don't have the the tools set up to automatically fail over, uh I'm still kind of thinking I'm going to run my own Postgres replication. I can do that on a much smaller hardware uh setup than what Azure has set up. Uh basically all I would do is take the that little two CPU uh 8 gigagram VM. I would probably increase the size of that. I'd probably double it. I would uh add some disk, I would run Postgres there. I would create another small server, probably two CPUs, eight gig of RAM to run my replica. If I ever had to switch over to the replica, running in the cloud is really easy to increase the specs on the hardware. You go into the portal and you say, I want this machine now to be four CPUs or eight CPUs or whatever, and it reconfigures it, reboots the machine, and all of a sudden you run it on a bigger machine. So if I ever did have a failure and I had to switch to over to the with the replica, uh I could start small and grow if I need it. One of the big benefits that offers me, though, is I could also go to AWS and create a small server there and run Postgres there and replicate my database from Azure. So now I've got a copy of my database on another cloud service provider. Uh in case I ever wanted to move, now I could move really, really quickly. Now it's just a matter of spinning up a VM to run my services, point at my my secondary uh at my replica on AWS, and I'm good to go. Uh I'm considering doing that. Uh I did the the numbers on that, and that would cut my costs by about 35% from what I'm paying now. So we've already gone from uh my data center prices and cut it in half. Uh I would actually get down to about a third, actually 35% of what I was paying. No, is that how it's no? I would be paying 25% of what I used to pay by by doing this. It'd be 35% cheaper than I'm paying today. Uh, it'd be 25% uh of what I used to pay. So I'm pretty serious about doing that. Uh I just I don't want to disrupt anything right now. I'm gonna let it run for a while. Um probably another two or three months, I'll probably do something like that. So, do you have any questions, Wolf?

Wolf: 43:10

Oh my god. Do I have questions? Do you have questions? Of course you have to. The first thing I want to know is, and this is a question I ask in almost every situation. Uh when I'm interviewing interns, when I'm talking to people who are talking about the programs they just wrote, and for you right now, I want to know what was the hardest part.

Jim: 43:34

Well, the hardest part, it none of it was really all that difficult because I had I had played with all these technologies before. You know, the the database sounds tricky, but I've been doing that for so many years. Docker, I pretty much had that figured out. I just had to move a lot of my services into Docker. Probably the hardest thing for me was estimating what it was going to cost me. Maybe the it wasn't hard, but it was scary because I just didn't know. I could put all this effort into it and find out it cost me three times what it used to. Um that was the that was the the most difficult thing for me.

Wolf: 44:11

I think uh of the people who are listening, uh there's some fraction who are thinking to themselves, I I've got stuff I can move to the cloud. Uh so my my question to you is uh what what size of business, what category uh do you think should consider a move like this? Well, what makes it possible?

Jim: 44:35

Yeah, certainly uh this isn't the solution for everybody. Um if you have a lot of data that you need fast access to in a database, uh you may not want to do this uh by a lot of data. Like, you know, I mentioned I got I got a customer with three and a half terabytes in uh of a database. That's not who's in this data center right now. My data needs right now is probably 40 gigs of storage space. I've got uh I I think I'm paying for 125 gigs of space in in the Azure Postgres database, but I'm only using like 30 or 40 gigs, not that big a deal. Uh somebody who was using terabytes might not want to do this. Because that's a lot of data to be putting out uh uh and to be paying for. And you know, if you're if you're running that yourself, you've got a big database server as well. So, you know, you still might want to consider that. Um if you're unable to break your services apart into Docker containers, and if you had to run separate virtual machines for each of these services, cost would probably kill you. Um I'm I'm getting away so cheap because I'm using one VM. If I had to run a bunch of virtual machines, if I were running uh uh two dozen VMs like I used to in the data center, this isn't the solution for that. Because VMs, the cost of those things adds up quickly. Um you had asked about you know runaway costs, how do you prevent runaway costs? One of the things that a data center or that a uh a cloud provider can offer you is the ability to scale up quickly or automatically. I I didn't need that. I don't have tens of thousands of users hitting my site or millions of users hitting my site where certain times of the year or certain times of the month I need to scale up. When you start scaling up, that's when costs get high. That's when you know it just spins up more and more VMs to handle the load. And if you're not expecting the load and you get it and your VMs are are going crazy spinning up, that can cost you a lot of money. So if you have that kind of a solution, uh uh that kind of a service, that kind of a business that you're running, think about it. You know, maybe you don't want to jump into this, but if you're running a small business like mine, or even bigger than mine, um, this turns out to be a really nice way to go.

Wolf: 47:08

So some fraction of people who heard what you just said are still thinking, Yeah, I am right for the cloud. I want to do this. Um you said why you picked Azure. It was mostly about experience. Um But let's say uh our listener wants to move to the cloud, and there's a bunch of different cloud providers, I can think of four, not just the three we talked about. Uh, how do they pick? How do they know which one's the right one?

Jim: 47:42

Well, uh it's a great question. You gotta do some research, talk to people you know. Um you know, we're we're fortunate. We're we're we're we belong to a great user group in the Detroit area, uh mug, MUG.org, I'll give a little plug, um, where there's lots and lots of really smart people. And if I have a question of this nature, I just I just ask these guys at one of our monthly meetings, and and they can help steer me in the right direction. So if you're if you're thinking about doing this, um seek out help from your peers. Find find some peers, find a a group uh that you can ask these kinds of questions of. Uh I think that would that would be a smart move if you if you don't already have a favorite.

Wolf: 48:28

Alright, that leaves me with just one question, kind of a closing question, and that is that is this. Um for a new cloud user, for somebody who wants to move to the cloud now, what are the top things they need to be thinking about?

Jim: 48:49

Uh for me, like I said a couple of times now, it was cost. Can I do it uh without without paying too much more than I'm already paying? Um, can I can I do it and save money? You know? Um do I understand the technology well enough? Can I do I feel comfortable using something like Docker? Um if I want to run Postgres, do I do I need to have them manage it or can I manage it myself? Um those are the things you have to look at. Um it's hard for me to say what's what's uh the most important thing to look at because a lot of the stuff I've just been doing for so long, it's hard for me to think in those terms.

Wolf: 49:32

I think that answers my question. Um so uh first of all, I want to say it's always a pleasure to spend time with you, Jim. And I'm happy that we got to spend some time with the listeners, and I thank the listeners very much for tuning in. Um if you heard things that helped you or that you liked or this was interesting, leave a review. Uh that that really helps us. Uh there's show notes that are attached to this podcast. You can find them in your podcast player. Uh you can reach out to us. The best way is probably on Mastodon. Uh we're on the hackyderm.io server. We are runtimearguments at hackyderm.io. And there is also email. Uh I am wolf at runtimearguments.fm. And uh Jim is Jam, J A M at runtimearguments.fm. And uh we hope to have something really nice for you when we see you again in two weeks. Thanks, everybody.