[00:00:00] Speaker A: Hello and welcome to the Rubber Duck Dev Show. I'm Chris.
[00:00:03] Speaker B: And I'm kristen.
[00:00:04] Speaker A: And today we are going to revisit a topic that we talked about a little while ago that is leaving the cloud.
So I think we talked about that with Chris a while back, if I remember right.
[00:00:20] Speaker B: You. You Chris.
[00:00:22] Speaker A: No, no, I think that was by.
[00:00:25] Speaker B: Her, I think we were.
[00:00:26] Speaker A: Oh, was it?
[00:00:27] Speaker B: It was just us.
[00:00:28] Speaker A: Okay. It's been a long week. Anyway.
Yeah, we did have a show about that.
You said you had some new things that you wanted to bring up on that topic. So that's what we're going to talk about today. But before we do Weekend Review, how's your week?
[00:00:43] Speaker B: Oh, man, my time is just a big time suck. I have no time. Mostly because, again, for regular viewers of the channel, what we've started doing is actually making short clips of some of the videos, like trying to pick out significant some people don't want to sit and watch an hour long video, but maybe they want to watch a ten minute video or 15 minutes video on a particular subject. So what we're doing is we're adding chapter marks to all the episodes that'll take a while to do and then creating clips from them and publishing them so there's more content for people to check out.
And part from that is coordinating all of that work because we have some assistance helping with that. And just the coordination, the back and forth. It just takes a lot of time to do it.
That's consuming way too much time. And I need to get back and focus on some of the other things I'm doing. I'm also working on the course that I mentioned and I'll have, again, more details in a couple of weeks. Again, this is a postgres course right now, 99% confident. It's primarily about making postgres faster in terms of query optimization and things of that nature. So more from something that a developer could use to get database superpowers, basically.
[00:02:16] Speaker A: Oh, cool.
[00:02:18] Speaker B: So what about you?
[00:02:19] Speaker A: Well, I've had an extraordinarily busy week because Friday, last week, the company announced that we've just bought out our biggest competitor.
[00:02:33] Speaker B: Wow.
[00:02:34] Speaker A: So we are in the process of merging that team into our team.
And they actually had a bigger engineering team than we did from what I understand. So there's going to be a whole lot of change management going on. Oh, man, that's and taken up a good portion of the week that I wasn't off. I was actually off of work. I took a brain break. I was out Friday, Monday, and Tuesday, and I just completely disconnected from things. I turned off Slack, I turned off my notifications.
I stayed off of Twitter. I stayed off of everything.
I didn't even return texts and calls for the most part because I just needed to completely disconnect. So I did, and I feel a lot better.
Cool.
[00:03:32] Speaker B: You may be asking periodically, what's going on? What happened?
[00:03:36] Speaker A: I've been doing that all day. Yesterday and today I was like, what is happening?
I finally caught up with my email though, so that's good.
But yeah, the new videos are looking good.
Thank you for doing that because I do the live production stuff, but then Creston handles all the back end things.
[00:04:01] Speaker B: Thank the partners in crime, Rajiv and Renzone, because they basically made it happen. I'm just like, we need to do this.
Help me make it.
[00:04:14] Speaker A: So yeah, but they seem to be doing pretty well. And I've already gotten some good feedback from community about it. And I had some people reach out to me and saying they really liked that. So we'll continue doing that. As long as you folks keep liking it, we'll continue doing it. So if you haven't, go check out the shorter form videos. Throw some likes on there because it helps the algorithms, helps our show grow. And the more we have show growth, the more cool things we can do for you guys. So there you go.
All right, so meat of the video, we are going to revisit leaving the cloud.
So give us a little recap of kind of what we talked about last time.
[00:05:00] Speaker B: So basically this was prompted by things that 37 Signals is doing.
I can't remember what the exact impetus or what was the trigger point. It's basically, I guess, just their cost spend was out of control and they started for their infrastructure. So they started examining I mean, just started thinking differently about it. And the thing that I think was probably a cause for it is that they were looking at AWS's profit margin and it was almost 30% from the original blog post they were talking about. So they're like, they're making that much money doing these infrastructure as a service and we're spending so much time trying to maintain our infrastructure. Like, we thought the cloud was going to make things easier, but really we've become super detailed accountants in trying to shave off every last penny to get the cost as low as possible as opposed to actually doing technical work. And they debated, hey, could we DeCloud ourselves basically?
And he phrases a different way in a future blog post. He said, create our own sovereign cloud, basically get a colocation facility. And this is something they had done in years past and they were still doing it for some of their applications. But get a colocation facility, put a bunch of servers in it, partition them into virtual machines, and then run their infrastructure that they said they basically explored, hey, could we do this? What would the cost be? And they came to the conclusion that, yeah, we could save a significant amount of money by doing this. So much so know David Hannemeyer Hansen was know, I was looking at this as like, what can I do to make X million of dollars over the next few years in terms of new products or new services or change. And he's like, I'm struggling to think of it. Whereas this thing is sitting right here and I know a way to save millions of dollars, potentially that was the promise. So he said, I can't not do it or explore it or try it out. So basically that's the path and what they started trying to do. So that's kind of what we covered.
You were of the opinion at the time, this is when we're doing our show that it's like, yeah, that's a one off. There's not going to be other companies or not very many other companies, particular big companies because they're so invested in what they're doing. And I was like, yeah, but there's a point at which it makes sense. I mean, maybe I was a little on the smaller organization not saying you have to be small, you do have to get a certain size because there's no way I would do this because I am not of that size. But once you have enough to have three, four, five Ops engineers, then it starts becoming, hey, you can start taking a look if that makes sense to do.
[00:08:13] Speaker A: Right? And I think one of the other things that we were kind of pointing out is that he's going back to kind of the way things were 20 years ago, bringing all the infrastructure in house because 20 years ago we were spending all our efforts trying to get the infrastructure out.
Now he's trying to bring it back in. So I thought that was funny.
[00:08:37] Speaker B: Yeah, well, I mean, what happens is that everyone was doing because they're like, hey, we don't want to deal with this. But then, now here's the thing that we were talking about something else.
I can't remember what we were talking about or if it was somewhere else. Basically, when the times are good in terms of economy and whatnot it's like, the cost is less of a consideration. But now when the economy is starting to sputter, if not starting to downturn, then people are like oh, then costs get examined a lot more carefully.
I think this may cause some people to consider looking at the cost and say, hey, does this make sense to.
[00:09:25] Speaker A: Explore type thing, which I don't understand to a point because from a business perspective, a dollar of reduced cost is the same as a dollar of increased profit on your bottom line. So why wouldn't you always try to keep your costs as low as possible and pay attention to that? Because it costs less to reduce cost most of the time than it does to get new customers and increase profits. So I don't understand that way of think. Maybe it's just not as sexy to be playing around with cost reduction as it is to be selling and getting new customers or something. I don't know.
[00:10:00] Speaker B: Well, when there's great flow and everybody has money and it's just like they keep getting more money. It's like, here budget for more servers. Oh, things are slow. It's quite easy to say, oh, things are slow. All right, then just get a bigger server because we've got all these other quote unquote fish to fry new features, get new customers. Whereas if suddenly now cost is a major concern, you have to change your perspective of like, okay, now everything must be performing. We must squeeze as much out of this as possible. You know, it's not as easy to make a new sale when there's a downturn. So it's kind of like, all right, let's shift to cost cutting measures.
[00:10:41] Speaker A: Yeah, but the thing is yes, you're right, and I think that's the prevalent way that things go. But if I paid attention to costs all the way along and I kept my costs as trim as they could, cost wouldn't ever become a major concern.
[00:10:58] Speaker B: Yeah, and there's organization. I'm not saying it's totally ignored, but.
[00:11:04] Speaker A: I think no, but it is a lot.
[00:11:06] Speaker B: Yeah, but I think at least in this case, the 37 signals case, they were apparently keeping very close track of things, but it became to the point where it's like, I don't know what was as a trigger point, but it caused them to say, hey, what if? And then as they looked at the what if, they said, oh my gosh, it's kind of like just thinking differently. Or if we do this potentially unheard of thing, we can save a lot of money, potentially, and we could do it.
[00:11:39] Speaker A: Yeah. So you said you got some new information and wanted to talk about it. So what's changed?
[00:11:46] Speaker B: Really? Just more information with the result of their transition and then a new post that I'll actually cover as well that has even more significant cost savings in February this past February. The original post, let me just say, was in October of 22.
Yeah.
Going forward in time, this is February. This past February, they had a blog post that says we stand to save $7 million over five years from our cloud exit. So basically, they standed they could save up to like 1.2 million per year for the next five years is what they're projecting.
And another thing that they were talking about is that what I didn't know and I found out reading some of these blog posts, is that they're still rocking Capistrano for a lot of their deployments. I was like, really? Wow, I didn't expect that. I mean, I'm still using Capistrano just because if something's working, I usually change, right? Yeah, but not all their applications, but some of their applications, they're using that other applications, they were using containers and Kubernetes and things of that nature. Well, their initial idea to do this cloud move was like, well, we already have this container infrastructure we're using for certain things.
Why don't we just get our own servers and then get, I guess some sort of get, like with an enterprise Kubernetes vendor, they said, or provider, and basically install their software in their system so they could coordinate all their containers using Kubernetes. And basically they again hit big dollar signs. That's basically what this post is talking about. And they're kind of like then they started reexamining again, how do we think different? What could we do differently?
And around this time is well, let me take a step back. So this blog post talks about that projection. And they were talking about the hardware they were going to purchase, what their bills are worth with AWS currently. But at that time in February, they were projecting saving $7 million over five years.
So with that, talking about the containerization part of it, they started developing something called Mersk. And we did mention Mersk in the show that we did, and it was basically a replacement for Capistrano, but as opposed to Capistrano directly, doing all sorts of bits of configuration to deploy an app more using shell commands and whatnot. Mersk, which it has a new name, which I'll mention in a second, actually took the concept of pre built containers and just deploying them to a server. So it would install Docker on the server and it would take that container, just throw it on the server and turn on the container and everything would work. So a lot of the pre work was done building your container. And so you just needed a server with Docker and a few other bits of configuration, and you just throw your container up there and it works.
So that's what Mersk was trying to do, deploy that. And actually the new one, I don't know why they changed the name. Maybe they thought it was I don't know, it was copyright related or they came up with what they felt was a better name. But it's called Kamal now, which actually has a meaning. I think it's something I'll have to look it up again. It's something like a historical navigation term while you're googling it.
[00:15:53] Speaker A: Kamal.
[00:15:54] Speaker B: Yeah. K-A-M-A-L.
[00:15:59] Speaker A: Okay.
Anyway yeah, go ahead.
[00:16:06] Speaker B: All right. So that's kind of the state they decided to say, all right, we're going to go for Merse, Kamal, whatever it is, and we're going to kind of roll our own solution to deploy our containers to our own servers. So they were going to stay with Kubernetes, but that kind of fell to the wayside.
It was a lot of complexity they were dealing with because you have to remember that they have about six or seven applications that they intend to maintain and run until the end of the Internet, as they say.
So they have some that are containerized and some that were not. So basically their experience using Kubernetes for their most recent app, hey, they had a lot of pain with using that. So I think this was also an impetus for them to say, hey, let's not use Kubernetes anymore. Let's just use a container switcheroo infrastructure focused on simplicity.
[00:17:03] Speaker A: So here's what the name means. Kamal is named after the ancient Arab navigational tool used by sailors to keep course by determining their latitude via the pole star.
It's okay.
[00:17:18] Speaker B: Just ancient navigation term.
[00:17:20] Speaker A: Yep.
[00:17:22] Speaker B: What that has to do with deploying containers and servers, I don't know, but there you go.
[00:17:25] Speaker A: Not me, but there you go.
[00:17:29] Speaker B: Or maybe they're like, this is the new way we're going to travel now. I don't know.
Okay, so that's pretty much the state of, I guess, February ish, or maybe even part of end of 22. And so then they posted another update in May entitled cloud Exit Pays Off in Performance Too. So at this point, they had converted one of their apps over, and they were significant performance boost with it as well.
Like, they had a median request go from 67 milliseconds when it running in the old cloud infrastructure to 19 milliseconds on their own server. So essentially a three fold performance improvement, essentially, or median performance time.
[00:18:20] Speaker A: Do they explain why?
[00:18:26] Speaker B: So it says that they were running on EKS and AWS. Well, here's the thing. They're using bare metal servers with super fast NVMe storage right on the box, whereas I imagine maybe they were probably using elastic block storage on AWS, which would mean you have to do network transfers to the disks. Like my experience working with some clients, direct attached NVMe drives will smoke anything that EBS has at this point. So they do talk about it. It's hard for me to read the blog post and remember at this point, but I know from experience that it's a struggle to have to get EBS up to the point as a locally attached NVMe drive. So much so, I mean, even AWS is offering direct attached storage for certain use cases in their boxes anyway because they know it's not network. Essentially, network attached storage is not as performant or you have to really spend boco bucks to get it close to that. So I think a lot of it is just due to it is newer hardware than they're provisioning on AWS. So that's newer hardware direct attach very fast storage I think is a big component of it. I don't see any other specific details about that. But anyway, so they got some good performance improvements with doing it.
They had another post about where basically David had offended, apparently people saying, we're leaving the cloud, like, you're not leaving the cloud, you're still on the like, yeah, yeah. So he's like, all right, we're doing a sovereign cloud then. Does that sound better?
It's our own, it's not somebody else's. Which we've had the terminology private public cloud. But I guess he wanted to come up with a new term.
Always the marketer. Anyway. Yeah.
[00:20:37] Speaker A: So they're getting better performance for less cost.
Okay, but what's the catch got to be a catch, right.
[00:20:52] Speaker B: They know. I mean, there will be no catch if you run your shop efficiently. Because think of it, AWS having 30% profit margins, they essentially saved a third by moving to their own stuff.
[00:21:10] Speaker A: Right.
[00:21:11] Speaker B: So in other words, AWS was taking that profit when they're running it themselves efficiently, now they get to keep that 30% profit, which they were spending about 3.2 million AWS. Now they get an extra million of dollars a year. So as opposed to that going, isn't.
[00:21:28] Speaker A: That offset by the people you have to hire to maintain it internally?
[00:21:32] Speaker B: They didn't change the number of people because the amount of staff they had, knowing the AWS, they said they haven't changed internally any staff members. They haven't increased. They haven't decreased. It's just they take different responsibilities like before. That's why I was saying in the beginning, maybe they were more cost focused in analyzing things. Now they're actually doing more actual technical work as opposed to accounting based work.
[00:22:01] Speaker A: Okay. So they didn't have to increase their manpower, they just had to shift their manpower.
[00:22:06] Speaker B: Right. That's how they've phrased it, essentially. That's my interpretation of reading, essentially these blog posts.
[00:22:14] Speaker A: Cool.
Well, I mean, that's a strong case for leaving the cloud if you're big enough.
[00:22:23] Speaker B: Once you have three to five Ops people, you have some redundancy and things like that. And as long as you have the skill set, then you can start considering it, I would think.
And then there's two more updates, at least with regard to this. The next one is in June. He says, okay, we have left the cloud, and it happened super faster than he anticipated. Basically, in six months, they had moved everything off.
[00:22:50] Speaker A: Wow.
[00:22:52] Speaker B: And he's already showing the where was it? It wasn't here, was it?
I think this one.
And they said, now our projections are we're going to be saving at least 1.5 million per year.
[00:23:13] Speaker A: That's a big deal.
[00:23:16] Speaker B: Yeah. And it all depends on how much of the infrastructure you're using.
And then in September, so again, more recent. So this is kind of why I wanted to revisit it. There's all these things that have been happening. So in September, he says our cloud exit has already got yielded $1 million per year in savings.
And he shows this bar chart of their costs going as they migrated things off and as reservations basically expired because I don't know how much, you know, but the cheapest way to run AWS servers is to reserve them for a year, two years, three years. So you have those reservations for a while. So they're still having to spend certain amount of money, but as time goes by, there's less cost being demanded. AWS.
Wow. He says he's projecting it might be able to get up to $2 million a year. It's hard to say that, but sure. Yeah. So basically, so far, if you believe what he writes, it looks like it's been a big win for them.
[00:24:32] Speaker A: Yeah, I mean, I was a bit skeptical about that. Not that you could save money and not that it was really expensive for very large companies to be on the web, on the cloud, but it just seemed to me like all the offsets, all the trade offs, all the other stuff you'd have to bring in to replace that would kind of wash all the savings away. But I guess it's not a million to a million and a half a year is not anything to sneeze at.
[00:25:08] Speaker B: They had a lot of, I guess I'll call it institutional knowledge. So they had been running their own things. I think some of the apps they had never fully cloudified or however you want to phrase it. So it was kind of like, all right, let's take what we're doing. And I think the containerization and not worrying about Kubernetes, because then they would not have saved as much money if they had to hire someone and institute Kubernetes. But they went rolled their own solution with Kamal that's much more simple to deal with, that allowed them to manage it much more easily. Then I think that's where they said, oh, wow, we can do this and save fair amount of money and not have to hire additional people to manage it.
[00:25:55] Speaker A: I'd kind of be interested to know too, a, were they doing Kamal anyway or did they do it to accomplish this goal? And B, how much did that cost to roll?
I'd be interested to know that.
[00:26:09] Speaker B: Yeah, I don't know.
[00:26:10] Speaker A: Yeah, if they were doing it anyway, it's sunk cost and that doesn't really apply here, but if they did it for the purpose of achieving this goal, then that's part of the cost of moving this, and depending on how much that costs, that could be a significant offset.
[00:26:28] Speaker B: Yeah, but I imagine it's a couple of developers time working on it. I mean, it is a relatively simple concept because they already had really all you're doing is just making sure docker is installed on the machine, put a container on there and start it and then coordinate being able to, when you're doing a deploy, put up the new version of the container and seamlessly switch over to it.
[00:26:55] Speaker A: It could have been two guys writing ten minutes worth of scripts for all I know.
[00:27:00] Speaker B: Yeah, I'm sure it's more than that, but yeah, so I don't think it was that significant of a list, or at least definitely not $5 million worth or whatever.
[00:27:14] Speaker A: Yeah, I'm sure it didn't completely offset the cost, if it offset any of it, but I'd be curious to know if they because it seems like that idea would be good whether they were leaving the cloud or not. So I'm not even sure that that was part of that goal.
[00:27:31] Speaker B: Yeah, it's not clear to me at what point that was considered, so I don't know if they were still thinking of it. I don't know if that was born when they were having frustration with Kubernetes or hand, how it was related to this or not, because it sounded as if some of the logic, you know, we could do this just by installing Kubernetes on our own servers and just move the containers we were already building and just put it on there so we don't need to have AWS run it. We could just run it ourselves.
But then maybe they had frustration with working with Kubernetes. And why is this so is I'm paraphrasing things? That my interpretation. What they're know. Why is this hard? It could be, you know, docker's, great, why don't we just put it on there and then just do these few things and we can deploy. So it sounds like what they tried to do with Kamal.
[00:28:30] Speaker A: So, David, if you're out there listening, we'd love to have you on the show to talk about the behind the scenes kind of what were the offsets of this? What did you have to put into it to get it to happen?
I'd just be interested to know, from a business perspective, what kind of trade offs you had to make and what it actually cost to achieve these cost savings, or not necessarily the numbers, but what kind of costs went into achieving these cost savings.
Still, it's pretty impressive, though, how this worked out. I was a bit skeptical seeing that, because coming from back in the stone tablet days, when we had all the infrastructure in house, I know how expensive that getting a server box was not cheap. And having the people to maintain those server rooms, your internal server rooms, and keep all that stuff up to date, it was a pain in the butt. And you ended up either having to farm that stuff out and hire external infrastructure companies to come in and do it, or you had to hire employees that specialized in that because it was pretty much a full time job. And there was just even with small businesses, it was a significant cost. And at the time, 2025 years ago, when this stuff started moving to the cloud, it was a huge cost savings to go that way.
Right. For small businesses.
[00:30:03] Speaker B: Well, I think it still is for small businesses, definitely. There's no question. You can just stick it on the cloud. Don't worry about it. But once you get to, again, a medium sized company where I guess the metric I've said multiple times is three to five literal ops people, or you're okay having that expense, then you could consider declouding yourself.
[00:30:26] Speaker A: Right.
And I'm wondering what the change was, because 20 years ago, even really huge enterprise companies were saving money by moving things out of getting them out of the house and moving them to the cloud.
So is it just that the cloud rates have gone up so much, or that it's gotten less expensive to keep things in house.
[00:30:51] Speaker B: I think it's two things, I think.
Number one, I think large organizations, there's just this cruft that builds up over time, these costs that build and the costs never go down. And a lot of times the easiest thing to do is why don't we just outsource it and essentially we take that. You clear out all the crust as opposed to doing the hard work of going in and excising it and firing people or letting people go. Maybe it's more convenient or easier to say we're just moving people, not moving people, moving our services to a consulting firm or we're contracting this stuff out now. Yeah, so I think that's one factor. And then the second factor is I think because that move to the cloud has been rampant. The past number of Google's, Microsoft, Amazons of the world have been able to charge premium prices as people move over so they can keep upping. It like I remember someone posted maybe a year or two ago looking at RDS prices. So RDS is their self managed postgres or MySQL database service. So they run the whole database for version. And there were significant price jumps by version. Meaning I think that's what it was. But it was some either by instance type, like let's say a T three cost 25% more than a T two and a T four cost 25% more than a T three. It's like, why is that? Or it was by the version of the database. Whatever it was, the longer you stayed on it and if you wanted the newer stuff, the percentages grew by leaps and bounds. Yeah, so I think that's the other side of it. I think they are milking as much as they can out of it.
[00:33:11] Speaker A: Well, if this exodus works and other very large companies take note of this and start moving off, that may end up driving the prices back down.
[00:33:25] Speaker B: Yeah, it'll be like a pendulum. Exactly. Because the cloud vendors will notice, oh crap, we're having people leave for the first time. We got to buckle down and they start to buckle down.
So it's basically this balance that has to happen, right.
[00:33:40] Speaker A: So every 20 years, guys get ready to either move your stuff in house or send it back to the cloud. Just well fluid there.
[00:33:50] Speaker B: It's the same thing. We had dumb terminals and who cares about the client. Then we had client server technologies where the client support now it's like, oh no, just give me a server and all it needs a web browser. Oh no. Now you got to build all the front end complexity. With the JavaScript frameworks, it's constant pendulum back and forth.
[00:34:12] Speaker A: Yeah, same thing with fashion, I guess, too.
[00:34:19] Speaker B: Everything old is new again every 20 years.
[00:34:22] Speaker A: Back in style.
[00:34:23] Speaker B: Now the other thing, now there's another article that I had found I wanted to actually cover here too. And this was.
From March.
And this is titled how, Hrefs. Have you heard of Hrefs Ahrefs? I don't know how to actually pronounce it.
[00:34:41] Speaker A: HTML code for links.
[00:34:43] Speaker B: Yes. It's ahrefs So I don't know if they pronounce it Ahrefs or I don't know how they do it, but they do basically SEO optimization of your probably because I was evaluating them as well as SEMrush is another vendor.
I don't know if they're the second biggest or third biggest SEO firm.
Not firm, but in terms of tool vendor to optimize your site for SEO.
And the blog post was How Ahrefs saved $400 million in three years by not going to the cloud.
I notice your eyes going back and forth there.
[00:35:38] Speaker A: $400 million?
[00:35:41] Speaker B: Yes.
So they purchased a bunch of hardware in a Singapore Colocation data center.
And I don't know why they did the cost estimate. I'm sorry, I can't recall with regard to this one either, but as a per server cost, it was basically $1,500 per month, all included with server costs and electricity. Basically everything for the Colocation facility. They tried to spec out something similar for AWS EC Two, and at every point, they actually tried to give the benefit to AWS. In other words, maybe it wasn't as fast, or they tried to get it as close as they could, but it definitely wouldn't be as fast. Again, that mirrors something that 37 signals found out where their performance went up, but their cost savings after they calculated and I think it's because of the disk heavy nature and the performance that they needed, but they were looking at $17,000 per server as opposed to 1500.
[00:36:59] Speaker A: Wow.
[00:37:01] Speaker B: So basically it was basically a ten fold cost difference. So they could have 20 servers running their own infrastructure versus two servers in AWS.
[00:37:16] Speaker A: My goodness.
[00:37:18] Speaker B: Now, you always have to take these things with a grain of salt, but that and performance measurement. But looking at this, it was like, well, even if it wasn't 400 million, if it was 200, if it was 100 million, still, I could live on that in. So much so that this article was talking and all these articles I'll put in the show notes for this episode, but they basically said our whole revenue was $257,000,000 over the last three years. So if we were to actually try to get AWS to do it, we would basically be operating at a loss.
[00:37:58] Speaker A: Wow.
[00:38:03] Speaker B: Yeah. Well, that's revenues, I don't know if it's good. Basically, they wouldn't have enough money to pay for it.
So the only way that they could do this optimally, basically, as they're saying, is by running their own stuff.
[00:38:16] Speaker A: Oh, wow.
Well, it makes sense. It's not something I would have thought of, not something I would have paid attention to, because I'm not on the infra side of things. I just deal with the code.
But that, I mean, makes sense because we use AWS in house and for our stuff to host our stuff and it's really expensive at the size we are. I mean, we're a multinational global company and it's really expensive.
The AWS bills every.
[00:39:00] Speaker B: Mean I use AWS as, you know, the thing it gets cheaper the less you ask them to do so. What I mean is I don't use RDS because again, I kind of know the postgres database, right. I kind of do my own. My database just resides on an EC two instance. So if you go the more commodity route like, hey, just give me some EC Two servers, guys, then it's pretty cheap. They do my DNS two and a few other different things, but the less value added services that you have, cheaper it can be.
[00:39:44] Speaker A: Yeah.
Wow. So, final thoughts?
[00:39:53] Speaker B: Yeah, there was a thought I had that just left my brain. I hate when that happens.
Dang a counterpoint to this.
So we did say that smaller organizations it still makes sense to go to the cloud. Totally. Rather than like if you're an company with one location, it doesn't make sense to make your own data center or get in a colocation center and get a server or two. It's just the economies of scale don't work out. Just get some cloud servers and go from there.
The other case where I think it doesn't make sense to not go cloud is if you have highly variable load on your application. Meaning like you are an event, a company or an application that does really large events and it's like for a month you don't do anything or very small events, but then you have this mega event five times a year or something like that.
[00:41:02] Speaker A: Right.
[00:41:03] Speaker B: Then it makes total sense to use the cloud or at least add it as a supplement. Do a hybrid private public cloud. So run your servers there. But then the ease with which you can scale up suddenly to immense levels in the cloud makes a whole lot of sense because then you can just ask for those servers on a temporary basis and then you can decommission them. So I think that's another reason that it doesn't make sense to leave the cloud in that case.
[00:41:34] Speaker A: Yeah, well, and that makes sense for the company I work at because we're event driven and so we have cases where for some of our larger clients, we will once or twice a year have to scale their instances up and then back down because we know there's going to be a big traffic spike because they're planning this weekend thing or whatever.
[00:41:59] Speaker B: I'm sure there's a hybrid way to do it as well.
You could run some of your own infrastructure that handles the base level, but during those high volume times, supplement with additional servers from other vendors, from cloud providers.
[00:42:21] Speaker A: Right.
Well, that was interesting. I'm glad we followed up on that. Well, I'll be interested to see how that turns out over the next couple of years. For them.
[00:42:32] Speaker B: I hope he keeps I'm sure he'll be talking about it if it's successful.
[00:42:35] Speaker A: I'm sure.
So if you're listening, let us know what you think in the comments about when it makes sense to be in the cloud and when maybe it doesn't. Do you agree with us? Do you not agree with us? Do you agree with DHH? Do you not agree with him on this topic?
That's a little bit of a hot question there. I think just this topic.
What do you think about that? We'd love to hear your comments below. Make sure you check out our new short form videos. If you are running out of time or you just have a couple of minutes while you're grabbing a cup of coffee to listen to something short, these are five to ten minute snippets of our live shows on particular topics, so check those out and give them a like. And if you haven't done so, please subscribe it'll help us out and help the show grow.
Make sure that you join us on Rubberductdevshow.com. You can email us
[email protected]. You can reach out to me on Twitter at duckydevshow. And we are constantly looking for guests to come on the show and talk about topics and we are also looking for topic ideas. So if you have any of those things, put them in the comments below. We will be back next week with something we haven't decided yet, but we'll let you know.
Make sure that you hang out on follow us on Twitter so we can announce what we're going to be doing and you can keep up with all the goings on.
So until next week, happy programming.
[00:44:13] Speaker B: Happy programming.
