Transcript
0:10
Hello, and welcome to Cloud Unplugged, the podcast where we take a light-hearted, honest look at the who, what, when, where, why, how and omgs of cloud computing. In today’s episode, Jon and i talk about things and stuff. We share some opinions and ask each other questions about some industry and cloud hot-button issues. What do we think? You’ll have to tune in to find out.
So with that, as always, I am Joel parks,
0:33
I am Jon Shanks.
0:34
And Jon, I guess hat are we going to call this? Is this opinion corner? I know the Top Gear guys call it conversation street.
0:46
Is that what it’s called? Yeah, I think opinion corner or like, controversy corner. We can call it whatever, I guess it depends on how red your face gets when you’re speaking to me, Joel, with anger.
0:59
Jon, it very well could turn into, ‘John and Joel talk in circles for 45 minutes’.
1:04
Exactly. Jon and Joel make people sleep, more like. We’ll have to see.
1:09
Yeah, we’ll find out. But we thought that what we could do is there are there specific things that are conversations or topics that we hear a lot. It just going through our day-to-day jobs and interacting with people in the industry. And what we thought it would be fun to do is just let’s take some of those conversations and unpack them. Obviously, they’re going to diverge, maybe slightly off the narrative that we’ve been telling of the journey to the cloud. But they’re relevant, just the same because they impact you know, the way that you perceive cloud, maybe the way that you’re thinking about it long term, some of this stuff is maybe going to be a little more high level or concept-y. But you know, it’s all good food for thought in your general pursuit of cloud and, and maturity in your cloud. pursuit. Words are hard. It’s Friday, my brain is officially fried.
2:02
Is that drink behind you, Joel, that I can see?
2:06
Ooh, I wish, that would be nice. So anyway, we both prepared a couple of questions. And what we thought we could do is just throw them out and have a healthy discussion about a few topics. So Jon, I’ll give you the first bite at the apple here. What do you have?
2:22
Right, so I was thinking about this is that these are things that are kind of coming up generally. Obviously, we’re in this space. So we speak to a lot of customers, we’re following the industry all the time. And I think there’s a cloud sell and a cloud marketing machine, obviously.
2:41
My gosh, yeah.
2:43
And then there’s reality for the customer. And I guess the question really for you is, do you think that customers understand their roles and responsibilities when it comes to cloud services, and how much the cloud is truly solving when it comes to that service before they go off and start to consume it? Or before they go off and start making decisions on, ‘Hey, well, clouds got this, we should use it and clouds got that let’s use it’? And so it’s a bit of a leading question, because each service will be varied. And I guess in some sense, how much of the problem of that service they’re solving could be variable per service. Right.
3:25
Yeah so that’s a fun one to unpack. Because this short answer to your question is no, they don’t.
But the real answer is more nuanced than that. So if you think about what cloud providers are sort of putting out in the world, their marketing and how they represent their services. Obviously, the thing that has worked for them the most over the years is simplicity. It’s easy to use, it’s easy to consume. And in a certain way that is true, right? It’s very easy to go swipe your card, and now you have access to just tonnes and tonnes and tonnes of cloud services. And but then you have to actually use them, you have to consume them and how one service works isn’t necessarily how another one works. And so while it is really easy to get access to them, you don’t have the baggage of if you wanted to spin up a new service, you know, rewind 15 years, you actually have to think about floor space. Power. Cooling. Do you have enough compute capacity to actually do it? You know, all those problems are gone. But now you have the: what is it? How do I use it? How do I apply it to my situation? So in that sense, you still have a learning curve. And in another sense, the learning curve is actually pretty steep. Yeah, depending on how much you’re trying to do at one time. It’s just sort of a kind of goes into what we were talking about, of you know, if you’re if you’re brand new to this start small, like be very conscious about how much you bite off for this very reason, because it’s going to be really, really easy to get lost.
5:10
Yeah. So I guess in principle, if you’re not going to do it via the API and you know all the other stuff. Lets say that you’re just going to go into the UI. And you’re going to stick to their console, then you can easily create things. Creating things is like clickety click right.
5:26
Yeah, click-ops.
5:26
Yeah, it’s basically click-ops. The stuff is there. But then how you consume it, how you use it, how you get access to it. Obviously, the cost implications of it, what I’m responsible for, after it’s created, like, is there still a responsibility here for me to…
5:27
Oh, yeah.
5:28
Which bit of this am I managing? Like, what’s on me and what’s on you cloud? And I think the bit I think is really challenging, which isn’t very clear for a lot of customers, is that depends on each service. So how much you have to manage in your side is then dependent per services. Like s3, or storage, for example, not very much, just stick your stuff in there, do some policies around it, you know, very simple. They cater for most, if not nearly all of it. So responsibility, mostly on them, not really much on you. Then you take a different service and it’s completely different. Again, the responsibility changes. Kubernetes. prime example. RDS database or something like that, another example. So it’s a sliding scale per service. So it’s not like, you can just say cloud does this, you do that. It’s not as black and white.
6:34
Yeah, there’s, for sure, there’s a service by service support as well as shared responsibility model for how you as the customer, what portion of the service do you take responsibility for versus the cloud provider. And sometimes it’s really clear, like, it’s a good call out s3, right? s3 is really like anybody that sits down and has s3 explained to them. And sort of, you know, what the cloud provider owns and what you own will grok, s3 really, really fast. Right? Then there are things that get much more, let’s say, harder to grab, like, message queues, or things like kinesis. Okay, so what, what exactly what part of this do I have versus what do you have? And unfortunately, I think there’s the sort of, so the cloud providers have done a really good job of selling on the simplicity thing. Unfortunately, I think the way that it’s been interpreted by some people is, oh, look at all of these services. And they’ve all been kid proofed. Right?
6:34
Yeah, exactly.
6:56
Like there’s, there’s all these services that I can consume, and there’s no way that they can go wrong.
7:51
And I don’t even need the skills. Like now, don’t need the expertise, right. I don’t need Kafka specialists, because it’s not even called Kaffir. It’s Kinesis. But kind of really isn’t, is Kafka, but it’s also and how would I even know that that was the skill I might need in my business, to be able to manage it, because not even branded the same to the industry anymore. So it’s like, you know, great, I can start clicking and getting stuff, and I can start consuming it, but you don’t really know how to consume it properly. You know, what the most efficient way to consume is that’s going to be, you know, unless I have the skill in house that does understand that. But then there’s 298 services. So it’s like, how many skills do I now need? You know, really?
8:32
And then there’s the sort of pervasive problem that we’ve been talking about it on a service by service level, right. And then there’s this pervasive problem of securing all these services, right. And security is sort of an overlay for all of the products and services that any given cloud provider will give you. And that is a whole can of worms in and of itself, right? Because the way that you apply controls and the way that you you limit access in and out of different products does vary sometimes, right. And more than that, it doesn’t work anything. Like there’s no comparable thing that exists on prem, it’s not like you can learn something on prem and have it be a one to one easy translation to understanding cloud security. It’s a very specific peculiar thing of its own.
9:24
Yeah definitely.
9:25
And it takes a while to wrap your head around
9:27
And it has a boundary again of responsibility because it can only do security on the things that it can control and was responsible for but not on the things that are now your responsibility. So again, there’s a line drawn pretty much between them and the customer. And it’s like well, no, I can only secure up to this point of which I’m responsible for you know, as a cloud vendor. Now it’s a new Mr. Customer or Mrs. Customer to kinda go off and do the rest.
9:56
Yeah, and if I could harp on this kid proofing thing for just a second. So there there is still this discussion that gets batted around occasionally. And I’ve heard it in talking to customers of why, you know, what are your cloud ambitions? Well, we don’t have any. Well, that’s interesting. Why is that? Well, because the cloud isn’t secure, you know. And then my eyes kind of bug out for a second…tell me more about that. And when you pull on enough threads, what you find out is they start to go back to, ‘here’s all the list of very high profile data breaches and incidents and, you know, compliance misses and things that have been in the news.’ And it’s like, okay, we’re gonna have to do some level setting with you to help you to understand that in almost every one of those cases, it wasn’t because of the cloud provider was unsecure. It’s because the person who was administering and setting up that environment underestimated the complexity, didn’t invest the time to learn a new way of working, made assumptions about how it worked and paid the price.
11:04
Yeah actually I read a really interesting statistic that isn’t specifically about cloud, but just generally around PCI compliance. It’s like PCI DSS, that I think more than or nearly 50% fall out of compliance within the first month, and then the other 50% fall out of compliance within that year. Right. So eventually, they’re just 100% of people are no longer compliant, which then goes to show how hard it is to maintain a very good security posture over time, you know, because a lot of people do it just to pass the audit. But then habit is still habit, right? Habit means that you still follow the same old ways you’ve done before, and you work in a certain way. And then you’re back to kind of unravelling the things you’ve done over time, that put you in a good position. So, you know, I think that I find quite interesting that it was so high, like, it’s such a ridiculously high statistic of like compliance and security. So I think you’re right, I think when it gets to the customer, you know, unless they’ve got exceptional discipline around all of this is very, very difficult to maintain.
12:11
Well, yeah. And again, they’re sold on simple. They’re sold on fast. And again, it’s not that that isn’t true. There’s just, read the fine print. Right? Like, it’s not that you it’s fast and simple. And you don’t have to you don’t own any part of this puzzle. There’s nothing about what you’re doing that has to change. Believe me there is. And if you if you take this sort of like, ‘well, it’s all kid proofed, and I don’t really need to know anything about this that’s all on the cloud provider.’ Okay, you know, buyer beware on that front.
12:51
Yeah. So I think I think that’s pretty much covered it. So I think the answer is, which is like a unified answer between both of us is that we don’t feel customers really, truly appreciate that necessarily how much is on them.
13:06
You know, at the risk of painting with an overly broad brush, I’d say the majority of customers don’t fully understand that. Obviously, it’s a bell curve. And there’s folks out on the far end that are very advanced and totally get it.
13:20
Very experienced, yeah true.
13:21
Right. But they’re sort of, they’re outliers, in general,
13:26
They’re the exception rather than the rule.
13:27
For sure. So now on to my first question. This is back for you, Jon. Alright. So one thing I know about this industry is that things change a lot. And if you’ve been in it for long enough, you’ve noticed that there’s a very definite pendulum swing, meaning that perspectives and trends in the industry really kind of swing one direction for a while. And then there’s generally some tipping point or some condition that causes the the pendulum to swing back the other direction, and round and round we go. It’s happened a bazillion times in this business. And it’s like, the one constant is change. Right? So when we apply that to cloud, it’s an interesting thing to think about. And the question really is, right now the pendulum is swinging very hard towards cloud. But if we take it as read that the pendulum will swing back, eventually, and that there will be movement away from what we think of as cloud. And again, the technology might be very different at that point. But what conditions would have to be true at some point in the future for people to say, ‘Ah, this isn’t it anymore, and now we’re gonna go a different direction’.
14:42
This is a tricky, futuristic style question though. It’s very future future focused when we’re all on Mars, and you know, Elon’s there and we’re, I’m joking. I think it’s gonna boil down to probably other things that are going on the industry. So I think when low code, or no code style companies start becoming more of a trend, will they also start hosting the things for you as well. Right? So I think, as development starts to mature into a different space, and things are much easily produced, I don’t know how long that will take before that happens, where it’s like, fully appreciated and recognised. Obviously there’s movement already happening. I imagine there will be companies where they’ll also host it, read it, and it’ll be a total service around it. And I guess as that starts to pick up momentum, maybe they’ll start to grow, because the opportunity will be different. Whether cloud catches on and still steals all of that. I mean, you know, it’s a bit of a rat race, I suppose in in certain technological spheres. That and probably edge. I imagine like edge networking, edge computing, telcos starting to compete with cloud vendors, kind of localised things.
16:03
What do you think, because the distinction that we’ve always had is that there’s my local network, and then there’s some other service, right. And it’s sort of an either or proposition of things have to run either here or there. And it’s often because of network boundary and network throughput and speed. If network infrastructure catches up to the point where there is effectively no difference between something running here, and something running there in terms of latency, or speed or bandwidth. If you can bridge those environments in a way that we know it kind of doesn’t doesn’t matter where it runs, it’s all effectively on the same fabric if you think of it that way. Does that change things?
16:49
I guess a little bit, the biggest constraint would probably be, where is the data? And I think that is where it gets a bit tricky. I think companies going backwards to be trying to do on prem stuff I feel probably won’t happen. I think there’ll be a maturity to the point where, and I reckon this will happen anyway where there’ll be just ways of moving data, and the cost of data won’t be as expensive as it is now. So there will be companies that are just shipping the data really quickly somewhere else, doing data migrations away from people’s data centres into something and then having low compute close to that data to kind of process it somewhere else, wherever that is.
Because you’ll have options now, you know, especially when it comes to edge. Maybe there’s just places locally you can ship it to at record speed, and there’s a service nearby that you can just consume and you can obviously run workloads there and start to process the data. And I think it’ll just diversify maybe and go into smaller pockets, more distributed smaller pockets to do things with, but I don’t think we’ll go backwards to, well, now it’s cheaper, maybe to be on prem.
I don’t know, maybe I’m wrong with like, outpost and Azure Stack and all these other things that are kind of happening to bridge on prem. But it probably will go past all of that even, past even that process, I think, into more of the future. I think there’ll be more like I’ve kind of highlighted, well this is total guesswork.
This is all guesswork, man!
It’s gonna be like this, Joel, this is your future. This is what its gonna look like. Yeah. What about you? What do you think?
18:32
I think it may, if I had to place bets, I think it’s going to come from two places. The first one is just economics. Now, at a certain point, cloud is still in such a growth uptick, the revenue and the business sustainability of the hyperscalers and also some of the smaller cloud providers is really coming from subscriber growth. Meaning they’re getting, they’re still acquiring new subscribers at a pretty substantial rate. So it’s from a business perspective, they can grow their top line revenue just by adding more customers. And that’s probably going to be sustainable for quite a while here, until they hit a maturity point where growing their top line revenue by increasing number of customers isn’t really happening anymore.
Case in point, we saw this in the hypervisor market. And VMware felt it big time because the hypervisor market grew by number of customers, and they were on a growth tech for a long, long time. But then, at a certain point, the market was saturated everybody had already bought. You couldn’t grow any more by by getting more customers because it just there weren’t enough of them to make a meaningful difference. So what do you do in that point? Well, you start having to raise prices, right? You start having to do things to create revenue from an existing subscriber base. And if you put that in context of cloud, it means at a certain point, it’ll saturate. And then they actually have to start raising prices to keep growing their top line revenue. When that happens, then at some point, there’s going to be a tipping point where customers will say, ‘oh, well, this was great but now it’s suddenly far more expensive and my margins are getting impacted.’ Because it’s a trickle down effect. So I think that’s likely scenario number one that would impact somebody’s decision to rethink how they do it.
20:31
Do you think, though, that they would revert back to where they’d come from? Or do you think they’ll dry…I guess it’s dependent on what else is out there at that time. I f they’ve munched up the industry, there isn’t anywhere to go. You’re kind of a little bit like, oh right. So this is this it. There has to be some innovation around the side so there isn’t a monopoly to be able to do that with I suppose.
20:53
Yeah so then there’s the idea that, so I don’t know where technology will be at the point that the business and the technology, where the business gets to the point where that becomes something that people start exploring. To where it opens up a market to do something outside of the context that we’ve been, that we’re talking about right now. So I don’t know exactly what that will be. But the other thing I think that will happen is, you know, when the one thing that’s great about cloud is that it’s very commodity service, and you can go get it. It’s very democratised, right, everybody can go swipe a card the same way or set up a payer account, and they get access to the same services. And then and then the differentiation is with within the application, right? How one company differentiates itself from another is basically down to the way that they write their apps and the way that they market and engage their customers. Now, fast forward, long time from now fast forward closer to when I talked about, you know, sort of the economic pivot.
You know, what happens when you’ve exhausted your possibilities for being able to differentiate on an application level, right? And you’re running on the same infrastructure and consuming exactly the same services as everybody that you’re competing against, and they’re getting the updates to those services at the same rate that you are, so there’s no way for you to gain an advantage? What then? Because that would drive industries to start thinking about, okay, well, how can I do this in a way that my competitor can’t? See what I’m saying?
22:26
Do you mean basically, as cloud is enabled the speed of innovation to be now basically consistent across the board,people can innovate at the same rapid speed, they can use the same technologies to solve business problems in the same way using the same technologies to solve them. That everything becomes a bit of an equal footing?
22:44
Well, yeah, so what starts is a differentiator between people that are, you know, like doing things in a legacy way, and people that have moved to cloud and adopted a new way of working and can move much faster. Okay, well, then over time, the number of people who are doing that faster way of working will grow. And suddenly, that’ll become the baseline.
23:04
Yeah, so basically, we’re all on the same starting blocks so now it’s like, basically just who is the fastest.
23:11
Right, right, or who can write the most creative app. And I think even at that level, at some point, the the ways in which you’re going to be able to differentiate or move faster, or do something that’s really outside the box or gain a competitive advantage is going to become constrained. So people are going to be looking outside of the hole at that point, the old way of thinking, the old baseline to find a new way to gain like a competitive advantage. And I think it’s the classic story of, you know, what was the attractive quality of something early on becomes the thing that locks it in and becomes a roadblock later on.
23:49
Yeah, I guess also if you’re thinking about if people all go to cloud, and that that’s done, which, we’re saying all the value, we’re talking about speed, innovation, all those things, they’re recognised, I guess, there is a little danger of the monopoly element. If everything is, you know, if there’s a total monopoly, and that business, it goes beyond just that one. category. You know, they’re also in like, retail, and in pharmaceuticals and they’re also in whatever else.
24:20
100%
24:21
There’s now a bigger danger, right, cause it’s now like not only are you in them, they’re also spreading their tentacles into other industrie that you’re also in and maybe start to compete with you on those things while you’re hosted in them, and you’ve got the cost of hosting. Right?
24:36
Yeah, we’ve already seen it. I mean, it’s a pretty common trend of Amazon ruining somebody’s business, every reinvent, right? Or now they’re doing, at least in the US, they’re doing prescription drugs. You know, they’re are a pharmacy now. And it’s like, oh, okay, that’s really fascinating. That I think if we talk about the regulation or you know, the lack of regulation in some cases, that’s something that is getting a lot of scrutiny in the US. It remains to be seen if there’s any teeth to it if there will be any antitrust action?
25:11
Well, I guess maybe that might be a trigger for what you’re saying. Right? It might be that people are just like, ‘Okay this is, like, we need something different. I’m not prepared to go to these cloud vendors, actually, for these reasons, because the monopoly is too much.
25:26
So I’ve seen that on the customer side, specifically with retailers. They have a hard no-anything-running-on-AWS mandate. Right? And so you know, where AWS and a lot of other other industries is sort of the default. You know, it’s either Azure or GCP. For those customers, for that reason only.
25:51
Right, exactly. Which is legitimate, really, you want to protect your business at the end of the day. Makes sense.
25:57
Right. So yeah, that is going to be an interesting thing. But I thought that that would be an interesting little thought experiment for us to explore.
26:07
Yeah, we should watch that. And maybe people if anyone’s listening and they’ve seen trends happening already. I’d be great to know, actually, if people are like, no, this is actually becoming a thing. There is these movements happening on the side. That’d be really interesting.
26:21
Yeah I mean this is, you know, obviously, this is ‘Crackpot Corner’, and maybe that’s what we should call it. So if you do have thoughts on on that one. You know, it’s not gonna happen anytime soon. So, you know, please submit all of your conspiracy theories to the podcast.
26:39
Or you know, if you’re a time traveller, and you’ve been there and you’ve come back, let us know! Exactly.
26:44
Yeah I’d love to know some lottery ticket numbers, you know, a few months from now. Alright, Jon, so that that was my first one. Let’s move on to your second one.
26:55
So my second one is a little bit more technical. So I may lose some people on this one. For those that don’t know Kubernetes too well, so I’ll try and keep this reasonably high level. Kubernetes, obviously when you post things to the API, things can run inside of Kubernetes that can basically mutate i.e. change certain things of your spec that you’ve posted into something else, right. So they can do that for legitimate reasons. Maybe it’s for security reasons. Maybe things do it dynamically to kind of enhance the service. I think Envoy is a prime example of that, where it will suddenly look kind of inject something into your podspec, etc. And so that then challenges item potency and as a best practice of infrastructure is code, this is my source of truth, right? What’s in my code repo is source of truth. But truth is now kind of slightly changed when it becomes a different truth, a different version of the truth inside of Kubernetes. And that restoration of service to say, Alright, I can restore my service, it’s item potent, I’ll just use my source of truth and deploy it to another cluster. And it doesn’t work the same. And you’re like, why doesn’t it work the same? Like it works over in that one, but it isn’t working in this one in the same way. Which then questions, obviously, is infrastructure with code and item potency and the principles of some of these still relevant when it comes to Kubernetes? Is the overall question.
28:30
Yeah. So we’ll take this one, one chunk at a time here. In my view, you know, infrastructure is code. I mean, that’s relevant to a different operating model. And I think we should draw the line really clearly up front, that when we’re talking about VMs, when we’re talking about infrastructure in that sense, that’s one operating model, and it has paradigms and tools and things that sit around that are that are very appropriate to managing that operating model. But that is not containers. Nor is it Kubernetes. That is a completely different operating model and a different way of thinking about how your applications run. Completely, right? So you kindof have to draw a big, big, big line down the middle and say, there are tools that exist on this side of the line. And there’s ways of doing things that exist over there. And then there’s tools and ways of doing things on the other side. And to take something like and this is, again, this is not a knock on terraform. Terraform is a great tool for what it’s designed to do, which is manage infrastructure, right? And make infrastructure item potent, that does not translate well at all, to your point to Kubernetes. Because now you’re dealing with containers, you’re dealing with a system, you may be able to use terraform to build the nodes that Kubernetes is going to run on. That’s about the end of it.
29:56
Yeah, maybe the terminology was wrong in some ways when you get to Kubernetes maybe it’s workload as code or something else as opposed to infrastructure. You’re technically running in the infrastructure, you’re not really creating the infrastructure as code, if that makes sense. When you’re deploying an app to it.
30:11
Yeah. So and the applications. So it’s two different layers, you know, what’s running in Kubernetes. You know, Kubernetes is sort of like a, it’s in some ways, like, especially if you’re new to it, it’s a little bit of a black box, right? And if you just read the tutorials, and you say, Okay, well, I can define a pod like this, a pod has a container or a set of container images, right? And then I give it to the Kube Master and it goes and it runs. And it’s like, oh, okay, so it’s a magic box? Well, it’s kind of fine to think of it that way at a conceptual level. But you know, anybody who’s used it for very long knows that you you put it under real world conditions with real apps for a little while. And suddenly you start to see the this the dragons, right. And there be dragons in Kubernetes for sure.
31:09
Yeah it does take skill, doesn’t it, to run it. I guess yeah maybe let me rephrase that. Not necessarily infrastructure as code, let’s just call it deployment as code or workload as code, whatever you want to call it. So if the infrastructure of Kubernetes is there already, and you’ve not, you’ve know, however, that got there, that could have been infrastructures code, fine. Let’s kind of put that over there. But if we’re, if we’re talking about the teams that are deploying their apps into it, and they are thinking that there’s some item potency with this kind of, I guess, maybe even in newer terms, this GitOps-y style model of like, here’s my deployment spec. I’m now going to deploy into this cluster. But then that cluster has stuff inside of it that mutates that spec and does different stuff style spec.
31:54
Yep, yeah. So I think we I think we owe it to the listener, because we haven’t touched on Kubernetes a tonne yet to talk about when you say when you say it mutates. So you have a pod spec, right? The Kube Master accepts it. And when you say it mutates it, one of one way that the listeners can think about that is you may be in a situation now where you have templated application or services configs that have sort of like key value pairs, right? Where you’re substituting values in that represent some specific aspect of that environment, not just the general configuration, but that apps now going to run in this environment in this context. And it needs to know these values in order to emit properly, right? More or less?
32:36
Yeah, pretty much.
32:37
So so the config gets mutated.
Yeah, it changed basically. It gets altered.
Yeah, right. It gets substituted with stuff that’s now specific to that environment and Kubernetes terms, depending on the way that the cluster was deployed, and how its configured.
32:53
And what’s running in it as well I guess.
32:54
Yeah and what’s running in it is, you know, you can deploy, you can take the exact same pod spec and not modify it at all in source control and deploy it to cluster A and cluster B, and have different results.
33:07
Yeah, exactly. Exactly right, yeah.
33:10
Because they’re configured differently, and they have different environmental considerations. And that is definitely something that’s a little wiggly. And uncomfortable early on in dealing with Kubernetes, because you expect it’s like, well it’s totally consistent, right? Mmm, not really.
33:28
Yeah because you’re reading the, you’re reading the website, right? You go to the the Kubernetes docs, it tells you here’s, here’s a prime example. Here’s even an example off the internet that you’re going to take. You could feasibly take it, deploy it, and it not work, depending on what was in that cluster, or what constraints are in that cluster. And you wouldn’t know why. And you’d be like, I have no idea. Like, why isn’t this working? It’s like, it’s literally an industry thing. And so what’s so unique, and I think that’s the challenge of the assumption that you can define it as per this, the API spec isn’t necessarily true. That could be variability that could do something different inside the cluster that somebody is deployed, who owns that cluster? And I think that yeah, that’s the challenge now with what does it now mean, to those concepts? That did give you a guarantee? The API spec’s there, I get a guarantee. That’s the contract.
33:30
Yeah and that’s one reason I think why Kubernetes is such a sticky complex subject because there are so many moving parts and they’re not immediately obvious, that there’s a moving part, right? Like, you can think that something’s very, very static, but once you get into it, it’s sort of like, y I’m just going to open up this door in the floorboards and it’s like, whoa, full of rats. Okay. That’s crazy. You know, it can it can be a little deceptive. Because the biggest strength of Kubernetes is sort of like, there’s some self healing aspects. And it does simplify things. And it’s very dynamic and it kind of adjust for a whole bunch of conditions. It’s also the biggest weakness in a way because it can make it very unpredictable.
35:15
Yeah, exactly. Right. So danger of, in some ways, it there’s pros and cons to everything isn’t there. Extensibility is amazing, pure innovation. In as much as you can extend something, you can simplify something or you can change something to make it that, oh, this person doesn’t need to now understand this, because I’m going to have a service that’s running in here, that’s going to make it really easy for them. And they can just do this. But obviously, the more you layer those things in, the more complicated it becomes. And so as people then try to consume, it’s then you end up with more variability and less predictability. And this is kind of the problem.
35:52
Yeah, 100%. And we’re just talking about this problem. And it is a probably a little bit of a preview of the Kubernetes discussion we’ll get to kind of down the road a little bit, but we’re just talking about pure Kubernetes. Right? This problem gets infinitely more tricky if you’re talking about something like openshift, which is not sort of a fully standard Kubernetes by itself. It’s its own thing. And if your expectation is I’m going to define everything running on openshift. And then if I ever get sick of openshift, I don’t really have to change anything, I just take everything that I’ve already got, and I just fire it at AKS or something like that. And everything runs and everything comes up and you know, I’m a happy camper. Absolutely wrong. That is not going to happen. In any in any way, shape or form.
36:47
I feel like there’s almost a little story that you’ve got to do about Joel, but maybe we can save that for another storytime.
36:55
Yeah, there’s there is a long story time on that one!
36:58
We should definitely bring that up sometime!
37:00
But I mean, it illustrates your point of you know, you think Kubernetes is A and you can be deceived into thinking that Kubernetes is a very static, repeatable item potent thing. And it just isn’t right, for a whole bunch of reasons, some of which we haven’t even touched on here. Right. The second one is that all Kubernetes is created equal. And that’s another really poor assumption, because that’s really not the case. If it’s following the the project, the open source project, very faithfully, then yeah you have much more consistency. But between distributions, there’s still variability. And then you get into platforms that are that have taken Kubernetes, but layered a whole bunch of stuff on top of it that are Kubernetes-ish.
37:46
And then you get the cloud ones, where they obviously are wrapping it. And then because there’s so many web hooks in Kubernetes essentially, where they’re saying, all right we’ve got our own authentication web hook, that’s going to then call our service, it’s then going to go off and do this thing. Because obviously, we need to integrate in our cloud provider with our own identity, because we’ve got identity in cloud. And so then they start doing all these other weird things behind the scenes that you can’t see because you don’t run it. And, you know, maybe you don’t ever need to because it all perfectly works fine. And that’s great. But sometimes it’s like weird things that they can do. That might change things and you know, you’re not quite 100% sure what’s just gone on.
38:30
Yeah, going back to the whole the cloud is not sort of like technology that’s been kid proved. Doubly so here. Because I mean, like, holy moly. It’s for sure better than taking a stance, there’s some opinions that have tried to sort of simplify some of the environmental concerns and make it much easier to get up and running with a Kubernetes cluster. But it’s still Holy moly, can you go sideways really, really fast?
38:57
Oh, definitely. And then permissions. I mean look we could save this for a whole day. This is like a topic or multiple topic conversation.
39:06
So yeah, I honestly think that we could probably do an entire season about Kubernetes.
39:14
Please don’t. Please don’t make it. As much as I love it I don’t know about a whole season for it.
39:21
But we will explore this topic in much more detail coming up. In fact, there’s an episode coming your way that I think you’ll find very interesting on this topic. So stay tuned in just a few weeks for that. But since we’re on this subject of Kubernetes, I’ll go ahead and go forward with my last question. Cause it is related. So in the sense of the the simplicity message, and certainly the trend in our business of you know, there’s a little bit of a ‘ooh, shiny’ thing you know. It’s like you know, always you know, keeping up with the Joneses or ooh shiny or whatever you want to call it. There is a certain camp within the industry that saying, yeah Kubernetes, it’s old. Like even that’s old news. Right? Why would you bother with Kubernetes? Really the thing that you need is serverless. So just do serverless. And, you know, goabout your business. What do you think about that argument?
40:19
I mean, there’s some element of truth to a degree in the fact that there are maybe more well suited situations, event driven architecture situations, where serverless definitely is more suited. But then, arguably, some of the serverless stuff does technically run in Kubernetes in the end anyway. Behind the scenes, even if it’s abstracted away to the maybe the developer, it doesn’t look like it is. But it kind of is, depending on, you know, the the extensibility, again of Kubernetes. The things you can do within it to extend it to simplify stuff. There is a way obviously to to capitalise on that and give a view of serverless, which is what some technologies do, like KNative etc.
So, I guess, yes, but doing absolutely everything as serverless probably not feasible, you know, there’s right, not everything will be suited to that type of architecture. Not all applications will be suited for that there’ll be situations where you need a mix, right, some things can be serverless, something’s running containers, you know, and so it’s, it’s not a, it’s not a one size fits all approach. And so I kind of think, you know, great, if you love it, and it alls, it’s all quite it’s simplifying things, you know, that’s fantastic. But to put that blanket statement, I think not, that’s probably a bit dishonest to kind of have to have that view.
41:50
Yeah, I agree. I mean, it at the end of the day, it’s a very opinionated platform. And we we’ve already we just finished one discussion about a very opinionated platform. Right? And serverless doesn’t avoid some of those pitfalls, right? It has a very specific way that it wants to work. And not all application types lend themselves well to being written in a way that you can that you can put in a serverless context.
42:16
And also, the thing that does annoy me a little bit with this term. serverless is if it’s like, is just, it’s it’s kind of oxymoronic in some ways. It’s like, no, obviously, there is a service somewhere. The experience might feel serverless, but there’s still infrastructure. Like if even if you need an event triggered on a certain thing. Well, what is that other piece of infrastructure that you’re triggering event on? Oh, it’s an s3 bucket. Oh, it’s an API gateway. So okay, well, how’s that getting there then? If it’s so serverless, how did those resources appear magically out of nowhere, that you also need to get that experience?
It’s not like you just consume it really easily. So I think there is still complexities within it. And I know, there’s like, you know, observability, how do you start to oversee all these interactions of many different functions, you know, that could occur to know where a bottleneck is, or you know, what weirdness just happens to my so I think there’s another set of problems to say with microservices, it can be problematic. It can be absolutely great when you do it really well, like with anything, but it can also be a nightmare when it’s applied slightly incorrectly, or you miss something around the sides that kind of make it work really well.
43:29
Or you or you fail to take into account that the service isn’t running all the time, which means the responses are not guaranteed to be instantaneous.
43:36
Yeah, absolutely, yeah.
43:37
There’s a there’s a lag and it’s in its spin up time.
43:42
Cold start, basically, isn’t it?
43:44
And I mean, so that in and of itself, depending on what the application is, from a performance point of view. If it’s something that has to be very, very high performance, that may be just a disqualifier out of the gate.
43:55
Yeah.
43:55
Right. You mean, you just you may not be able to hit the performance targets that you need? But yeah, I mean, past that. As far as the name, as somebody who works in Technical Marketing, I am a 100%. confident that was cooked up in some marketing. discussion. And it probably tested better than blackbox. Right? Because that’s effectively what it is. Right? It’s just, we’re gonna abstract literally everything from you.
44:23
Yeah. And I think Cloud Run sounds better. Actually. I’ll give Google that, Cloud Run is probably a little bit nicer, nicer. I kinda quite like that. But again, I think, you know, it’s horses for courses, there’ll be situations where absolutely makes sense, or situations where Kubernetes and containers make sense. You know, this is a situation for everything, and there’s technology there to meet the situation. That’s the reality. You can’t blanket it all and be like, you should only do this, you should only do that. And that’s that, you know, is it situational? It depends on on the situation. I think. I do remember, I think the fixes now we’ve kind of lambda and Amazon when they’re kind of hard to keep, had to keep it active. Yeah, so it didn’t ever stop so that you got the, you know, the cold start thing that you’re talking about was that lag before the function gets, you know, warmed up and triggered.
45:11
Yeah. Which always, always made me laugh because effectively it’s like, okay, so you’re taking one of the key selling points of this, which is, you only get billed for like, what you actually use at a service level. And you’re turning it into a container.
45:27
Yeah, cause you’re like, it’s too slow if it starts from cold, right? Oh, so I’ll just keep it active. Then you’re like, oh but that means it’s always active, which defeats the purpose of it being like event driven?
45:40
Yeah, 100%. So anyway, I see that argument getting argued and you know, I take everything that happens on Twitter with a mountain sized grain of salt.
45:51
We definitely will now because God knows what people are gonna post, so that’s a very wise move, Joel.
45:58
I’m gonna go put on my asbestos outfit here. But yeah, I mean, I just see this get banded around a lot. And it’s like, yeah, you know, right tool for the right thing, guys. Yeah. Let’s, let’s make sure that we, we keep that straight. But I think that covers our four topics for today. And unless you had anything else, Jon, I think that really covers it.
No, that was it for me. It was two random things each. So, no, it’s been good fun.
Awesome. Well, as always, please rate and review us on your favourite podcast app. You can also email us at cloudunpluggedpodcast@gmail.com or tweet us at cloud_unplugged on Twitter. You can check us out on YouTube at Cloud Unplugged for bonus content and videos and transcripts. And as always, thank you so much for listening. We will see you next time.
Transcribed by https://otter.ai
