Follow me:
Listen on:

Day Two Cloud 099: Can Cloud Computing Get Simpler?

Episode 99

Play episode

In some industries, the longer a product is on the market, the simpler it gets to use. (Or to put it another way, the industry finds clever new ways to hide the complexity from the consumer). Cars are a great example. Over the decades they’ve generally gotten more reliable and easier to operate.

Now take public cloud. We’re a good ten years into the industry, but the complexity trend line seems to be going the other way, particularly as cloud giants such as AWS pummel customers with new features and capabilities. Automation software, orchestration platforms, and service meshes are supposed to help, but these tools can also be very difficult to use, let alone master.

On today’s Day Two Cloud podcast, guest Brian Gracely explores the idea of whether we can expect clouds to get simpler to operate and manage. Brian is Sr. Director Product Strategy, Red Hat OpenShift. He also hosts The Cloudcast podcast.

We discuss:

  • Nuances of, and tradeoffs between, complexity and simplicity
  • Is PaaS the solution?
  • The persistence of edge use cases and snowflake designs
  • How much blame to apportion between providers and customers for the current situation
  • Simplicity, pricing, and predictability
  • What happens to simplicity when you want to interconnect things?
  • More

Show Links:

Simpler Clouds on the Horizon – The Cloudcast


@bgracely – Brian Gracely on Twitter

Brian Gracely on LinkedIn



[00:00:05.240] – Ned
Welcome to Day Two Cloud, and today’s show is all about simplicity, we should make things less complicated, or at least that’s the core premise of what we’re getting into with Mr. Brian Gracely of Red Hat and Cloudcast fame, a podcast he did recently, sort of made me want to talk more about this topic. And so we got to dig deep in with Brian. What stuck out to you, Ethan?

[00:00:30.320] – Ethan
Well, you hit on a topic that I am passionate about and have been for some time Ned coming from the networking world where things seem endlessly complex. It’s difficult to automate in the networking world, for example, because of all the nerd knobs that are out there. And I felt for a long time, if we could just simplify and make things more predictable and put more guardrails in place, that that life would be better in the networking world. And that’s really the what we come from on this show, talking about it not just from a networking, of course, but really from that cloudy angle.

[00:01:01.370] – Ethan
And and all of us, all three of us seem to have thoughts, feelings, opinions, Ned.

[00:01:07.280] – Ned
It all comes down to the tradeoffs you have to make of features and complexity versus constraints and simplicity. And that’s what we’re going to talk about. So enjoy the show.

[00:01:17.360] – Ned
Brian Gracely. Welcome to Day Two Cloud. Why don’t you first start off by just telling the folks a little bit about you and who you are.

[00:01:24.650] – Brian
Yeah. Thanks, guys. Thanks for having me on. Excited to be here, my name’s Brian Gracely. My day job. I run product strategy over at Red Hat, mostly in the kubernetes space. And then, like you guys, I do a fair bit of podcasting sort of on the side. I run a podcast called The Cloud Cast, which is a sort of twice weekly show that focuses on a lot of different aspects of cloud computing.

[00:01:48.390] – Ned
Yeah, and it’s that second show that because you just started doing twice weekly, relatively recently, your second show has now become this Sunday Exploration’s where you just kind of riff on an idea. And you did one pretty recently that was simpler clouds on the horizon. And I heard it and I was like, I got to have you on the show because 20 minutes was not enough time to to dissect this topic. So we’re going to go a little deeper.

[00:02:12.770] – Ned
Could you first sort of summarize the episode a little bit and what the core concepts were inside it?

[00:02:18.200] – Brian
Yeah, it’s sort of spun out of a little bit of just frustration on my end. So we’ve been we’ve been doing cloud computing for easily ten years now, sort of the stuff that most people think about. And and usually what happens in any industry is at some point, you know, in most industries, not ours necessarily, but in most industries at some point you have sort of early adopters and they deal with the technology and all the wonky ways that it is because it solves some problem.

[00:02:43.490] – Brian
And then at some point for the mainstream, the industry figures out a way to make things simpler for people. And and I think it’s sort of just bore out of this frustration that I have that we’re 10 years in. And Amazon continues to have 80 announcements a year on 10000 new features. And every single vendor is just like features, features, features, features, features. And I’m like, at what point, are we going to take this new paradigm and ever make it simpler?

[00:03:08.340] – Brian
And then the other kind of I always try when I do the Sunday shows, I always try and find some balance of it. And the other balance of it was Digital Ocean had just launched their IPO. So they’ve been around for ten years, but they’ve always been focused on being simpler. And I was like, why isn’t the thing that’s so simple? Why is it so small compared to the thing that’s so massively complicated when most people don’t understand how computers work?

[00:03:33.080] – Brian
So it kind of scrambled my brain a little bit and I riffed on it for twenty minutes.

[00:03:37.730] – Ned
Now that that makes sense, that that does seem to be the march of technology, like maybe the early adopters of, I don’t know, cars are always the classic example. You had to know a lot about how your car worked in order to keep that thing functioning. But now, like, I barely need to know anything about how my car works, aside from putting gas in it and taking it to a shop occasionally. So.

[00:03:57.590] – Brian
I’m super jealous. So I have two kids that are just learning to drive. And the commercial I saw the other day, you now get parallel parking built in for free on your cars. I’m like, that’s what that’s that’s the progress I want, right? Like, I don’t want to teach them to parallel park. I just want the car to do it right. Like, I want my computers to do the same thing.

[00:04:16.220] – Ned
So you want parallel parking for the cloud.

[00:04:18.140] – Brian
Right. I don’t care exactly what parallel parking for the cloud.

[00:04:21.350] – Ned
So like is complexity inherently bad or. I feel like when you make things simple, you’re just hiding the complexity and shoving it under the rug.

[00:04:32.940] – Brian
The more I think about this, the more it is I think we, you know, in a lot of things in life, you have to make trade offs because there are there are constraints. And there’s times when when we actually are pretty good at being disciplined about constraints. So, like, maybe you’re trying to lose weight and you’re like, I could put a lot of food in the fridge, but I’m trying to get healthier, whatever it is.

[00:04:53.880] – Brian
And for for some reason with computers, even when there’s the possibility to do constraints. So like we had a phase when platform as a service was kind of a rage and platform as a service was basically developers would like to go fast, but in order to do that, they’ve got to have constraints and we have whatever whatever it is in our brain is as computery people. We’re just like, yeah, I don’t like constraints, I just don’t want them and I’m just not going to live with them.

[00:05:20.190] – Brian
And and apparently the cost of constraints is just so low that we’re always like, nope, we don’t have to have them. And I think if we if we would ever get disciplined enough to sort of be like, you know, we’re going to live within constraints and and sort of evolve with them, it might get there. But I don’t I just don’t think we have the discipline to do it. And it creates what we have today.

[00:05:41.490] – Ethan
So constraints, though, give us the ability to simplify. So, Brian, I’m coming from the networking perspective where network automation has been a travesty because there are so many nerd knobs and so much difficulty and capability in our various networks, so much complexity that what you end up with trying to automate is just a lot of unpredictability in the system. That and it’s very difficult to automate when you’ve got a lot of unpredictability. You’ve got to have simplicity and guardrails and constraints.

[00:06:14.160] – Ethan
And and that to me is kind of the joke. No, we don’t like the restraints as engineers. Right. But if we had constraints, if we had a reference architecture that we had to build some something to, then it would get simpler for us.

[00:06:30.720] – Brian
Well, I like I got a CCIE back in the late 90s and I thought I knew a little bit about networking. I look at what people do in networking today. I have no I literally have no idea what any of it means anymore. Like, there’s no there’s no perimeters, like IP addresses don’t have to be contiguous, like all sorts of things that I’m just like, then how does it work? And I I’ll put it this way. I don’t want to come off as being this horrible curmudgeon because like, at the end of the day, the idea that, for example, I could work from home and not have to VPN and I could then get on an airplane and connect to the Internet and then work somewhere else.

[00:07:06.870] – Brian
Like to do that 20 years ago, you never would have thought of because networking didn’t allow it. Now it’s just like turn it on and it works. But you’re right. It’s it’s we we allow these new use cases to come along, but then they explode the level of complexity that you need to to keep up with them. And yeah, how you automate, I don’t totally know.

[00:07:24.480] – Ethan
Often for corner cases, you have all that capability because of some some narrow little thing that some particular company had. And so the technology was expanded with complexity to to add that feature that 80 to 90 percent of the user base doesn’t actually need. And I see similar in cloud. Cloud in some respects is heavily constrained. Right, because cloud providers have to make it so. On the other hand, as you were saying at re:Invent, like, oh gosh, what’s going to happen this year?

[00:07:53.820] – Ethan
All the new things I’m going to have to figure out and learn how they fit into my world.

[00:07:57.930] – Brian
Yeah, I mean, I know I live on the vendor side of the world. We’re constantly getting people asking us to do new things. And if we were all if you know, if we all could be as sort of like pure and wonderful as Steve Jobs and say, hey, Apple is great because they say no to everything, you’re like, oh, all the vendors would work out. But, you know, we all tend to say yes to things because somebody at the other end of it says, I will pay you if you do this thing.

[00:08:20.910] – Brian
But like you said, you know, 30 percent of the features maybe get used, but you never know which 30 percent are used by any given person. So, yeah, you end up having thousands of features and so forth.

[00:08:32.040] – Ned
Right. The classic example for me is like Microsoft Office products, because those things have hundreds of thousands of features and like the average person maybe uses 20 percent of those features, but different people in different job roles, use a different twenty percent of those features. And at some point someone asked for each of those features. Microsoft could have made it much simpler if they were more opinionated about it and said, no, we are not going to develop that feature because it not enough people are asking for it and it’s going to muddy the waters and bloat our software.

[00:09:03.810] – Ned
But then they run the risk of people going to a different product that offers that feature. So how can is it incumbent on vendors to push down this simplified approach if consumers are never going to demand it?

[00:09:18.400] – Brian
It is a hard sort of chicken and egg because on one hand you’d think there’d be a set of users, consumers, businesses that would say, please make this simpler because I’m tired of paying so much for for IT services. Right. I’m tired of paying for the top talent. I’m tired of paying for these things. But yet there doesn’t seem to be enough of them either asking for it in bulk to where it can create a viable business model. Right.

[00:09:46.240] – Brian
Like it’s it does feel like this sort of chicken and egg of like, you know, do you have the risk? Could you take the risk as a VC to fund some company who says I want to be the next digital ocean? But then you look at digital ocean, for example, and you go, wait the market cap of digital ocean versus the market cap of like Amazon Web Services. I don’t know that that’s where I want to be. So, yeah, it’s it’s a weird it’s a weird chicken and egg.

[00:10:10.120] – Brian
But you know what I think it’s going to be interesting to me is like so we all sort of grew up in this age where we sort of were at the beginning of the Internet, not the Vint Cerf beginning of the Internet, but the beginning of the Internet where like businesses were using it. And so we learned all the core parts of technology, like we sort of we can pretend we understand how DNS works and we can pretend we know how BGP works or whatever.

[00:10:31.030] – Brian
But like our kids, the Internet just works. And so, like, I wonder if there’s going to be this next generation who’s like I never bothered to learn how that worked, but I know I do want to build a website for my for my business. How do I do that? And, you know, so maybe there will be this sort of second generation that just didn’t learn how to do it. And maybe there’ll be a wave of technology that makes it simpler.

[00:10:52.990] – Ethan
I don’t know. I’m somewhere in the middle on some of that stuff. So you mentioned Digital Ocean, so I build some websites on Vultr using their VPS service. OK, Vulture, I want you to stand up a Web server for me. I want you to have it. Preinstalled with WordPress all live and ready to go. And I can do all that with the click of a button. And in less than a minute I think it was all stood up and ready to go for me.

[00:11:19.180] – Ethan
A very simple experience that I appreciated because I recognize at this point in my career it is not, Ned we were saying differentiated heavy lifting on a recent show. It’s not differentiated, heavy lifting for me to like install the operating system, install Apache or Nginx and then WordPress and layer all that stuff on top. I want that to be automated and simple and predictable for me. I had to live within their guardrails of exactly how much RAM the system has and CPU and whether or not I’m going to have a firewall is all very constrained and limited.

[00:11:49.600] – Ethan
Which boxes I can check. But the result I got was very simple and there’s a lot of things I don’t have to understand. If they’re using terraform or Ansible or something under the hood to deliver that service to me, I don’t care actually, as long as I’m willing to live with the product that they’re giving me and it’s quote unquote good enough. Yeah, that’s what I wanted. And that’s what I got.

[00:12:14.290] – Ned
To posit something here. At what point do we hide complexity? Who needs to have that complexity hidden from them? Because we’re mostly talking about end consumers. Right? Right. The client at the very end of the service. But there’s, you know, MSPs and then there’s the actual vendor who builds the thing and they’re reliant on other vendors. So where do we want to embrace complexity and where do we want to hide that simplicity? And I don’t know the answer. I’m literally throwing that one out there.

[00:12:40.060] – Brian
Yeah, and I wonder, you know, like I often wonder, for example, like, could you be a vendor or could you be a project, you know, an open source project for and you said, like, I would like to create a secure bank. So let’s say I’m going to become the next mondo or I’m going to become the next square or something. And you go, I don’t every time every time you talk to any large bank, they go, there’s ten thousand things you’ve got to do in compliance and this and the other like.

[00:13:05.800] – Brian
But like there’s also hundreds of years of institutional knowledge of what that looks like. Like why can’t there be a way that’s not just a consumer saying, I want to stand up a Wix’s website, but like, why can’t the next generation of banking institutions say, just give me bank security? And it’s it’s like click, click, click, click, click. And again, you know, that’s a that’s a naive thing to say because there’s a lot of stuff that goes on there.

[00:13:29.200] – Brian
But I mean, there’s got to be some way to do that such that it doesn’t have to be one hundred years of institutional knowledge. It’s like, you know, like I don’t know how to do credit card payments, but I do know how to get a stripe account, like I’ll be interested to see, like, will that become, you know, will there become like a thing that is Stripe for I want to secure a bank or I want to have the infrastructure to do a thousand IoT nodes or something along those lines.

[00:13:57.220] – Ethan
It feels like the maybe the dividing line is where different groups are responsible for different things. So I used to work on a medical exchange network. There was complexity to that. There was a large WAN involved. There was a lot of security, HIPAA requirements involved and so on. As of the time I was there, I was the lead network engineer on that project. So there was a lot I had to know because of the services that were being delivered across that network.

[00:14:21.310] – Ethan
I had to know from one end where there was a wireless kiosk that might have been wheeled around a hospital for language translation services. Let’s say exactly what the performance of the network was end to end. So that was complexity like Ned you were talking about like, when do. Where do we draw the line? When do we abstract it? I couldn’t abstract it away. I had to know right down to the kiosk that was being supplied to the hospital what the network performance was.

[00:14:44.680] – Ethan
On the other hand, I didn’t have to know a lot about some of the WAN in the middle because I gave that away to a service provider. As long as the network is performing adequately, I was fine, but I could call them up when there was a problem and say, hey, it’s broken the circuits not performing, please fix it again. Going back to illustrate the point that think maybe it’s about responsibility and if you can divide responsibility, clearly you end up with simplification from a certain point of view, depending on who you are and which service you’re consuming.

[00:15:16.150] – Brian
I mean, I think you’re right. We’re never going to I mean, look, we we we work in a complex world. There’s there’s very few sort of purely black and white things. There’s very few straight lines between stuff. I think you’re right. You kind of have to look at it from from from any given perspective. Can you make a piece of it simpler and is that valuable to somebody else? It doesn’t have to be the entire thing simpler, but maybe a piece of it’s simpler.

[00:15:39.550] – Ned
Another thing that’s brings to my mind a little bit as we think about simplifying the whole process is I see all these low code, no code solutions that are coming out that do kind of to a certain degree, they allow the business side of things to just kind of snap Legos together to build a product that they might want. Do you think that might be the simplicity that we’re, that we’re looking for to offer to customers that are and that and RPA are all kind of in my mind is the same.

[00:16:08.200] – Brian
Yeah. I mean, my my understanding of those spaces is, you know, they’re very good once the task itself has been automatable. So I think the difference between so take like a terraform or ansible type of scenario where you go, yes, I’m I’m doing this thing with the network and it needs 12 different tasks to happen, you know, steps to happen in a row. But I still need to be pretty smart about it. I think this is more like, you know, RPA is is, as I understand it, very successful when you say there’s ten steps in securing this mortgage.

[00:16:41.590] – Brian
And, you know, I could take eight, eight of those out of somebody human doing it. And here’s the system that does it. And as long as somebody can kind of drop and drag or sort of draw a picture of it. So I think that’s the trick, is that, you know, if we can get to a point where the task is really well defined, then you can automat it and then you can think about can I put a simple interface on it?

[00:17:02.470] – Brian
Because that’s really what the low code things do is they they make the interface either sort of look like, you know, PowerPoint or Visio or they make it look like Excel. And you’re like, oh, that doesn’t scare me. If it was a bunch of code with different colored words and squiggly brackets and other stuff like that scares me because I don’t know what it doesn’t look like anything I’ve ever read before.

[00:17:22.240] – Ethan
But that takes us back to your opening remarks, Brian, about engineers wanting to. I don’t want it to be simple. I want all the nerd knobs.

[00:17:31.030] – Brian
Well, it’s it’s the great challenge of as an engineer, you want to grow in what you do. And part of that is you want to take on new new challenges, but you also. You want to stop being a junior engineer and you want to be a senior engineer, and it’s hard to prove how good you are if somebody doesn’t go, wow, that was amazing. Like in the context of I don’t think I could have done that right.

[00:17:52.990] – Brian
Like, if somebody showed me, hey, I snapped together a thing and low code, I would kind of go. I probably could have done that, but if somebody writes like an awesome node.js application and you’re like, oh my God, that’s amazing, I could have never done that. You have a sense of or you have some perspective of OK, then there must be value to that because people do this weird thing. This is the other thing that’s sort of weird is I don’t know if you guys have ever seen this.

[00:18:16.900] – Brian
Like people always put things in the context of like their own either their own skills or like their own salary. So if you go to somebody, for example, and you go, here’s a thing and it costs a million dollars and let’s say their salary is like fifty thousand dollars, they’re like that is an insane amount of money. But you could also be that same person could work for a bank that takes in eighty six billion dollars a year in revenue.

[00:18:38.400] – Brian
And you’re like, OK, it’s it’s it’s not even a rounding error of a rounding error. So like I think part of that engineering piece of wanting all the nerd knob’s is. And I’ve learned this more and more over the last couple of years is that as people jump jobs more frequently and they change jobs more frequently, you’re constantly having to go. Am I helping them solve a business problem, or am I helping them build their resume? And and then that period of time has gotten much shorter, I think, for a lot of people.

[00:19:05.480] – Brian
And so they love the knobs because they’re like, cool, I can put Kubernetes on my resume or whatever the heck it is.

[00:19:12.230] – Ethan
Well Ned, I don’t know how you feel, but I feel more impressed with myself when I’ve done something in Python than what I did something in Zapier.

[00:19:18.730] – Ned
Yes, that’s absolutely true, that the sense of accomplishment that I built this thing, I wrote this thing, but I also have to acknowledge that my time is precious. Yes. And spending time writing that Python script, while instructive, also means that I’m not spending that time doing other things which might actually be more productive to me as a business or me in my personal life. So it’s there is that conflict between I do this because it’s fun.

[00:19:43.330] – Ethan

[00:19:43.960] – Ned
Versus I do this because I’m trying to accomplish a business goal. And if it’s your hobby, you go for it, you know, but if it’s if it’s your job, there’s also this feeling I think you’ve probably you’re alluding to this a little bit Brian, the not built here syndrome. Well well, we didn’t build that from scratch. So we can’t possibly use this other solution. We have we have to build it ourselves, which just adds even more complexity.

[00:20:07.690] – Brian
Yeah, it’s to me, it’s always fascinating. I’ve had a guy on my show a couple of times named named Joe Emerson and Joe’s sort of unique in that he he runs this little company and I’m going to forget the name of it. So maybe I’ll find it. But basically, he does, they’re a mortgage company and he basically said it was like I broke down all the tasks that we have in order to be able to do these things that, oh actually that’s not right they’re an insurance company.

[00:20:33.640] – Brian
But he’s like, I can I can take those and break those down into all these little serverless tasks and then the companies that can actually help us do that. And it was always fascinating to me that that he sort of put his ego aside of I could build this unbelievable, massive application to do stuff. But he was like, the role of my business is to be as profitable as possible doing this repetitive task. And I can break it down into these sort of fungible pieces of of software or code or an external service.

[00:21:04.630] – Brian
And like, it’s always fascinated me that people that that understand stuff from a business perspective and then sort of go, what’s the what’s maybe sometimes the minimal technology I need. But it will absolutely do the job I have. So, like, sometimes when I see people that, again, I can make, it kind of goes back to the constraints thing, like they’ll put the constraints on themselves because they’re like my focus comes from the business side as opposed to the technology side.

[00:21:27.580] – Brian
And there’s there’s just not enough people, you know, in our industry that that come from enough business background. That that that’s a natural thing. I think it’s hard for people to to do.

[00:21:37.340] – Ned
Yeah, yeah, I agree sometimes it is really if you came up through the Help Desk or whatever and earned your stripes by implementing complex systems, it can feel like cheating if you’re not continuing to do that or making it even more complex. But at a certain point, I think this is when you get to the architect level of things, you realize that some simplicity is beautiful and it means less troubleshooting. It means less less things to unpack and and less things to maintain over time.

[00:22:06.620] – Ned
The next thing that you brought up on the original podcast, aside from complexity and applications, was complexity in pricing. And boy, howdy, is cloud impossible to parse in terms of pricing? And I feel like customers always say they want simple pricing, but then they don’t because they’re like, yeah, I like this package, but can we take this thing out and add this other thing? You know, it was kind of like the whole cable unbundling thing and now we have all of these streaming services.

[00:22:37.550] – Ned
So I don’t know how do we fix pricing?

[00:22:41.420] – Brian
I feel like pricing is one of those things that could get fixed in a simpler way. I think that the thing that you always find out with with things like you take the cable bundle or you take you take pricing like you’ve always got to go figure out what’s the one piece of it that they’re not willing to give up. Right. So like in the cable bundle, it was always they weren’t willing to give up ESPN because it’s subsidized so many other things.

[00:23:03.740] – Brian
I think in the case of of the cloud, at least in terms of whenever I sort of dig into it, it never gets talked about. But networking is the the cost of networking is the piece that the price never comes down. And it’s really kind of the core of their business model, which is it’s free to get in, but it costs money to get out. Right. I mean, you know, and that’s not a knock on anybody, but like, that’s their that’s their business model.

[00:23:27.800] – Brian
So, you know, I think there’s definitely opportunities for people to go. I’m willing to make you a bundle. And there’s going to be times when I make money. There can be times when I lose money. But, you know, we figure out how to sort of bundle stuff together. I just the cloud providers have no interest in doing it. Like they’re like, hey, a whole ecosystem has popped up around this, whether it’s tools or people that call themselves cloud economists or whatever it is.

[00:23:52.010] – Brian
But I think they’re I think that’s where maybe there needs to be a secondary group that sits in front of your environments that just focus on that. And I mean, we see it all the time. Like we see we see companies that are willing to do financial modeling, financial risks, like we see that in the finance industry. Like, I wonder if we will ever see it in the tech industry once people start understanding the patterns a little bit better.

[00:24:15.500] – Brian
Because I don’t I don’t know that the cloud providers are they have any incentive. What’s their basically like the old cable companies, they have no incentive to necessarily do it.

[00:24:25.490] – Ethan
Wait a minute. I disagree that they don’t have any incentive to do it, because if you could consume cloud services with an easy to understand pricing model that for some businesses that’s going to be a win that’s going to be attractive to them. Because the flip side of it is what is putting off some customers is just I don’t understand how to deal with this or what this is actually going to cost me or the reality of their bill hits them and they can’t make sense of it.

[00:24:48.920] – Ethan
And it feels to me like there is a market opportunity there for I don’t know, I don’t maybe not the big three, but maybe an up and comer to. Look, here’s what we got. It’s really straightforward to understand our pricing model and go from there. But the pricing model is I think you brought out in that podcast, Brian, it changes by product. It seems obtuse to get your head around what exactly is being what you’re being charged and so on.

[00:25:14.480] – Brian
It’s it’s sort of interesting. The cloud, the clouds gone through a couple of things. So like obviously, like in the Enterprise, they solved a lot of it. I say solved. Right. They came up with the we will do an ELA [Enterprise licensing agreement] and here’s the price. It’s sort of all you can eat. And so for some companies, that works out great. And for others, it was interesting to me, somebody at one point in time, I don’t know if you guys were following it at this point time, but at one point there was like there was the Amazon pricing thing, which on one hand, psychologically, people were like, oh, my gosh, five cents an hour for compute.

[00:25:46.130] – Brian
That just seems ridiculously cheap. And then they do the math and they go, oh, they’re not that cheap. But there was at one point. There was this psychological thing of we will price it like going to the grocery store and everything will end in a nine. And so you’ll think you’re making money. And then Google came along and Google said, hey, you shouldn’t have to think about that. We will just automatically make your bill lower or, you know, you sort of per unit lower as you pay.

[00:26:08.090] – Brian
And and on one hand, people were like, that’s brilliant. Like that’s the Googley way of thinking about stuff. And they’re just going to work it out. And apparently what it turned out was CFOs and project managers were like, yeah, I hate that model because I have no way of forecasting what my stuff looks like. I need you to give me definitive pricing on stuff. And so.

[00:26:28.730] – Ethan
A case in point, it just a really small scale. I can consume Vimeo for business to do video distribution for me and they’ll give me that. Basically, it’s. CDN, more or less is what I’m getting, it’s 80 bucks a month or whatever it is, flat rate, or I can go to a service like Bunny, Global CDN, they’ll charge me some fractions of a penny per gigabyte distributed. What’s that going to cost me? I don’t know.

[00:26:52.830] – Ethan
You know, am I getting a better deal with the Bunny Global CDN? I might be, but it’s hard to say. And the unpredictability of it’s a little a little bit freaky.

[00:27:02.790] – Brian
I feel like the SaaS folks have figured it out the best because they put these they put these sort of buckets around things and they know enough about their customer base. They’re like, I’m probably going to make money on more of them. Some of them I won’t. But again, it reduces that friction of like, what does it cost? What’s the uncertainty of it? Do I want to trust them? I would love to see the the sort of infrastructure cloud providers figure out a way to to build their kind of produce their pricing in such a way that looks a little more like SaaS like here’s a lower end pricing, here’s a middle range pricing.

[00:27:36.510] – Brian
Here’s kind of here’s a top one pick which bucket you fit in. But that doesn’t seem I think it’s because they build all their services independent of each other. It would be really, really hard for them to just say, take these six in a row. They do do it sometimes. Right. Like you will see, the great example I always use is at one point Amazon had like an RDS database and they realized that people would always buy the database.

[00:28:00.900] – Brian
They had struggled with storage, they struggled with backups, and they made something that became the Amazon Aurora database and they included all for you. So they kind of do it when they see patterns, but they must not see enough consistent patterns and they must have the own their own internal sort of struggles to be able to make it look like SaaS pricing. Because, like you said, that’s whether that’s effective or not. It’s the easiest to understand.

[00:28:24.240] – Ned
I feel like, as you brought up before, networking is always billed separately, though. So even if you use that Amazon, Aurora yeah. It probably bundled in the storage and the compute, but I bet the network egress was not included in that price. That was still an unknown and kind of unknowable, which maybe the most frustrating thing about pricing is not how simple it is, it’s how unpredictable it is. And we’ve all said OpEx is the way and capex boo hiss.

[00:28:54.660] – Ned
Is that a mistake? Should we have stayed in the CapEx world like a little bit?

[00:28:59.130] – Brian
Well, I think the cloud providers have learned that they I mean, they you know, the I think maybe the great I don’t know, misunderstanding is that everything is on demand. Like they have plenty of they will they will do plenty of what they call like enterprise, what is it called enterprise discount plans or something along the like. They’ll create you the equivalent of what looks like CapEx and, you know, so it exist. I think what’s interesting to your point about networking is most people don’t know how much networking they use.

[00:29:29.070] – Brian
Right. Like they want the network. They want it to be there, they want it to be fast. But if you ask them, like, how much traffic does my application generate, you’d be like, I don’t I don’t totally know.

[00:29:38.460] – Ethan
And it varies by application. So much Brian.

[00:29:40.780] – Brian
Yeah, yeah, yeah. So so sort of ask somebody like how do they then price how much you’re willing to pay for the network. You’re like, I don’t, I wouldn’t even know where to start. Right. Like you’d have to do a whole lot of research and then. And then and then you put the burden on, on sort of the application team to be like, oh, maybe you should start thinking about being more effective. And you’re like, is that really what we want to do?

[00:30:01.200] – Brian
Or do we want to build good applications that people like? So yeah, it’s there’s always a way around that way, but maybe not for good reasons.

[00:30:11.230] – Ned
You could spin it up potentially to a positive there, where if you realize how much network capacity an application is using, and it shouldn’t be using that much. Maybe it’s just a really inefficient application and it could deliver a better user experience if it was more efficient. So there’s potential positives there.

[00:30:28.660] – Ethan
I can tell you developers don’t always think about what’s traversing the network just to speak about efficiency. And you can send a whole lot of data in in a transaction response that’s not needed to actually accomplish the transaction, makes it really inefficient on the network transport.

[00:30:43.680] – Brian
Well, in it, I mean, like we’ve gone through this, right, like we’ve seen scenarios where developers will get really efficient, but it usually starts somewhere like it’s like, hey, you’re hitting the database a hundred times when in theory you could cache 60 percent of that. Oh, OK. There’s a distinct number there and there’s probably a distinct cost. We don’t necessarily do that on the network, but maybe we start we will now in in the cloud since where that becomes a distinct line item that everybody’s aware of.

[00:31:13.210] – Ned
It sounds to me like in an ideal world, and correct me if I’m wrong, the great pricing scheme would be more predictable and a little simpler. But like predictability is probably the biggest component for a good pricing scheme. Does that does that sound relatively accurate?

[00:31:28.750] – Brian
Yeah, I think so. I mean, I think if we think about most things in our lives, like we value predictability, the stock market values predictability, you know if you if you know how much something’s going to cost, at least you can plan around it. It’s it’s the unknown bill that I think surprises people. Right. That’s the one that always gets the most headlines, is we put an application in the cloud and we got a two hundred and sixty thousand dollar bill.

[00:31:51.010] – Brian
And you’re like, oh my God, I had no idea. But but if you knew going in like it was going to cost you 60 grand, you’re like, OK, that’s that’s you know, that’s sort of binary good or bad. So, yeah, it would be nice if it would be nice if they were a little more. I mean it’s it’s weird. Like I’m trying to think of other aspects of my life in which, you know, what something is going to cost is so, you know, so unknown, you know, based on kind of what you what you’d expect to have seems to be that I can’t think of anything else or say.

[00:32:22.270] – Ned
Well, it’s the it’s the elasticity of the cloud. That’s the big problem. Like, my power bill is basically it’s very close every month because I use about the same amount of power. It’s going to fluctuate in the summer, but overall it can be about the same. But an application you’re running in the cloud that’s available to external people that can just blow up because suddenly your applications really popular and hopefully it’s making you a ton more money. But it also could result in a much bigger cloud bill, if someone’s abusing it in some way.

[00:32:50.080] – Brian
Yeah, and even like little things, I mean, like we have a thing here. I mean, so North Carolina is a strange place because it’s really hot in the summer. And so you will get these these strange electricity bills. But even them they’ll come to us and they’ll say, hey, if you’re worried about that kind of stuff, like we can we can create a billing model that sort of normalizes stuff. And, you know, and you look at it and you’re like, OK, maybe I’ll pay a few more bucks for a few less.

[00:33:14.020] – Brian
But that’s the sort of stuff that from a customer kind of friendliness perspective, you would sort of like to see some of those things. Now, you probably can’t do that if you’re Netflix, but I imagine most customers would appreciate if you were like, hey, you know, if you’re not really sure, like, here’s another way of doing the financing of it. So maybe maybe that’s maybe that’s a way that sort of evolves but still has the elasticity of it.

[00:33:37.310] – Ned
The last point you brought up on your reflections was the complexity of interconnecting services, and to pick that apart a little bit, what types of services are we talking about connecting? Is it cloud, cross cloud, SaaS? What did you have in mind when you were thinking about that?

[00:33:55.550] – Brian
Well, I think it’s like I go through this thing all the time. So, you know, I have friends who go, hey, you work in tech, can you help me with? And their ideas are they’re all fairly legitimate things. They’re like, look, I, I want to have this front end service and I need a database, but I’d also like to be able to have it connect to Twitter or have it connect to Stripe or something along the lines.

[00:34:16.460] – Brian
So, you know, it’s your it’s your classic example of an application that, you know, is going to integrate with three or four parts, call those micro services or whatever you want to call them. And I think parts of it have gotten much simpler. Like I can get I can get a billing system or I can get a credit card system. Really simple, but I still need to know, like how to program an API, for example.

[00:34:37.400] – Brian
And it would be nice if it’s just a regular everyday person didn’t have to necessarily say, like, how do I do the API? Can I just click a button? Maybe I get a token back and I put that in a field and all of a sudden my WordPress thing has I think of it as sort of like WordPress plugins. Like I just want the button that says do that thing.

[00:34:58.520] – Ethan
I’m laughing, having just gone through needing to query a particular Google Cloud API and it was 90 minutes of jumping through OAuth2 flaming hoops to get to the point where it’s like now I can run the transaction against the API.

[00:35:13.010] – Brian
You know, again, some of that comes back to, you know, if you’re if you come from an infrastructure world, which is more my background than development, like I wish development stuff was easier, I think developers probably say the same thing. Like I wish the network was easier. But, you know, I think there’s there is sort of a constant tension of we wish the other part was easier, because sometimes sometimes you have to do those parts.

[00:35:33.560] – Brian
So that was kind of all it was, is that we no longer sort of have monolithic applications. They’re they’re composed of a lot of things. I think there’s a big industry that does things like API gateways and integration services like MuleSoft and Red Hat has a service and lots of of others. But like even those things, you know, every time somebody says you need a consulting organization to help you do it, you’re like, OK, that’s probably too complicated.

[00:35:57.830] – Brian
I understand. If it’s like it’s a 20 year old system and you have to connect it to some COBOL code that doesn’t exist. But like, I should be able to string together five or six things on the Web these days as if they’re just WordPress plug ins. And I think for a lot of businesses, like, you know, like if you’re the marketing organization of some some something, you’re like want it to be that simple. I’m all I’m doing is like it’s like a promotion for something.

[00:36:19.430] – Brian
I want to give out a coupon. I want to collect your email address. That should be like snap, snap, snap. I’m done. And I think it still takes a little more time than it needs to.

[00:36:27.260] – Ethan
Ned does that go back to your low code? No code point from earlier?

[00:36:30.590] – Ned
I think it might, because one of my favorite platforms is Zapier, because it lets me stitch together things and it’s manipulating all the APIs on the back end for me. And it just gives me a pretty simple, GUI interface that’s actually fairly powerful. Like you can do a lot of text transformation. You can have alternate paths, you can pull information in from like Google sheets and stuff like pretty much anything that can it can hit with an API it can work with.

[00:36:58.280] – Ned
And I’m sort of envisioning what you’re saying. But instead of consuming all these sort of like Twitter and Buffer and WordPress type stuff, getting deeper and maybe it hits SAP or maybe it hits, I don’t know, my manufacturing application or something. Do you think there’s a market there for someone to build a Zapier for industry?

[00:37:19.940] – Brian
Yeah, there are. I mean, there’s I’ve got I’ve got a good friend who started a little company called Trigger Mesh that does something similar to that. They you know, they’re trying to become sort of the the event bus, if you will, for the enterprise. But more of like, I don’t need a big giant event bus. I want it to sort of work like Serverless. We’re just sort of sits there idle most of the time. And then, you know, if an IoT device on an event floor kicks off, some, you know, sends out a message, then something could happen.

[00:37:48.650] – Brian
So, yeah, there are some companies that are that are trying to do that. And again, the the technologies there or at least the pieces of technology are there. But will they become big companies or not? It’s that fine line between is the goal to be more simple or is the goal to have one hundred integrations because you want to be able to get to one hundred use cases?

[00:38:08.150] – Ethan
It goes back to a point you made about the human impact here, Brian, where if I don’t have services that are doing these things for me, I need some team of high powered engineers to pull it all together.

[00:38:21.110] – Brian
Yeah, again, I don’t think the goal of this thing is like the entire system is simple because we are often solving complex problems. It’s you know, it’s sort of looking at are there places to simplify? Because as simple as it is the other. Like, as simple as it is to, like, hail an Uber, I mean, there’s a you know, there’s a million complicated things behind that that made it simple. So, like, we can’t have a mindset of like, hey, just make everything simple.

[00:38:47.290] – Brian
You’ll never get the simple result. But, you know, maybe it’s just like it’s like Ethan said early on, it’s from certain people’s perspective, for certain parts of it that we want to be simpler.

[00:38:59.070] – Ned
Right. It’s simplicity for me is always complexity that’s been bundled into an abstraction. And then you only expose small portions of it that are actually relevant to the person I think of, like, you know, modules and libraries in programing. I don’t need to write a calculator library or a string library myself. I can just I can import that and use the functions inside of it. And hopefully it’s programed well enough that I don’t have to worry about how it does those things.

[00:39:28.350] – Ned
It just does them. And maybe this is just another instance of that. Another thing that kind of popped in my head was the fact that every cloud provider has a different way of doing things and they’re like they’re close enough but not close enough. So like when you want to do the same task in Azure versus GCP versus AWS, it’s going to be close, but vastly different in the way that you implement it. And I think that’s by design.

[00:40:00.450] – Ned
I think they don’t want it to be a consistent framework across all the all of the clouds. What do you think of the idea of a standard cloud model and that being applied to the various clouds out there? Could that be a way to simplify things?

[00:40:17.520] – Brian
It would be nice, right? It is sort of that that is at the heart of the sort of multi-cloud discussion that sort of rages on on Twitter and other places, which is like companies would like to maybe not necessarily be tied to some specific implementation in a cloud provider. But then at the same time, if you’re going to do that, are you only going to give people the sort of lowest common denominator? You know, I think it’s I think it’s a nice concept.

[00:40:42.120] – Brian
And I don’t mean to downplay it. I think we’ve just seen historically and I know this from having worked at Cisco forever, like we would work forever to make sure that the Ethernet standards were all the same and then we’d add 10 extra features that were Cisco specific, that, yes, they were they were better or they were more expensive or whatever. But you were like my intention was always that you didn’t use anybody else’s Ethernet. So I think we’ll see some of that.

[00:41:03.330] – Brian
Like we see standards around HTTP or we like certain things. I just I think there’s too much money to where the vendors are going to. They’re going to say, let me let me do that to help you, to help you move. I mean, it’s this will, will those vendors, ever basically create a standard that that simply enables sort of divorce from the cloud as a service? I don’t think it’s in their best interest to do that.

[00:41:27.750] – Ned
No I guess not, no moving back to on Prem or to another cloud, it’s not something they want you to do.

[00:41:33.180] – Brian
Yeah. I mean, they’re fine with you going back on Prem again. They just want you to do it in the Azure way or the the AWS way or I mean like they’re like, hey, I’m happy to provide you hardware on prem and software on Prem and just. Yeah. I mean I think that’s always the tension between the users and the vendors themselves is the users are like I have a business problem to solve. Some of that would be solved if it was standardized.

[00:41:55.500] – Brian
And the vendors are like, you know, I’m in the business of making money, applying engineering to technology. So we’re going to have to figure out where that tension or the right tension is. And, you know, nobody’s in it for sort of the wrong side of it. It’s just it’s a it’s a normal tension of, you know, what problem are you trying to solve? What what what resources did you apply to solve part of the problem?

[00:42:17.170] – Ned
Right. It’s almost like the more open standards that no one necessarily owns are the ones that are going to be a standard and add some simplicity. But there’s always going to be complexity above and below where that standard lives in the stack. So you mentioned HTTP, and that’s that’s a common standard across across the stack. And so it’s it’s a relatively simple right. It’s not a super complicated protocol.

[00:42:42.510] – Brian
I mean, we we do well in our industry when there are some fundamental standards. Right. Like at the network level, there’s there’s IP at the application level, there’s things like SSL or HTTP. And I think the industry sort of is like, that’s enough. Like those are foundational enough. We don’t. Because if you because again, if you if you put too many constraints on them, then we couldn’t do some of the amazing things that we do.

[00:43:06.510] – Brian
So, again, it’s it’s not a somebody trying to influence control. It’s going the industry does the best when the pie continues to sort of get bigger and ideas can flourish because they can build on these basic building blocks and maybe create something one or two unique things. So I think it’s I think it’s OK that we don’t have universal only standards for the cloud. People can pick and choose what they like because, I mean, look, there’s there’s some people that love only being in Amazon or only being in Azure.

[00:43:34.350] – Brian
Like, there’s nothing wrong with that. You know, that if it’s their business, it’s what they need for the business.

[00:43:39.660] Ned, you had said HTTP. As how come it’s not really that complicated? Right. Only it is I mean, it’s because I got HTTP/2 to HTTP/3, you’ve got different transports upon which you can have HTTP going. You got qwik. You’ve got SSL and TLS. As someone who’s just been I’ve had needed to build a Web server recently and was going through security hardening all of the emerging things that have come up to insert in headers, to instruct browsers what to do and not do to avoid certain security attacks.

[00:44:13.820] – Brian
It becomes complicated yet again, even though in theory I fundamentally I agree with you what HTTP doesn’t have that many methods. It’s got a pretty well-defined set of error codes and controls, and it’s awfully well known. And yet, as you dig into the details of implementing it, it’s a constantly evolving standard that isn’t simple anymore, sadly.

[00:44:35.330] – Ned
So are you saying that we took a simple thing and because we wanted to add features, made it more complicated?

[00:44:42.080] – Ethan
Dude, it’s unbelievable. Yes. I mean, I’m looking at something called content security protocol now where I’m supposed to build a lexicon of what is allowed and not allowed and deliver that as an HTTP header to a browser in order for my Web server implementation to be considered properly secure and modern these days. Yeah, man, it’s. It’s nuts.

[00:45:01.380] – Ned
All right, well, I’m going to let Brian have the last word on this so we can’t just burn everything down and start start over. So, or maybe we can? So assuming we don’t do that, what do you think the solution is or not even the solution? But what should the path be forward for getting to this more simpler version of the cloud?

[00:45:22.470] – Brian
I think there’s a couple of paths forward. I mean, I think one one one real simple path is to go, hey, Brian, you’re an idiot. It will never be simple. I’m going to I don’t need to listen to the stuff you’re saying, which is which is fine. Right. There’s the complexity kind of comes out of lots of use cases. I think my my hope is that there will be viable businesses for companies like like a digital ocean type of company or even just, you know, sort of the things that somebody like Apple does to make certain things simpler.

[00:45:52.720] – Brian
And some people would argue that argument. But, you know, I would hope that just that when people look for simplicity, that there will be markets that sort of embrace it and go, hey, as long as you’re willing to live with certain constraints, here’s some very cool tools. I hope some people in the open source community spend a little bit of their time focused on those things. I don’t have any crazy, you know, wild ambitions that, you know, everything will be simpler because I think, again, we all benefit from people getting creative.

[00:46:19.980] – Brian
And unfortunately, their creativity sometimes do it. But at the end of the day, I think I’m hoping there’s some small piece that people in the back of their mind go and maybe I can put one less feature in and that’ll make things a little easier for people. And nobody will be the wiser and people will be a little bit happier that they didn’t they didn’t spend 90 minutes trying to figure out HTTP headers or something like that,

[00:46:42.420] – Ned
Helping Ethan out there. We appreciate that.

[00:46:44.760] – Brian
That’s right.

[00:46:45.330] – Ned
If folks want to know more about you, where should they go to get get more Brian and more Cloudcast?

[00:46:51.030] – Brian
I don’t know if anybody needs that. At bgracely on Twitter is probably the easiest thing or LinkedIn or something. The Cloudcast is the cloudcast dot net because somebody had the cloudcast dot com 10 years ago. But yeah, if you just search for the cloud cast, it should typically come up in in Google and other places. So that’s that’s the places you can find stuff.

[00:47:11.620] – Ned
Awesome. Well, Brian, thank you so much for being a guest with us today on Day Two Cloud.

[00:47:16.120] – Brian
Thanks for having me, guys, as always. Great to catch up too.

[00:47:19.010] – Ned
Absolutely, and hey, listener out there, a virtual high five to you for tuning in, if you’ve got suggestions for future shows, we’d love to hear them. You can hit either of us up on Twitter at Day Two Cloud show. We do monitor that handle. Or you can fill out the form of my fancy website, Ned in the cloud dot com. You know, if you’re listening and you’re like, man, I got this way cool cloud product that makes things simpler for the IT professional.

[00:47:42.560] – Ned
You know, we’ve got a whole audience of IT professionals out there and you could become a Day Two Cloud sponsor. You’ll reach several thousand listeners, all of whom have problems to solve. And maybe your product fixes their problem, but they’ll never know unless you tell them about it on our show. So you can find out more at packet pusher’s dot net sponsorship until next time. Just remember, clouds, what happens while it is making other plans

More from this show

Episode 99