Episode 11: Methinks Thou Dost Rent Too Much?

We’re baaaaaaaaack!  After a short hiatus, Brian and James return to the airwaves (or your airpods) to talk about changing directions, the reality (or lack thereof) of Hybrid / Multi-Cloud, and a renewed commitment to RBB listeners and their favorite cloud providers.

James Hunt
And we’re back. Hi, my name is James Hunt, and with me today is Brian Seguin. And we’re the hosts of the red by build podcast. It’s been a couple of weeks, we haven’t pushed a new episode lately, mostly because Brian and I have been on back channel and doing a lot of background research trying to figure out a couple of things structural to the podcast. If you’ve been listening to the last dozen or so episodes, you know that the formulas, pretty straightforward, we start with a piece or a part of a cloud native infrastructure or cloud native deployment or architecture, whatever you want to call it, we talk about what your options are from a rental purchase, or build standpoint, whether you’re going to use something somebody else’s already created, on a usage model or metered model, whether you’re going to buy something outright licensed or open source, or whether you’re going to actually roll up your sleeves, get the editor out and write some code.
Brian Seguin
And what we’ve discovered with this podcast is that we’re always going to recommend rentals. Because if it’s not your core business logic, you should always be renting it, you shouldn’t be investing the time to build things out or to buy things and implement them, you should really just be saying, hey, I want to write more business logic to add more business value to my my company. So what we’ve started talking about and started doing in the background is figuring out where most of our listeners are, is, they’re all in with one infrastructure they’re all on one is that whether it’s Amazon, Google Cloud, or Azure, or Linode,
James Hunt
— Which is fascinating. And I just want to say that right out, I’ve been in the enterprise consulting business for so long now that when we started talking to listeners, we started talking to people who aren’t in the Fortune 2000, we realized that it’s not a huge question of which of the cloud providers plural Are we going to use for this deployment of this product? That cloud portability and multi-cloud and hybrid cloud and all those lovely buzzwords are just that buzzwords, they’re not solving actual business problems for the majority of people,
Brian Seguin
Which is fascinating because what we’re actually seeing is people going all-in with one IaaS provider, and then they’re consuming every single service that is provider has to offer, without even considering if there’s other options out there. So I guess it’s the they’re, they’re using a screw instead of a nail or a nail instead of a screw, they’re not actually going out — and they don’t know what else is out there, because they’re only indoctrinated into one IaaS provider. And they only know that tool chain, so they just forcing them in there together. So what we’re going to start talking about in the next series of podcasts is where is the complexity, that you need to start breaking out from your core business logic to start to push into using other services, whether it be you know, an open source service or something, you’re gonna have to build yourself or something you’re gonna have to implement on top of your IaaS provider.
James Hunt
And I think “complexity” is the key word there. Because when we look at what people are concerned about, with the future of cloud and their cloud deployments and architectures, multi cloud is not a concern. Most most people aren’t trying to figure out how to bridge both Amazon and Google, Google and Microsoft, most
Brian Seguin
Unless you’re an enterprise, which then you just buy every single one.
James Hunt
And that’s because enterprises have a completely different risk profile, their risk profile, is having put millions of dollars into something and then have to put more millions more into something else. When we look at the mid tier market or the startup market, you’re looking at people who don’t have a lot of money, or have money, we don’t have a lot of time. And that complexity really is the thing that will kill most of those ideas. If you’re trying to paper over the differences between clouds so that you can quickly pick up when Amazon increases the rates of Lambda function hours by a half of a penny, you’re going to spend an inordinate amount of time and introduce an inordinate amount of complexity into your application design to account for what really is a non issue. It’s a non event. vendor installation is not something that most people care about, in much the same way that I only have one internet provider, I only have one natural gas provider, one electrical provider, I don’t have multiple utilities providers to play one off the other. And yes, we could get into the the monopolies of municipalities and all that. But it actually works to the benefit of the smaller companies and the smaller the startups in the mid tier businesses to just pick a vendor and go. But what we find when we talk to people is a lot of times these cloud provider catalogs are so vast, there’s a million different services Amazon as a they get picked on a lot of justly so for having, I don’t know 15 different container runtime engines now. You’ve got fargate you’ve got ECS, you’ve got EKS, they’ve probably got a hold on head lightsail for a whole bunch of these, what is out there and what just looking at service names, you may not be able to tell that this is a thing that can replace this part of your cloud architecture. Case in point, Amazon just released memory DB powered by Redis. Essentially, this is RDS. But for key value stores, backed by Redis. And it makes it so that you no longer have to spin up an EC2 instance, run Redis or spin up an EKS cluster and put Redis as a deployment, you’re, you get the same benefits we got from the shift from local Postgres local MySQL installations to RDS you get for Redis. So what Brian and I want to do is go through, right, right, Brian, you’re on board with this on a per-IaaS basis, and we’re gonna look at every single service. And we’re going to explain what it is how it works, what you would have to do, if you were going to build it yourself, and when you need to make that decision.
Brian Seguin
And when James says, “every single service,” we’re not going to go through everything that Amazon or Google has to offer. What we’re going to do, though, is the the big ticket items, the big components that are going to run the vast majority of everybody’s applications,
James Hunt
Okay, fine, we’ll just do the important ones.
Brian Seguin
(laughter)
James Hunt
I want 700 episodes of this thing, Brian, how we’re gonna get to 700 episodes, if we don’t do every single, successful and failed Amazon, Google and Microsoft service,
Brian Seguin
we’re gonna just have to start taking callers James.
James Hunt
The general ideas that if you listen to the rest of the podcast — which I hope you do, I hope you find value in this podcast, we have a lot of fun making it, I hope people have a lot of fun listening to it — that you will have a better understanding and a better feel for the texture of these service catalogs and kind of understand where one would apply RDS versus Dynamo versus SQS, where what the primary functional difference between an API gateway and an ALB is, and to be able to look at the applications, either the applications you’ve already built, or the ones you’re building today and tomorrow, and kind of slot in, hey, we could just if we just did this, you know, slight tweak, we no longer have to manage that fleet of nginx servers that keeps falling over at 3am, we can start using these cloud services, understanding with you know, eyes completely open, understanding that this is a single vendor strategy, but it’s getting us less complexity, less of a maintenance overhead. And hopefully, the ability to free up staff and talent to go build business logic, which, at the end of the day, if you if you distill what Brian and I are passionate about in this podcast, it’s about getting you to the point where you can focus almost solely on what makes your product and your offering yours, and not worry about all the plumbing and infrastructure.
Brian Seguin
Right. And if you are all-in on one IaaS, I encourage you to listen to the other is episodes that we will be creating. Because the more knowledge that you get, the more things that you know about other things that are out there, the better you will be able to make strategic decisions on your own platform, your own application deployment.
James Hunt
So I know the listeners can’t see this because we don’t do video. And that’s a service we offer to you the listener to not have to look at our ugly mugs on this pod. But I do have off to my left here, I do have the dartboard that has the big and medium sized is provider. So we’re gonna go ahead and throw the dart and see where we’re starting up our first infrastructural cloud provider dive. No surprise, it’s Amazon. We’re gonna start with Amazon. So starting next episode, we’re going to take a look at Amazon, the service catalog from a very high level and just kind of get a feel for the big services. And then we’re going to pick a couple of those and we’re going to treat those in subsequent episodes where we talk about EC two, we’ll talk about Eks fargate, etc. It’s gonna be a lot of fun. It’s gonna be a lot of work.
Brian Seguin
Let’s do it. Thank you for listening to rent buy build. I’m Brian Seguin.
James Hunt
And I’m James Hunt.