Welcome to Cloud Unplugged, the podcast where we take a lighthearted and honest look at the who, what, when, where, why, how and OMGs of cloud computing. In today's episode, more news from the cloud, will my dogs make a return appearance? stay with us to find out. Also single, hybrid or multi cloud, we discussed the realities, benefits and drawbacks of each of these approaches.
I am Joel Parks.
I am Jon Shanks.
And Jon, we have some pretty major podcast news. So we have officially reached the 100 subscriber mark on the podcast. Yeah, so we have listeners. Hello, listeners. And first of all, thank you for listening and tell your friends. But, you know, that's a pretty huge deal for a new fledgling podcast to have 100 active subscribers.
That is amazing. I just want to point out all the 100 are me, Joel
Oh is this the bot account thing?
It is one of my bot accounts, yeah, I just want to confess. Yeah, you're talking to me 100 times. So yeah.
Oh, wow. Okay, well, then we have nothing to worry. But anyway. So I just wanted to say thank you to our listeners, we know that you're out there we see you. And it's really gratifying to know that you're listening, you're paying attention to what two crackpots on two sides of the Atlantic have to say, we are really thrilled. So please, you know, interact with us, tell us what you'd like to see from the podcast, we are more than willing to accommodate your requests, questions, etc. So thank you very much. From there, let's jump straight to the news.
So, in the news this week, we've got two articles. I think they apply to either things that we've talked about in the past or something that we're going to talk about in the future. The first is, it's an announcement out of Microsoft, specifically in the Azure space. And that's a new feature that they're rolling out called Azure auto manage. Now, if you recall, in the last podcast, we talked about, you know, resisting the urge to take your existing Configuration Management System Management Tools, specifically for infrastructure, and extend them to the cloud. You know, our recommendation at that time was use what the cloud can provide, you use their ways of managing infrastructure. And here we have an announcement out of Microsoft, that is perfectly in line with that. So the feature's called Azure Auto Manage. And from the article, which we'll tweet out, that's what Azure Auto Manage is. Sorry, As are hard. It's a tool that distils Microsoft's own experience and uses it to make sure that your virtual machines, whether they're running Windows, or Linux, run at their best. And what it does is it takes into account best practice from a Microsoft point of view for managing infrastructure on their cloud, and takes the functions around account automation, update management, monitoring, security, boot diagnostics, backup, log analytics, configuration management, and change tracking and inventory, and provides a curated experience to make managing infrastructure on their cloud, really, really seamless. So I think this is like a big plus one or clap from Microsoft, towards what we were talking about. Right, Jon?
Yeah, definitely. It looks really good, actually. I mean, obviously, we're not seeing it in action. So I think it's in preview, isn't it at the moment? So people can obviously, try it out. And I'm guessing it's probably got a few little issues...
Oh yeah, there will be things.
But it does look really good.
Yeah. But you can see what we were talking about that all of the cloud vendors are aligning to provide you tools to manage infrastructure on their cloud, that are specific to them, and encapsulate the best practices for that cloud. So if you were having the conversation of maybe we want to extend system centre or satellite or whatever, out to the cloud, and take our on prem technology and sort of commingle that with our cloud resources. This is a, this is the best, you know, sort of plus one for what we were saying, Just don't do that.
This sounds like you're almost getting into the hybrid story there Joel, a little bit.
Oh, just a little!
You might think that we spent some time This podcast. Yeah. But that's, that's the first article. The second one is, and again, we'll tweet this out there is a book from O'Reilly called Cloud Native transformation, practical patterns for innovation. And there was a summary article that was put out talking about, you know, what is cloud native, because, you know, that is a term a little bit like DevOps that, you know, depending on the context, and depending on who you're talking to, could have lots of different meanings to lots of different people. Cloud Native isn't a settled term. And the goal of this book, I believe, is to try and settle that term and provide a concrete definition behind it. And to be honest, the the article spells it out in much more detail, I'll hit on the highlights here. But I think they do a pretty good job. In the article, they call it the five principles of cloud native. And those five principles are containerization, dynamic management, microservices, automation, and orchestration.
And from my perspective, I think that really does a good job of summarising that the the different concerns, the different layers that are concerned with what does it mean to be cloud native. Obviously, in this podcast so far, we've talked about a few of those. But as we go along, as we talk more about the journey, we'll we'll get more into these. And obviously, when we get to the end of this podcast, we have a little bit of a tease for the next episode that's directly related to this. JOHN, What's your impression of the way that they describe cloud native? Yeah,
I mean, obviously, we haven't read it. So not 100% showing the content yet. But the principles make massive sense that the five, very easy, I think, to kind of wrap your head around a very logical that I'm not sure if it goes into ways of working around cloud native, but that'd be kind of interesting to know, I guess they're teasing out the very specific principles that probably help you work in a specific way. So by proxy, but it'd be good to kind of understand if we kind of go into a bit more depth on like, What does good look like for a team when you adopt these things? But yeah, I think it's really useful to have a bit more because I mean, the thing I always struggled with was the term cloud. And then the term native would make you sound that you're native to cloud, and therefore if I'm in cloud, I'm cloud native. But you know, that's what, by proxy you'd assume, but it doesn't really mean that at all.
Right, well, we'll tease that apart in future episodes. But if you think about the five high level constructs or five principles that they they lay out: containerization, dynamic management, microservices, automation, and orchestration. Each of those implies some technological implementation, it implies a specific skill set to go along with that it implies changes in process or ways of thinking that go along with them. And so from that level, I think, if you look at it holistically, it's a very good summary of what it means to be a cloud native citizen. What does it mean for your applications to run on a public cloud environment in a native way? And I say public cloud, specifically, as I'm going to take the baton from you for, you know, King of segues to get right into our subject today, which is single, hybrid or multi cloud. Right. So Jon, this was something that you brought up on the last podcast, I think it's something that we definitely owe our listeners a deeper dive on. And just for the the clarity of the listeners, we spent some time putting together an outline on this subject, and holy moly, is it long
It is, I think it's very, very difficult. To be fair, and it was very time consuming really to to pick it all apart. Because it's very nebulous, isn't it really?
Well, and that's sort of the confusion, I think, where a lot of people land in trouble with this is because it is a multifaceted subject, there's a lot of moving parts is a lot of different desires or motivations that might sit behind why you might want to do A, B, or C, you know, so we're gonna pick that apart today. And I just want the listeners to know this is going to be sort of a super sized episode of the podcast, and we're aware of that, but just stick with us, we want to help you make sense of this very big confusing subject.
So in an effort to get started, what I thought we would do is just let's get our terminology straight. Let's make sure that we're all talking about the same thing because when you hear hybrid cloud, multi cloud and then you know single or all-in you know, you may have different ideas or different biases coming into that. What I thought we'd do is talk about that first, make sure we got our terminology straight.
And if it isn't correct, by the way, or people have a different definition somewhere that we've not clocked, you know, that might exist out there in the wild, then let us know because this is our understanding and interpretation really what it kind of means. But maybe, maybe this is the problem, maybe there are other interpretations out there, where everyone's saying the same thing, but what their meaning is completely different. So it'd be good to know what other people's definitions are.
Right. And it's an extension of what we talked about early on, when we were discussing building the team of making sure that you're all discussing the same things the same way normalise your vocabulary, we want to be both practitioners of our advice, as well as dispensers. So the first question is, what is hybrid cloud? And, john, I'll tell you what my definition is. And you tell me if you agree, my definition of hybrid cloud is a public cloud provider and your private data centre, operating in an integrated way. Do you think that's that's about right?
I would definitely agree with that. Yeah, I would say is a public cloud and a private data centre. Yeah. And or a private cloud? You could kind of argue, yeah,
yeah. Well, so we'll, we'll talk about private cloud in just a second. Right. So multi cloud when we talk about multi cloud, what my definition is, is more than one public cloud, operating in an integrated way. Yeah. I got a yes. I'm gonna move. Yeah. So here's, here's where this gets a little soupy, and hard to talk about, talk about to people is your definition of cloud is likely to vary a little bit. So for example, when we talk about private cloud, what does that actually mean? In a lot of cases, based on my experience, we're talking about privately controlled data centres that have, you know, a semi or very automated environment that encompasses both not only the application runtime, it's typically VM based, but it could be platform based. But beyond that, it automates and controls the service exposures. So not only can you define and run a thing, but you can expose it out to the world, you can actually direct traffic in and out of the applications. So, you know, that's one conception of private cloud. But again, there's lots and lots and lots of caveats that sit around what is private cloud actually mean. And in many cases, it means that you have a certain amount of your data centre that's automated. But then another piece that's still manually controlled, you have to submit tickets and people have to log into individual devices and go alter configurations. In my view, that's not really cloud, because it doesn't meet the bar of automated service delivery. Jon, would you sort of agree with that assessment?
I would, I would agree with that. I think it's bit of a bit of a misnomer in some ways to have the word cloud, which obviously, would, would make you think, you know, up there out there and ether, right? And then and then it isn't, it's kind of in your data centre, which kind of is slightly oxymoronic in some ways. I suppose, really, what they meaning is they run applications on their data centre. Maybe that isn't cloud, and that's just a private data centre and a private cloud would be exactly that is it meets the desired expectation of cloud where you have abstractions, and you can engineer against it, you can do the network and do Defined Networking. and kind of get an overall outcome with some automation.
Right, so let's take a practical example. So if you're today running completely in your privately controlled data centre, based on market research, there's a decent chance that that's VMware based, especially if you're a large enterprise, and there are now VMware, there's VMware cloud on AWS, there's VMware services on GCP and Azure. And really what they are, are bubbles, right within that within that ecosystem, but you know, instead of you owning the physical hardware, the hardware is owned and controlled by a cloud provider. It's on their network, but you fundamentally don't really have to change much, you just view it as another data centre in that construct and can move services around. But my question would be, is that really cloud? I don't think so, because there's been no operational transformation, you fundamentally have the same thing that you did before. But now, it's just the infrastructure, the hardware specifically is owned by someone else. But you don't have to change any of your processes, your skill sets, it's just a way to move a workload from A to B. Right. And so I would say, while those are valid in specific contexts, and we'll get to that in a second, I would resist saying that that is, is cloud. That's not the target state that you should be looking at.
It's definitely not going to bring any level of operational efficiency in the end, if you're just kind of moving a specific thing in the same, you know, in the same capacity of how you interface with it somewhere else, and you've just moved, you've just co located it really, haven't you? Co located that thing, exactly where else and that isn't, you know, 100%, right, that's not transformational is it? So you're not going to get the same efficiencies, as you would had you buckled down on Cloud.
Yeah. So another approach would be you have an application platform that you've deployed on prem. And you're familiar with that you have process and skill set around that platform. And specifically, what I'm talking about are things like Openshift. Or if we go further back in time, WebSphere, or something that is meant to be sort of an all encompassing, walled garden for your applications. One approach would be to say, all right, well, we already know that on prem, we have it deployed on our VMs here. Now, we're just going to go deploy that same platform on VM over there. And by over there, I mean, a public cloud provider, and we'll deploy our applications over there. And again, by extension, we don't really have to change anything. And again, I asked the question, is that really cloud? I don't think so.
It's just that this is I, I mean, we did discuss this a little bit, I'm gonna get into the nitty gritty of all of this work, we're gonna pull this apart a little bit. There are legitimate reasons for this, we kind of understand. But, again, when we're talking the previous episode, it's like, what is your motivation for cloud to begin with, and if your motivation for cloud was to, you know, reduce, risk, maybe have increased operational efficiency, release faster, get features out quicker, be more competitive, but all you're doing is moving something somewhere else, of which it's already how you work, but those problems epistemically is still there, then you still have the same problems, because you haven't overcome the obstacles by just working in the same way somewhere else. Right. So I agree. It's not It's not what cloud is there really to help you with? But it might be a legitimate reason of why you do it. But yeah.
Right. And I think that really sums up my perspective on this is, you know, there is a category of thinking or, and by extension, there's a category of tools that you provide that walled garden, or that bubble in the cloud that, you know, the tease of it is, yeah, you can get to cloud in big quote fingers (you can't see what I'm doing). But it's not really cloud, it's a bubble within the cloud, right? If you're not changing your processes, your skill sets, or the technologies, then this isn't really a transformational effort. This is a this is just a bit shifting effort, you know, you're moving things from one, you know, colo to another, it just happens to be that one of the colos. In this scenario, and again, colo in quotes, is a public cloud provider. So I don't think that that really satisfies the need. Also, to Jon's point about motivations. Typically, the motivation for going to public cloud is because the the private data centre environment and all the baggage that is associated with it doesn't work terribly well. So again, I would sort of question the motivation of why you'd want to do that specific approach: take private cloud technologies and push them to a public cloud environment. Is that actually solving what you set out to solve? Or is that just replicating your baggage in another form? Now, again, we'll talk about the the distinctions of like, why you might have to do that in some form and what the legitimate reasons are in a minute. But the other thing I want to call out right here is, this is sort of the origin of why I said in the previous episode that you should avoid infrastructure on the cloud, if you can. Because as soon as people draw the correlation to say, okay, well it's a VM in my private cloud, it's a VM on Amazon, Microsoft or Google. So why can't we just deploy the thing that we already know over there and call it done? You sort of have lost the fox, you lost the reason that you were trying to do this in the first place. And it prevents you from having to deal with those early impactful decisions that are potentially negative. And and keeps you on the path towards cloud proper cloud native, right?
Yeah, exactly. And I didn't those principles that you've just defined, you know, the automation and observability, etc, in the in the definition of cloud native. Unless those aspects are already there. For some, you know, some amazing reason maybe there was a platform that you've already got that is cloud native, and you kind of put it in the cloud, but you still need the cloud application services for your applications in the end. So it's like, despite the run running workload elements, the applications need more than just CPU or memory, right? They've got they've got dependencies, and they need databases need storage, they need, you know, maybe AI, TensorFlow, whatever is going to go on. So usually, you're going to cloud to consume those things. Well, those platforms don't give you those things, because they aren't the cloud. And you're running inside of that thing that isn't the cloud. So, you know, directly. So therefore, you're still left with the same problem of how do I get the cloud services for the applications anyway, so you kind of back to square one a little bit.
Right, and we'll touch on this in a second. But that's, that's more of a buying time manoeuvre than it is getting to cloud manoeuvre, right? It may be a decent interim strategy, which we can discuss it at length in a moment, but it's not the target state. And I do want to call out, sort of right up front. There's a lot of noise in the industry that talks around multi and hybrid and how this is, you know, sort of the core strategy of a lot of large organisations. And I think that can potentially send, you know, people who are new adopters to cloud down a bad path, because it sends a message that is, is potentially misunderstood. What I mean by that is, if you look at the broad swath of the industry, and you see that a lot of companies have a hybrid cloud strategy or a multi cloud strategy, what that doesn't really tell you is the intent behind it. Like the why. Why are they doing this? Right. And, and, based on my experience, my observation, I think the reason that you see a lot of companies pursuing this strategy is because it's a transitional strategy. They're in the process of working through some issues, to get them to, you know, cloud native, but they need time. I think it can be misinterpreted, sometimes, especially through through analysts. And again, this is like not a knock on Gartner, Forrester. Anybody else? But when they say that a majority of companies have a hybrid cloud strategy, they don't really tell you that, oh, that's part of a transitional strategy. They're not intending to stay there. If you just read the the analyst report, you could be misled into thinking, Oh, well, that's the target state I should be shooting for.
Yeah. And it might be that it wasn't an actual strategy. It's a situation, right? It's like, Oh, I acquired a company, you know, through acquisition, and that company was public cloud, but our company is on prem cloud, right? And now we're hybrid. And is that oh, you must be in our hybrid strategies. It's like, look at all these companies with this hybrid strategy. Like, No, that isn't a strategy. That's just a situation that I'm in. The situation isn't a strategy.
Yeah. Right. And so, you know, it's a little bit like that old thing that your mom told you, if everybody was jumping off a bridge, would you? You know, it's it's a little bit of a simplified version of that of just, yeah, I know that that's where they are today. But I don't think that's where they plan to stay. Right. And based on my experience, I mean, that it's so if you're relatively new to the cloud space and you're coming into it, you know, it resist the urge to sort of look at those analysts reports and say, oh, clearly, this is the target state. Right. They've defined it for us. And that's misleading. Right. It's about the transition and getting there.
So I don't know actually, to be fair, it'll be useful to know... I mean, I know I know all the 100 listeners are me but, hahha, if anybody out there has got data... because I think this is the problem as well as people talk about these things from such a theorised element, you know, but there's no data surrounding the value in the benefits. It's like, where Where is the data saying that hybrid is a good strategy? And a good strategy for what situation specifically based on what data? You know, and I think you have to be a bit more analytical about these things, which is what you'd hope, you know, generally, maybe analysts do have this data, I don't know. But it would be good to kind of know what it is because then people can be a bit more informed and be like, Oh, that is my situation. And therefore I can kind of see the value now because of this data. Right?
Dangit, you took the segway trophy away from me.
Oh, did I?
Okay, so he's now king of segways again. So really, that that leads very fluidly into what we were going to talk about is, you know, if for for hybrid, multi cloud scenarios, you know, there are wrong reasons to do it. And there are right reasons to do it. Right. We're not saying outright that you, you should never look at this, right. There are good valid reasons why you might want to pursue that strategy. But there's also a heck of a lot of just noise and bad ideas that surround each of these. So what I thought we'd do is, you know, really talk through first multi and then hybrid. What are the wrong reasons to do it? And what are the right reasons to do it? You know, what are the good motivations? What are the bad motivations? So, let's start with multi. So just set up the question, what are the wrong reasons to pursue a multi cloud strategy? And again, to reset the definition, we're talking about multiple public cloud providers, operating in an integrated way.
So DR. Let's do it. Let's just bit that off. Let's just say active active DR. Should we just should, we un-pick that, because that does come up. If people saying, hey, I need to DR situation, right, I need to de risk and be in one cloud and another cloud and at an active active or active, passive situation where I can kind of fail over. And then that has a really negative impact then on downstream application development and complexity somewhere else. Do you wanna? Do you want to pick at that, Joel?
Yeah, so I would say this. So there's one school of thought that says, okay, well, we can balance our risk across cloud providers, by saying, okay, our active is, let's say, Amazon, our passive is Azure, or our secondary is Azure. And that way, our applications are balanced across these two cloud providers. And if one of them decides to get snarky with us, we can always just sort of uplift and move. I would say, alright, let's unpack this situation a little bit. Number one, I don't know who started the rumour that, you know, just because you can deploy infrastructure across multiple cloud providers, means that, you know, suddenly, they work all the same way. And you don't really have to account for the variability between the cloud providers, that is I, whoever started that, and you know, who you are, I wish you would stop. Because that's not true. Even at an infrastructure level, if even if you're thinking about this, it's like, we're just going to consume lowest common denominator services across the cloud providers, even infrastructure doesn't work totally the same across the major three,
really API's for a start aren't the same. So I mean, that's already like, one footing of, you know, duplication of effort, because, you know, the API's are fundamentally different, even on the infrastructure. So it's like, so you still have to do the infrastructure code somewhat, because, you know...
I would even go one level down from that and say that the image formats are not the same, right? You can't even instantiate one in the exact same way. Even if you do, you're still left with all this world of configuration that sits outside the VM around logging, monitoring, you know, patching, you know, all this stuff, which we teased with the Microsoft announcement earlier, that is specific to that cloud. So just because you can create, let's say, a cue cow, that may translate well across the platforms doesn't mean that you can just boot it up and it'll work the same in all three contexts. It just won't.
I think that's a really good example, because we've just spoken about a preview feature in Azure, that brings together all of these facilities, you know, automatically for you in preview probably got a bit of bugs, but you know, it's going to mature and bring value. And now because you're multicloud that won't be in Amazon or that won't be in Google, for example. So it's then that well, now what do you do? Do you not take advantage of it at all? So it's not like they have like, you now can't get the value of the thing that somewhere else, because you've decided to kind of split across two clouds equally and trying treat them as equal.
And it's actually worse than that. Because when you go down that path, and you start deploying everything is infrastructure, and you start to rub your head against the fact that the ancillary services, the thing that sit around the VM are not the same, then it leads you to a further conclusion of, okay, well, our our logging system, we'll deploy that as infrastructure as well, right. And then you like buy, but it's a steady drip, drip drip of replicating your previous architecture in the cloud. And again, that's really not the goal. That's not the plan, and it will not provide the value that the cloud can provide you if you go down that path.
Yeah, definitely. And not just that, I guess. Then you get into the application complexity, you know, that's the next phase. It's like, oh, so if it's active active, how's my data replicating, you know, in the right way? How quick is that replication to give, like, eventual consistency, right? So then back to that other problem, then? And you're like, oh, well, how does this work? And how we're going to run? Right?
Right that gets to the if we're talking about the DR scenario, let's just take databases for an example. Let's say that, you know, your home base is Azure, because you have a high reliance on Microsoft SQL. You need highly available SQL databases. The thought might occur at some point, 'okay, well, if I deploy database replica on VM in AWS and I do the same thing in Azure, I can set up replication targets, as long as all the networking' (again, started turning into a bad word on this podcast) as you know, as long as I can set that up so that they can replicate efficiently, then we'll be good. But I would challenge you and say, is that really what you want to do? Like, that's not that's not satisfying the goal of why you wanted to go to cloud in the first place, because now you're just in managing infrastructure in another form. So who wins?
So I've got a question, though. Do you think ... I just literally thought of this, as you were talking ... Do you think the cloud vendors will try and target one another? A little bit that's already started to happen, right? Where there'll be like, actually, if you're in my cloud, and you do want this situation, you can run this database in Amazon now, right? It's like, or, you could run this other service in Amazon from Azure. Do you think that's the path, they'll start to pick up that will kind of exacerbate this current multi cloud problem in some ways where you're then running another thing, but paying twice?
Well, you're already seeing it in a certain sense, because you have technologies like Azure Arc, that allows you to extend Azure workloads into other cloud providers, or into your on prem data centre, you know, Google anthos is is similar to that. Amazon is doing it in a slightly different, it ways seems to be more selective, because also, let's just be clear about this, like, of the major three, Amazon has a very clear position that they are the only cloud. So they're the the Protestants of the bunch. I'll put it that way. You know, you can't be cloud unless you're with them.
I mean, they are the market leader to be fair, still.
Oh yeah, no argument there. They're just, you know, they have a very insular opinion of themselves and their services. But yeah, you're starting to see people cross collateralize workloads across clouds. And, you know, situationally, yeah, maybe that fixes a problem, maybe it doesn't. I would be really sceptical of that in a long term supportability scenario, because all it takes is somebody at cloud provider A getting sufficiently POd at cloud provider B, and suddenly that technology ceases to work.
Yeah, or the cloud will strike, you know, more so and then suddenly, you know, this thing doesn't work quite the same anymore.
I mean, at the end of the day, I mean, you're you are sort of betting that they continue to play nice with each other in that scenario, and I don't know if that's a good bet or not, I would sort of fall in. I don't know if that says something about me or whatever. But like, I don't know, I don't really see it. But at the end of the day, you're you're talking about extending workloads, and most of the time it's on an infrastructure level, and It's just not, it doesn't really move the needle, like we just did just changes the specifics of the problem from being completely contained within your private data centre to now. Alright, now we got it split across a couple of different environments, but it's ultimately the same problem, the same management headache that we had before, it doesn't really solve anything.
And I think if you're if you're going to, and this is why the infrastructure piece is really important, I think and not coupling in to your existing ways is kind of critical, you know, coupling into networks, coupling into your on prem stuff, because the minute you've done that moving to another cloud means you've got to duplicate all that coupling somewhere else. If you remove that when you get into the cloud, it becomes more about the applications. And those applications have to iterate anyway, right? Because there's new features, you've got to patch them. So there's always a team looking at that. So moving from one set of libraries of one cloud provider to another set of libraries with another cloud provider, or using library abstractions is much easier than trying to redesign the coupling, right, which takes forever, you know, and loads of change requests and all the other processes that go around it. So if the ask was, can I port to another cloud really quickly? Well, you don't necessarily need to be multi cloud to achieve that. You just need to design properly. So it's quick and easy to move. Right, right from the beginning, if that event strikes, and that's probably more cost effective and less time entombing.
I would argue that, that when we talked about the walled garden application platforms that you know, really started on prem, and then you know, people are extending up to the cloud, you're sort of effectively doing the same thing, but just an infrastructure level. If you only look at the clouds as infrastructure providers, you're building your own walled garden.
And that's not necessarily helpful because it doesn't bring any efficiencies. And it doesn't allow you to access any of the value of the additional services the cloud providers can give you. Because you're still in a mode of like, we're just going to build our little bubble. And you know, everything outside of that can go away.
I just had a flashback from the previous season. And the Jedi thing of just, you know, building the wall. Yeah, you no, totally building that wall.
Man, oh boy.
I'm sorry, I couldn't resist it. Yeah, anyway, let's, let's talk about the legitimate reasons for multi cloud.
Yeah. So what what are the reasons that you would want to? What are the legitimate reasons you'd want to pursue a multi cloud strategy? And I mean, the the first one, right out of the gate is, is choice, right? It's it's flexibility in selecting the right set of services that fit your application. And on that level, multi cloud does make a lot of sense. It does bring some complications with it. To be sure, right? Yeah. Because when you're anytime you're bridging platform, a, and by platform, a I mean, maybe Amazon, right to Azure, or GCP, where we're talking about bridging fundamental ways of working technical paradigms, and how things want to function together. But if you need that choice, for a whole bunch of legit reasons, then yeah, I can, I can see that one example. And I'll throw this out. And Jon, maybe you have some others behind it is, you know, if if you have a very global business, and you're trying to access specific markets, right, spin up workloads in specific localities, that maybe one cloud provider can't give you access to all of the localities that you need, then, okay, fair. I mean, that that's changing rapidly and most cloud providers are sort of matching like for like with their their regional footprints. But that said, you know, if you need it, now, you need it now.
Yeah. And there might be legislation that means you kind of have to host at a certain cloud, right, for whatever reason, as well, depending on what country you're in. And it's kind of like maybe there's some legislative issues there were so then be multi makes sense, because you kind of write a run over that now.
So we should touch on that. So there there are a shortlist of countries that have very, very strict data sovereignty laws, meaning that your workloads that relate to customers in that country cannot really be moved outside the geographic or political borders of that country. Australia is is one example. I believe Switzerland is another there are others, but those are the two that come in immediately to mind. If you're doing business in those geos, then you may have to have regions that are within the geopolitical borders of that country. And if your primary cloud provider doesn't give that to you, then you may want to branch outside of that.
Yeah, do you know what, I was thinking about this. And this is just a bit of a random, a random thought really out there. But the thing that I think is missing from this multi story, which would be great to eventually see is the companies like Mongo and Elastic bridging in to the current cloud providers. So you can tap in somehow, automatically, through some catalogue or something in some automation, so you can take advantage of oother services and cloud providers in some ways where it's very niched, and kind of go over there and kind of start to host things.
So expand on that a bit, because I'm not sure that I totally understand.
So if you wanted to go all in on Mongo, right, and you wanted to host on the Mongo as a Mongo service, but not necessarily dynamoDB, for example, on Amazon, to be able to still provision that through the cloud provider, because there is some relationship between them that enables you to kind of bridge across, but it looks like it's from the same cloud, if you see what I mean. So which is then fundamentally multi in a kind of abstracted way. But enabling this kind of, in some ways, a smaller players to kind of enter the marketplace of the bigger players in a way that it doesn't really okay.
So I think maybe let me reflect this back to you. And again, listeners may be doing the same thing. But it's, it's really about, is there a specific service on cloud provider A, B, or C that is more aligned to your use cases? But maybe there's another technology that doesn't exist on the one that is your primarthat you want to stitch them together? Right? So there's a there's a functional disconnect that where you want to have you want to have apples, but you also want to have pears.
Yeah, exactly. And if there's another smaller based kind of offering with, you know, do we classify those as clouds? I'm not sure, really, but they offer a service of which is hosted as a kind of SaaS offering, or most or a PaaS offering? And so like, what happens to those players? Why are they not represented in these cloud vendors to kind of bridge them back out? And I think it'd be good to see.
I think that's part of it. But the other aspect might be that there are differentiated services between the cloud providers that you may want to access, right? So one scenario might be alright, well, I've got a bunch of MS SQL, that's really core to one application. All right, well, you might want to run that on Azure, for that reason, right? On another level, you might have an application that is, completely, like, it wasn't originally written that way, but maybe it's just tailor made for Lamda. And you want to run that on AWS. You know, I those, you know, taking advantage of specific features, or for GCP, for for big data genomics, you know, stuff that GCP does really, really well, that may be the better fit for you. The issue is in integration of those environments, like you have to be really, really careful in my opinion, of making sure that you don't expect those applications to be tightly coupled, because if you do once you spread them out across those cloud environments can be very difficult to provide the same level of connectivity as if it was running in the same place. And I think that that expectation, you know, really speaks to the application architecture, and making sure that the applications that are going to be run across multiple cloud environments, if you're going to do that, have that baked into them. Like there's that expectation of service availability, latency, etc. Between those service components or those application components. Does that make sense?
Yeah, it does. It does make sense, I think you're back to the same problem that we kind of highlighted before, though, with the ancillary services of light. Well, now what monitors this, these things that are now fundamentally different places and slightly different technologies, to give me this holistic view. And I think, in truth, and I'm obviously biassed here, so apologies. But, you know, this is where containers, you know, as a kind of uniformed approach across all of them, that is really that that the leverage, in some ways at least then you can address that concern equally, right, as opposed to trying to address it somehow slightly differently and not really understanding how to do that properly. When it's very coupled to the cloud vendor, it can be a bit more difficult to achieve but not impossible, but maybe a bit more arduous.
Yeah, so we're we're talking about the legit reasons for why you'd want to do this. You know, if you do need features across multiple clouds, the consideration is that you, if it's let's say, the same application that has components scattered across multiple clouds, you have an application architecture problem that you're going to have to solve. Specifically, like how to integrate the communication between those components, if you can carve it up along functional lines, and say, you know, this application has a functional requirement for mssql, it can more or less operate on its own over here. Now we have an application that has a functional requirement for Lamda, it can more or less operate on its own over here, then that's another thing, right? But expecting all three of the cloud vendors, let's say, even if you have a network provider that's at a cloud interchange, that promises you very, very low latency between cloud environments, and you just won't ever know that there's a difference between the three. Yeah, be really sceptical, because that's just not fundamentally how this is gonna play out for you.
Yeah, yeah, I think that's it. And this is why it's hard, Joel, isn't it. This is why this whole topic is quite a difficult topic is it's not an easy, all these decisions and all this decision criteria that's kind of going into everything to kind of feasibly understand has some costs somewhere, right. And even when you're doing it from the beginning. And you're thinking, well, yeah, I've got this app, and I'm just gonna host it over here, because it makes sense. And it's doing this thing, how you got it has operational cost, how it's managed long term has operational costs, if you then go off and do a different thing over here, you're back to square one, where you're like, well, now there's like dual operational costs for two separate different things. And I guess it's then the measure of did the outcome, overall, justify the business value on now the operational overhead that you now have on these two different approaches? And I think that's the bit that you just have to weigh up. Because it might be that it's true, and you're not actually the values there. So it was worth it. Or it might be that in the end, you recognise actually, this is costing us too much money to run in these two distinct clouds. In the end, I don't know.
Yeah, I mean, that's, that's really it. There is no free lunch. So if if you're going to pursue, you know, either a multi or hybrid cloud strategy, then these complications are just intrinsic to, you know, what you're going to have to plan for. And, again, I would recommend, if we haven't said it already enough, if you're new to cloud adoption, and this is sort of your first pass, resist the urge to go down this path. At least, you know, first pass, because because their madness lies, your you know, the things things are going to get substantially complicated far beyond what you're already experiencing, if you try and inject this into the first pass of what you're trying to do. So I think from there, you know, we've talked about the the motivations that are invalid for multi. We've talked about the valid motivations for for multicloud. What are the invalid reasons or the wrong reasons to pursue hybrid cloud?
Right, so now, I don't know if you've seen this, I'm going to bite the first bit off. The the old adage of it's a checkbox exercise, if somebody said, we need to be in cloud, we don't really know why. Right? There's just some rationale somewhere that's like, not really tangibly linked for any explicit reason. Yep. So now it becomes a checkbox exercise, like, are we in the public cloud? Are we doing this initiative? We don't know why this initiative is there. But we know that this is initiative, and then low and behold, you kind of go off and do something in public cloud, you can kind of tick a box, oh we're hybrid and we've got public cloud, and we're kind of on prem, and this is progress. And I think it's like, well, that's not really a good reason, you know, fundamentally. I can't see what the motivation is for that. Specifically, if it's just about ticking a box.
Well, there is no motivation. At that point, it's the motivation of somebody to get their bonus. Really. That's it. Right. So, I mean, the second motivation might be that you talk to an analyst and they talk to you a bunch about well, a majority of our customers or what we're seeing in the industry is that, you know, everybody has a hybrid cloud scenario, or a hybrid cloud strategy, which is what I teased up front. That's also not the right motivation. Because again, that doesn't really tell you anything about the business context, the intent, why they're doing that and in my experience, it's transitional. Yeah, right there, they're solving some problem in an iterative fashion. But to you from the outside world looking in, it looks like they've chosen a target architecture. And it's misleading. That's that's not the target architecture they've chosen. They're moving towards something else. But that's just where they are now.
Yeah, it's situational. It's not strategic. Right. Yeah, I think that's fair. And there is that, like, you were saying the looming danger of copying others, you know, or being led by those accidentally, that results in new kind of been in this situation that was their situation, but now is your strategy. But it wasn't their strategy. So yeah, absolutely. Just following others for the sake of it, you got to do right for the business of your own and analyse your own business, right. So, you know, work out what's right for you, and try to kind of work out the best approach for yourselves rather than listening too much. Unless you can dig into the right kind of quantitative and qualitative information about why people are doing those things, then otherwise, try and stem away from just kind of following everybody blindly, really.
Yeah, exactly. And I think that that sort of translates down to, you know, from the, you know, sort of, it's a check box, but we don't know why, and there's no real advantage behind it. I think that goes to, you know, sort of a general thinking around, you know, well, we can't change the application, the applications too monolithic, it's too tightly coupled, we can't move that. So we need to, you know, somehow bring the cloud to us and, you know, make the cloud more work more like we do rather than the other way around. I again, I think that's sort of probably a quick win fallacy of, you're looking for things that you can do now, to change the state of affairs, rather than investing in a programme that's very systematic and moving the needle. And I think that's a pretty common symptom in most organisations is just like, you know, it's quick win after quick win after quick win after quick win, and somebody else is going to have to hold the bag on the technical debt. And that's problematic.
Yeah. And another thing, just to expand on that is, the cloud vendors never gonna complain about you running something in them. Right? So they're designed in a specific way, and you can leverage it, but they're also not going to complain if you're still running things in them, and they're never going to correct you to be like, 'Oh, you're not using those in the right way necessarily', because why would they? So I think it's , I mean, I'm sure there will be some cloud vendors if you've got the support, and you've got the professional services who could help you do it properly. But generally speaking, you know, you might think that it is the right way, because nobody else is saying otherwise. But you're running something that you've already done, and then just shipping it over and continuing to work in the same way, like we're saying at the beginning isn't necessarily capitalising on the cloud properly?
No, it's not particularly and for a lot of the cloud vendors, they have a notion of a workload review, is your utilisation of the cloud storage ramps true, right. So they'll give you an idea of, you know, here are the things that you should do to improve your utilisation of cloud. But again, if you're just you know, gobbling up infrastructure resources, which are, you know, traditionally, in most cloud providers that the most expensive things you can do, they're not going to complain, they're going to, you know, they might give you a pointer here or there. But if that's if you want to continue to throw money at the problem, they're not going to stop you. Yeah. Another, you know, wrong motivation for hybrid cloud is potentially the wrong people led the first exploration to into Cloud, in the way that we were talking about became infrastructure obsessed. Yeah. And really, the idea of cloud as a colo, or just another DC took hold, and now you're trying to upseat this notion.
Yeah. And that's, that's the classic, you know, they're building the world that exists for them currently somewhere else, because that's the world they live in. Right. So it's like, well, this is how I see it, rightly or wrongly so. In this instance, wrongly so right, because there's a wrong reason. But they're doing it that isn't valuable to the business in the end. So you got a question? Like, what's the business value in repeating the same thing somewhere else? When you don't have to do it that way? There are better ways.
Yeah, seeking a new colo provider or something like that. That's just not the right motivation to pursue hybrid cloud. Right? Yeah. You shouldn't go down that path. Additionally, and this is something I've seen, I'm not going to turn this into storytime,
Oh, no story this time, Joel? Letdown!
Well, I, again, I just, you know, I'm trying to be nice here. But, you know, I have seen people and heard people talk about, you know, like, Well, our, our data centre is more secure than the cloud, like we're better at running security and networks, then than Amazon is. So, you know, we can only put low trust assets out into the cloud, which is bonkers.
Well, you know Joel, it's because, you know, it's because they own it. Right. So it's more secure. There you go! It's owned by them which means is now more secure. Right?
Yeah. I mean, and, and effectively, that's what it is, is like, don't touch my molehill. Like I have authority. I have control here. And because I have control, I now have a better feeling about the level of security in sort of an abstract way, whether or not that is true or not.
Yeah, and it's the staff situation, as well, as now I've seen that one. It's like, Well, you know, these aren't our staff that run this run know, all of this infrastructure. So, you know, there's massive risk here, how can I trust the staff, which is running the infrastructure of which my application and my data sits within if they're not ours? You know, so you're like, looking at it from a people perspective, not an actual engineering security perspective of what's actually been done? So yeah.
Yeah. 100%. And I would just combat that opinion with by saying, look, the UK Home Office, US Department of Defence, you know, numerous critical government infrastructure companies, including power stations, electric companies, water providers, etc, in the US. up to and including the the Jedi contract that we talked about before. You know, they're all looking at cloud as secure resources. So you have to, you need to take a big step back from this, take a breath and say, okay, if they're looking at this as a mechanism to run those types of workloads, do I think that I am smarter than they are?
You know, I do understand from most large enterprise perspective, you know, they've had experience at some point in the past where resource, their resources have done bad things, right? And they put processes in place to lock down and control who can do what and when, to make sure that everything's really locked down, I would just say, look don't assume that the problem that you've had with your resources somehow translates to the cloud providers, and that they have the same problem. Because I will guarantee you they don't. They have a better process and a better mechanism for providing those types of services than you do, primarily because it's their primary line of business. You're running a data centre as a support line of business. It's not fundamentally what you do.
Yeah, yeah, definitely. I think there are some edge, very edge, cases, obviously on the sensitivity of data is some of those departments obviously, you know, if you've got some extremely sensitive data, I can kind of understand, you know, as in like, you know, critical to life situations. If that data kind of got out in the wild, then you can kind of, but I guess that's the premise, then you have other things like outpost or other services, where you can still have the same experience as cloud and actually make it the same look and feel as normal public cloud for on prem?
Well, and if you do have those requirements, if you have stuff that just can never, ever get out into the wild, that crap is air gapped, anyway.
So it's never been a candidate for cloud to begin with. So it's out of scope for this discussion, and why are we still talking about it? Oh my God, my head's exploding. You know what I mean? Like, it's sort of like, that's, that's an edge case.
It is an edge case, absolutely.
...thahat really leads into the legit reasons for hybrid cloud. It's you have data that legit, can't ever go to cloud for some reason. And it's got to stay in an air gapped state. It has to stay, you know, within, you know, it has to say exactly where it is right now. And that's just the end of it. If you have that case, fine. But I would argue that most companies don't.
But also, don't make the exception the rule. All right.
If 2% of your estate is this yet, 98% of your estate isn't, don't then force everything in this hybrid model. You know, like the cost of everything we're now going to be doing this strategy because 2% of our businesses is this, so we want a consistent strategy. It's like, Well, then, you've now demised 98% of your estate from kind of capitalising on value for the sake of 2%. Why would you do that?
Yeah, yeah, exactly. Like put it into risk buckets. Right. Like, like segregate your stuff as much as possible. But yeah, I would just say like, I think there is a general tendency ... And again, we should probably have a noise for when we say something controversial. I'll find that.
That's the entire podcast, Joel, you'd never be able to talk.
It's just one long bleeped out thing. Yeah, but I mean, every enterprise, every large enterprise I've ever interacted with, when you talk about technology A, B, or C, at some point, somebody waltzes into the conversation and says, 'well, we have unique constraints.' No. You. Don't. I don't know who started that but seriously, stop it. Like, I know that you think that you're like a unique snowflake in the world, and that you have requirements that nobody else does. And I think for like, 1% of companies, that's probably true. But if you're just like an insurance provider, and you think that you have, like, super specific, unique constraints and things that apply only to you, uh, you haven't spent enough time in the industry, because it's all the same. Right?. And, and the cloud providers know that they crafted services for you, knucklehead! So don't don't think that somehow you're immune from using this stuff, because you think that you're a special snowflake anyway. Alright. So that ends Joel's...
Just jump off that soapbox, Joel.
So that's, that's the end of Joel's rant corner. And we now move on with the regularly scheduled programme.
I think that's fine. I think I one thing I will say is, in terms of legitimate reasons beyond this, obviously, that snowflake one isn't. But in terms of the ones that are is the data set thing. So this is something I have come across where companies with exceptionally large data sets, you know, it's very complicated, shifting that to the cloud would be very expensive, unless they're going to do some amazing deal for you on that data. But really, you know, do you want to be shifting all this data is very complicated. How do you design for it all in the right way? So I can kind of understand bringing a way to run workloads close to the data makes a lot of sense.
So that's a legit reason.
So you've got a lot of data on prem, your data, gravity is there, but you might want to move application components closer to that so that they can deal with the data. But fundamentally, all the rest of the logic stuff can go somewhere else. Yeah. Is that , effectively what you're just saying? So I've definitely seen that. And it generally boils down to like, again, data sets that aren't easy to separate, where you've got a bunch of different concerns commingled, where previously, you had a monolith, maybe you're breaking that up. And there's not a clear separation of concerns within the data. Maybe the logic is easy to split up. But the data is even harder, right? Because it's like it's grown over time. Yeah. And so the the data structures just don't lend themselves well, at least at that stage, to getting like split up where you can take one piece of it and move it out and leave the rest of it here. That is absolutely a valid reason.
Oh, I guess if you're transitioning, like we keep saying, you know, if you're in a situation where you're transitioning a very complex service over to the cloud, and you're now bridging two things, you've got still got the old that needs to work and the data, obviously, still being fed in from users on your old system. But you're trying to decouple the old system into a new system move to the cloud, then you are technically hybrid, because you're kind of having to you can't switch it off. It's a transitional improvement.
I would say that that's 99% of companies that find themselves in a hybrid strategy is because they have that that legacy baggage where, you know, it's making money for the company. It's not a trivial application. That thing has to stay running.
And they're going to refactor it, you know, little bit by little bit over time to get to the cloud, but they've got this big boat anchor of a thing that they're trying to chew through slowly. I think that's 90 + percent of the use case around hybrid cloud.
But again, not a strategy but a situation, isn't it? And I think that's the thing is, like, your strategy is still really kind of cloud, you just so happened to be hybrid on the transition to cloud?
Well, yeah, I mean you have a hybrid cloud strategy. But what you don't say is the actual strategy is to get to cloud, right, you know, like hybrid cloud is, is like we're passing through this town on the road on our way to cloud proper. I mean, the other one, and I'll just say this, having worked around insurance and financial services for a long time is mainframe. A lot of them still have mainframes around it's core to how the business actually works.
And extracting that logic is not so easy. Because A) it's in a language that a lot of developers don't understand these days, most of that stuff was written in COBOL. Additionally, they probably have contracts with, you know, mainframe providers, or maintainers, that they have to tail off. And so they're, they're working iteratively to get away from this mainframe centric model. That said, if you're in that transitional state, and you need some portion of your applications to run right next to the mainframe, because it has a certain expectation of latency or, you know, communication patterns, then that's another completely valid reason to pursue hybrid cloud. Again, albeit in a transitional way. I wouldn't recommend that you just sort of like, plant your flag there and stay put.
Yeah, and another thing, which is really unusual. I'm not sure if I've ever seen this, rarely, but I guess it is, I guess it's a legitimate reason is that you're going for consistency over commodity. So it's like you've built teams, like all your business works in a specific way, , all the teams are educated in a certain way. And you also have the internal capability to build, run, manage support, you know, develop. You're happy with the cost of total cost of ownership of that, you're happy with the operational cost of all of that, because that the consistency outweighs the consumption of commodity in the end, and you're prepared to, you're prepared to look at it in a financial way or an outcome where it's like, well, actually, that's, we can still move faster in our old ways in a new ways, and I'm prepared for that. And I'm designed for that, and therefore it's fine.
Right, yeah, and again, this is sort of like an executive level decision. But you know, if maintaining your existing skill set, and making sure that you have a sort of a long tail of that to make sure that you can transition very slowly, one thing down another thing up, then then that's a that's a valid reason too. where I've seen that, in the most part is in companies that are not existing in in disrupted industries. They're very static, they're very stable. They don't have to, you know, they're doing this on a very strategic slow level.
Yeah, I guess, maybe COVID has had an impact of that. Really, you know, I guess this current situation, that's just happened, the pandemic situation, there's probably ruffled a lot of people's feathers, you know, and that maybe this is now a thing that's kind of it's all been unearthed. And they're like, Well, actually, now, this isn't a strategy. Right? We do have to fix this.
Well, I think, you know, like, it has, in a certain sense, because I think people have, and by people, I mean, primarily tech executives, have realised that all this noise that they heard about, oh, it's nice to be in the cloud, it can do all this stuff, like all the benefit messages that they've heard for years, suddenly hit like is suddenly resonated when COVID happened, and they had to distribute their workforce. And now they see it. And so I think on a certain level, the ones that are more, maybe literal, or sort of like focused on solving the existing problem or looking at it as like, Okay, well, we can do VDI, and we're going to go all in on on VDI, and make sure that everybody can work from anywhere, if that has to happen. And I think the more forward looking ones are looking at that and it's like, Yeah, but that's an indicator of things to come. Right? And they're starting to look at, alright, how do we distribute our operations generally. And cloud is literally the way to do that.
So I'm gonna, I'm gonna be I'm going to segue and use this this segue here. of like, shall we summarise like, what is really the true if you are going to do hybrid What does it really mean? In the end for your business? What are the markers and decision making criteria to kind of assess by to be like, you know, if I'm looking at this, we've said a lot of information here. You know, we've covered a lot of ground, we've talked about multi, there's a load of information to digest. We're talking about hybrid - the do's and don'ts.
How do we quickly understand, you know, the positioning of how to make decisions on this?
Yeah, to summarise I would say, if you're going to pursue a hybrid or a multi cloud strategy, but I think this is more focused on hybrid, know why you're doing it, make sure that you have a business outcome, or an objective that sits behind your desire to do it. Not just because it's shiny, not because other people are doing it.
Yeah, and not because of the buzzwords as well, right? Not because of the marketing. I mean, obviously, marketing can be helpful if it's the content that kind of helps you make a decision. But if you're led by the industry overall, and that isn't necessarily led by your business like you're saying, then try to focus inward rather than outward on the problem And be like, actually, you know, does this make sense? Do I have the engineers? Do I want all of this cost of ownership long term? Is my business, really a hosting company business? Well, I always get the investment to sustain this right from investors or from from the chairs. Are people can listen to me when I'm saying, 'hey, we need more money to underpin the development of our of our company. But we need to also keep maintaining thisbecause we got the total cost of ownership of this thing that we've now built, you know, for this hybrid model that's now costing us money.' You know, and these are all the considerations. Look, you have to look futuristically, don't you really. You've got to look at the long term. Not the short term. So yeah.
And I would say, you know, when we talk about marketing, I would say, put analysts in that same bucket of, yes I know that the analysts have a bunch of information that they can provide you. But at the same time, you know, that's very generalised. Right? And I would say if they, if they recommend that you pursue a hybrid cloud strategy, it's an entirely reasonable follow up question. To say, why?
And you're comparing us to other people in the industry? Why are they doing it? And also, how long are they planning on staying that way?
Right? I think that's a really good question to ask. I mean, ultimately, at the end of the day, if you don't have a lot of confidence that you can build an on prem environment that is as feature rich and stable, and programmable, as one of the public cloud providers, then I would read it and really think about that for a second. If you don't think that you can do that. And there's long term long term support for doing that, then I would say, Why are you in that business to begin with?
Hmmm, and eyes wide open as well, like, go eyes wide open. They're not the same, right? So it's like, the minute you read it, you recognise that my on prem is not identical to the public cloud? Well, that means there has to be a level of compromise now, right? Because it's like, I can't run an application on prem the same way as I could run an application in cloud when it comes to their dependencies. unless I am managing those dependencies myself. And I go to host and manage them in a similar way as on prem to in the cloud, that's compromise, right?
And can can you actually do that in a sustainable way? Like, it's one thing to do that for a period of time, and everybody gets really sort of amped up and thinking that, you know, well, we can build this and we can run this but, you know, like, be honest with yourself, like that you your interest will wane, right? You will get interested in other things. And your interest in maintaining this environment over time will go down and down and down.
Yeah, I'm not sure it's just that though, think about the technology, like the velocity of new tech. Right? It's like how on earth are you gonna keep up? You know, the cloud vendors are designed to keep up because that's their business. It's like they're investing the money to keep up.
Yeah, yeah, that was my point about you know, yeah, security and such. It's like you, you're never gonna keep up with the cloud providers because that is their line of business. That is what they do. That is their core competency. You're doing it as a sideline. Let's be honest. Right? And you know, unless you think that you can staff up and you can do that, then I just wouldn't even, like bother at this point.
I think this is maybe a good transition towards Jon's analogy moment.
I mean this is a really bad analogy by so I am apologising in advance to all the vegans out there. Because this is a vegan analogy of like, when you when you make a decision for something and those decisions, you know, are based on, you know, truisms for legitimate reasons, is really bad, to be fair. But if you're, if you're going to compromise like hybrid, the same ways you've compromised are no longer eating meat, you can't now have the same selection of choice, right? So it's like, so I've gone from having lots of choice to now having diminished choice. And unless the reasons are legit, which, obviously, they could be in this situation, then that's fine. But if you didn't really choose to be a vegan, you know, and your choice is diminished, then I guess you're not gonna be as happy anymore, right? Because you're like, I can't eat out in the same places that I used to. I don't have the same selection of the menu that I used to so that, you know, if you make the decision, you make it wisely. And that was kind of my lame comparison. So apologies out there to vegans for that, but that was my bad analogy. There we go.
This has been Jon's Curiosity Corner. Thank you for tuning in. Next week, we'll discover ways that you know, dog food can impact your technology choices....
That's assuming anyone else is gonna tune in now, after that analogy!
This is my NPR voice. Welcome to NPR. Alright, so anyway. Yeah. I mean and I think it makes a lot of sense, at least to me, like, you know, you're there. Again, there is no free lunch, you're not going to find that somehow combining cloud resources or doing things in in that way is going to get you further than me making some strategic choices. Right? And I think if we had to boil it down, it really boils down to understanding your motivations, right? Because there's, in this industry, there's going to be no shortage of noise trying to get you to take one approach or the other.
And at the end of the day, the only way you're going to really slice and dice all this information that's coming at you is to understand: what is my motivation? What problem is it that I'm trying to solve? Not only today, but also maybe 12 months out. And if you if you have sort of like fuzziness about that, then I think that's probably something you should take back to the team and say, 'Okay, look, I know that we're trying to solve X problem now. And the deliverable is clear. But are the actions that we're taking now going to set us on a trajectory to be sustainable long term? Or are we going to find side effects? Are we gonna get sidelined into some of these other conversations?' I would say, you know, that's a valid conversation to have, but don't let it distract you from your immediate deliverable. If you're new to cloud, of getting the first thing running, getting the first thing running is absolutely the key because it unlocks so many possibilities, and, and, you know, things that you can discuss and ways of working.
Yeah, and that's that, I think, once you know, the other thing is don't forget to modernise, you know, in the end, because if you know, I have, I have kind of seen this with the velocity motivations they're on, like, we just need to get to the cloud, we just need to get to the cloud. And it's that stepping stone, just like, we don't care, we're not going to do it as well, as we know we need to do it. We're all in a rush times time is of the essence, we're compromising on lots of things, we're going to compromise on best practice, we're gonna probably compromise on a bit of security, you know ... don't forget to go back and fix those things. So when you're in this kind of hybrid model, and the motivation was exiting, you know, very quickly, and you still maybe got a bit of on prem, but then you've moved to the cloud, make sure you fix that up and have a plan of action to go back around that so that it is at the maturity level that it needs to be long term. And don't forget about it, because I have seen cases where people, you know, the velocity drops, you know, the panics over and then the momentum gets a bit lost. Right, and people don't go back through. So yeah.
So the question is, if you have to go like multicloud is, I think, pretty far downstream for most people. Right? It's it really boils down to service selection and making sure that you can get the services that you need. We've already talked about segregating concerns where, you know, we don't have application a single applications components scattered across multiple clouds. And, you know, trying to avoid that as an initial step. If you are going to implement hybrid cloud, what's the best way to do it, in my view, it's not to take on prem technology, and try and push it towards the cloud, like we were talking about with openshift or WebSphere. Other, even VMC on AWS like things that create a walled garden or a bubble within the cloud, is to take the cloud providers, notions of what hybrid cloud looks like, it's basically taking cloud and extracting a piece of it and putting it in your data centre. So that it falls under common management paradigms. It has the same fit function form as what it would in the cloud. And and putting that in your data centre and using that as the hybrid cloud way of working. Right, take cloud first, and then bring it to you rather than taking private cloud to public cloud.
Yeah, 100%. Spot on. I totally agree with that. And that is probably the biggest thing that you know, I've kind of seen is it's the wrong, it's the wrong way round, not the right way round. And now Luckily, cloud vendors are extending, aren't they into, they're extending themselves, they have newer services that allow for the extension for them into you. Some of the more mature than others. And obviously, it's a it's a work in progress. But, you know, the movements happening, isn't it now that set the wheels turning? Absolutely. That's the path things are going down. And I think over time, well, we could segway to your future predictions job, because I know you gave me some of your future predictions. So I don't know do you want to give you a future predictions of why this is so important?
Well, before we get to that, I wanted to talk a little bit about practically speaking, when we talk about taking a piece of the cloud and putting it in your data centre. And that being the sustainable way to go. What does that really mean? So for Amazon, what we're talking about is outposts, as well as EKS-D, and EKS-E, right. And those are specific to Kubernetes. When we're talking about Azure, Microsoft Azure, we're talking about Azure Stack and Azure Arc. And for GKE, we're talking about Anthos. In all three cases, what we're talking about is a technology that you put in your private data centre, that is really an extension of the cloud. So rather than taking your private cloud and trying to extend that through Herculean effort and make it work properly, just take a piece of the cloud, put it in your private data centre and let it fall under common control and common management. That is the the correct path, in my view, if you're trying to satisfy the hybrid cloud concerns that we were talking about before it now in a couple of cases anthos and Ark specifically, they have capability of running Azure and GCP workloads in other public clouds, which is a bit unique, it has not been tested. And I would say, at this point in time in 2021, give it a little while to see where that, you know, like how that bakes. Because I think it's there, there's a real potential of that not sticking around long term. So I would say be sceptical of those, but the stuff that brings things, you know, in a hybrid cloud way thing that things that bring things into your privately controlled Data Centre. I think that's, that's pretty, pretty well baked pretty good. I wouldn't question that too much get into the future predictions that Jon was talking about.
Here we go...
Again, this is just you know, like, I'm putting on my Carnac hat here. That you're seeing a lot of companies with hybrid cloud as their current strategy. I think that's a transitional moment. I think what we're seeing is a lot of companies in transition. I don't expect that will be the case five years from now. I really don't
You know, I've got to agree. I mean, you know, I'd love to be more controversial than argue that case, but unfortunately on this one, I agree with the fact that I think what will slowly get recognised is I think businesses over time are going to become much more application centric and less infrastructure centric. And as that starts to happen, this whole being hybrid and why I need a data centre, you know, that's slowly like the importance of it's going to be removed. Right? And it's then be like, well, actually, I suppose I really don't wait to get business value, I don't really need this. That'll take time. And who knows with you know, all these? I guess though, would you say outpost? You know, when you do Azure stack? And you put as your stack on prem? Or you do outpost on prem? Is that hybrid? Or is that multi? Or is it just one cloud?
Why I think it's hybrid, because based on our definition, at the beginning, it's a public cloud with a private data centre.
So I've even forgotten our own definition jellies, we've been talking so long, I've lost that any sense of anything anymore! So yeah,
but my thought is, in about five years, most companies just won't have that strategy anymore. And it'll be because they either fully transitioned to the cloud, or they, you know, remained completely on prem. And there will be a Grand Canyon sized gap between the two. And I think even more than that, what we're seeing from a skill set perspective and where people are training themselves for, nobody's training themselves up on like, legacy data centre technology. Nobody's doing that, like the overwhelming weight of certification, education, everything's pushing towards the cloud. So I find it hard to believe that, you know, that's going to be the focus going forward, I think most companies have already recognised or in the process of recognising that that is not part of their core competency. And they're going to move it out. Because again, they're financially motivated. They want to drive either, you know, shareholder value, or top line growth. And sometimes those are correlated, but you know, it's just like, the overwhelming weight of business, you know, momentum is going to push some of that stuff out the door.
Yeah. And it'll be like, it'll be like those traditional mainframes and COBOL. I was saying, like, the COBOL engineers, you just can't find any more mostly that most of them are retired. That's why people are recognising, 'hey, we've really got to do something about this now, we can't even hire the skill.' That will probably be what will happen over time with with data centres, these on prem legacy, what will be legacy then, you know, technologies that nobody really knows about anymore, and you can't find a skill set for love or money. You know, that's probably what's gonna happen, right?
Actually is time for storytime.
Oh, there we go!
Yeah, so I met a guy. This is probably 10 years ago.
Do we get a name?
No, nope, not gonna give a name. But I worked for a manufacturing company. And this guy who I just stumbled over, like, I didn't intend to meet him. He was in charge of the boilers that ran the heat at a specific manufacturing plant. And he had been there for 40 years. And he knew the boiler system in and out, he knew everything about it. And, you know, it was interesting, because I was talking to this guy, and he had real passion for telling me all about the boiler system, and how the steam travelled and all this stuff. And it was fascinating. But at the same time, I sort of wondered, like, 'oh, you don't really have much of a career path.' Right? Like, this is this is, this is like the terminal career path for you. Because and it wasn't even like five years later, you know, that facility closed and moved into a different location. And it was not steam heat anymore. And it's a little bit of like, recognising, like, what is the what is the steam heat in your area? Right, because he was really talented. No question about it knew everything about it inside and out. But it became no longer relevant. And because he planted his feet and said, 'you know, this is what I do.' You know, his relevance to the business was almost nothing when it left. And you know, that's the hazard that I think we all face in an industry that has such high momentum and such high rates of change, is we all are in danger of becoming the boiler guy.
The boiler guy. I've got to caveat - I don't mean to be mean, but was it really that interesting when he was talking about steam boilers?
I found it really interesting. I thought it was really fascinating. Talking about like, just, you know, like he, you know, I don't know, I thought it was really fascinating, but I did feel for the guy because it was like, Oh, you've chosen a path you are now planted in concrete in place. And you like, that's, that's the end of the road for you. And I, you know, if we, if we tie this back to, to something that's like purely tech. You know, like, I worked for another company that had an entire team that was focused around their mainframe, right. And they had a strategy to deprecate the mainframe, and their strategy, which I think was great. Actually, their strategy for deprecating the mainframe completely targeted the team that supported it and said, okay, in five years, the last member of the team will be eligible for retirement, and at that point, will retire the mainframe, right? So they took up completely human approach, deprecating the technology, but at the same time, it's a little bit again, it's the it's the boiler guy, right? It's, you know, if if you tie yourself too closely, and you hug a particular technology too much, and tie your, your market value to that, it doesn't always read up to your benefit. So when we think about, you know, hybrid cloud, specifically, like public cloud, you know, how that interaction is going to work long term. And, you know, when I say my, my prediction in five years is nobody's gonna care. You know, if you're in a position where you're not adapting your skills, to be more focused around public cloud, I would really, really encourage you to do so. Just because, you know, I want you to be relevant. And I fear that you won't be in about five years, like five years in this industry is like the Ice Age.
Yeah, it is. And there's no reason not to, right? There's so many courses, so much information out there. You know, it's it's so easy to get going. There's free credits on stuff, you know. I totally agree, I definitely invest in kind of crack on and start that get the ball rolling and start putting a bit of a plan together to upskill.
Yeah, so given that, our massive supersized episode around single, multi and hybrid, are we good?
I mean, I think we're good. I think most people have gone to sleep and woken up and we've still been talking to be fair.
That's totally fair. All right. So on next week's episode, we are going to talk about cloud native: what does it mean to be cloud native? The value that it brings to a business, and also what does it mean to be cloud native from an infrastructure or an operations point of view, as well as from a development point of view from an application development point of view. So as always, if you have questions, comments or other feedback on the show, we would love to hear from you.
Please rate us and review on your favourite podcast app. You can tweet us at @cloud_unplugged unplugged on Twitter, email us at cloudunplugged email@example.com or, most recently, find us on YouTube at Cloud Unplugged for episodes, transcripts, and even some bonus content. Thank you so much. Thanks for listening. We'll see you next time.
Transcribed by https://otter.ai