30. There are Too Many Clouds – Tech Field Day Podcast

The cloud is not a place. It's many places. Businesses are navigating market of multiple clouds and deciding to where to place their applications.

This episode of the Tech Field Day podcast features Magic Vish Jack Poll, Justin Lauren, and myself, Alice Cook. Stay tuned as we find out whether there really are too many clouds. Welcome to the Tech Field Day podcast, where we bring together a group of it technical experts to discuss a single idea about key concepts in the industry.

This podcast features a variety of perspectives from members of the Tech Field Day delegate community, and is often recorded in association with one of our events. Tech Field Day is part of the RUM group, and this podcast is also published to our sister company's website, text on tv. On this episode, as we head into cloud field day, we'll discuss the premise that there are too many clouds before the discussion with meet today's panelists.

Hey, my name is Maek. Uh, I'm, uh, running a small, uh, architectural shop in Poland. Um, working with the Clouds for the last 20 years.

Well, um, mostly as a tech and, um, VMware, uh, with a VMware background. Hi, I'm Jack Poller. I am an former engineer turned, uh, marketing person, turned industry analyst, and I have recently launched my own firm as Paradigm Technica, and I'm glad to be here and join everybody in this discussion.

Hi, I'm Justin Warren. I'm the principal analyst at Pivot nine. Uh, we do a lot of, uh, technology analyst, uh, work and, uh, media marketing for vendors.

And I'm Alistair Cook. I'm an event lead at Stick Field Day and leading Cloud Field Day 21, which is starting tomorrow, 23rd of October. So this idea that there are too many clouds is a little bit of an interesting one because there's a bit of an idea that the concept that there were, there was a market in the world for five computers that was back in the, the 1970s was a statement from IBM seems to have been that there was a market in the world for five clouds only.

There's more than five clouds. As you start looking beyond the, the massive hyperscale, uh, infrastructure providers, there are more options for where you might run your applications, where you might build your applications. And this might end up being really confusing for organizations.

Where, where do they choose to put their applications? Why would they choose to place their applications on one cloud versus another? Getting into a situation where there's just too much time spent analyzing and thinking about where we might place our applications.

And then they were all different. Every cloud has different sets of technologies, different APIs, different philosophies of how they're gonna bill you. How the heck do we make our way through this Maura of confusion, I think that there is a place for, uh, for everybody on this market.

You know, I remember the talk that mainframe is finishing, you know, like it's, uh, happened like 30 years ago, blah. It's gonna go X for X 86. You know, it's, it'll take every year, all the market, but suddenly, you know, X 86 just grow up, uh, near mainframes and the mainframes are still good.

And same with, with the cloud vendors, cloud, uh, uh, cloud service providers. There are so big market for them, and there are so many different use cases. Uh, I believe that yes, there are too many, but there are too many because of the reason that different customers have completely different needs and, uh, different vendors in the sense cloud service provider address them differently.

I think we can sort of, I look at it and we can take a look at it sort of from the vendor, the cloud vendor perspective and from the customer perspective. And, you know, from the cloud vendor perspective, you have the concept of, you know, really supply and demand. Do I see that there's customers out there that are willing to buy the services I'm providing?

And if so, and if I can provide a service that I can make a profit at while providing that to somebody who wants it, then I should be in that business. And, you know, at some point we may see a collapse on the vendor side, a consolidation or vendors going out of business, but clearly right now they're able to either invest enough capital and continue, continue to operate or make enough money selling cloud services. So why would you say that there are too many?

If they're able to do business right then, you know, from the customer, from the consumer point of view, from the businesses buying services in the cloud, then that leaves you with massive amounts of choice, which is both good and bad because it puts you in a situation where you may, as you said, Alistair, get into analysis paralysis rather than taking action. Yeah, I've, I've long said that cloud is a state of mind. It's, it's not a location.

So I, I think it's, it's still a carryover from the early days where cloud became popular. So everything became a cloud, and we, we see that with every new technology. The, the marketing label gets a applied to everything, whether it's appropriate or not.

I think we are still living with the long tail of that, which isn't all bad. I, I think what's, what we really need to be doing is looking at, well, what does a cloud mean as an operating model? And then we use that operating model wherever it makes sense.

I don't think that's necessarily a challenge if there's too much of it, but I mean, too much is bad for you because that's what too much means. I think the issue we have with customers that there's too many clouds is exactly what you're saying about is it's a complex decision because I'm trying to pick between a whole bunch of different versions of the same thing that, well, that's fine as long as it meets the requirements that you have, which again, should be about the operating model. So as long as I'm operating in a cloud-like fashion, it kind of doesn't matter which one you pick, if it does what you need, Right?

But then, then the other side of that is, does it do what I need in all situations and do I solidify my entire business on one vendor or maybe two vendors so that I'm not locked into one vendor, but then I look at it and I say, but I have this one specific need that would be much, much better over on another vendor solution. So do I switch, do I, you know, expand my environment to have three clouds, then four clouds and five based on my needs? And then it, you know, so there's, it's, it's not as, from a consum from consuming cloud services and, and operating the cloud, it's not as simple as I'm operating in the cloud and so this one thing provide meets my initial, uh, uh, requirements, and therefore I can just continue marching happily down that path, right?

It's a little bit more complex than that. And I think that that comes back to the fact that these clouds down to commodity. You can't just take the application that ran on one cloud and lift and shift it into another cloud.

The way you could take a virtual machine from one platform to another, if you're using the value of these cloud platforms, you, you're using unique features in them. And unique feature also translates to vendor locker. These are the same thing.

They're just looked at from a different angle, right? So if you're not getting the ma maximum value outta a particular cloud, then you can easily move from one to another, but you've chosen that cloud to get the maximum value. You're probably architecting replication based on how that cloud is built.

Uh, the diversity, the fact that these are not fungible clouds, I think is the biggest challenge that we have with the sheer number of cloud platforms that are available out there. Yeah. That, that customers like to tell themselves that they're unique and special.

And the reality is they're not, like most business problems are the same in every different company. Um, you, you do hit the issue, Jack, when you, uh, like we, we want to optimize on one particular thing. It's like, well, if you ever do any kind of m and a, so you buy another company, they may have made a different decision.

So now it didn't matter that you wanted one cloud, you've got two now because they made a different decision. What, what we need there is interoperability and that kind of standardization. And that comes from people realizing that, you know what, 80% of the time the, the standard is fine.

Um, standards are great. It's what allows us to actually interoperate across, you know, using ethernet for everything. It's a standard that can just work across all of the different technologies for networking.

And it's, it's really weird to bet against ethernet in the same way. I think there is a common denominator to all these clouds, and it's kind of difficult to bet against that idea. Virtual machines, for example, we do eventually get this kind of standardization because there is so much value in having that, where the vendors are sort of fighting against that.

Like clearly they want you to pick them and not anybody else. So they absolutely wanna resist any kind of standardization effort because it makes it easier for you to leave. And really, that's what I think we should be having about, are there too many clouds?

There are too many proprietary standards. I think what we need is an actual common standard, which probably needs a, a non-commercial solution to that. Um, this is an area where governments traditionally step in.

Uh, yeah, so my opinion, I fully agree, you know, the, the different stacks of technology, the different approach from, um, cloud vendors, uh, build, uh, boundaries, both of the adoption. But as well after on day two, I think that the, the, one of the biggest issues with the too many clouds, it's like, uh, you step into one, you build your competency group in your in-house, or you take it as a contractors from outside, and then you realize that, hey, that one is very interesting as well, right? So I put a little bit of workload there as well.

And then you need to build another group of specialists, you know, and, and when you enter into this, back in the days it was called, you know, cloud first strategy, right? Then you don't realize that on the beginning of cloud first strategy, and you realize that after, you know, like a little bit later, right? And when it's, um, sometimes very costly, and, uh, I'm fully agree with you Justin, that um, it needs to fit the, uh, requirements, but what is the problem?

Mainly that you don't know them when you build the first step, right? So in my opinion, we should, we should go for different clouds, but not go like all in, right? Maybe not a one, right?

Like, just think a little bit what you have and where you can put it. But there's, there's another part to this too, is standardization happens, um, through market forces when it makes sense to, and sometimes it's explicit standardization, like on ethernet, and sometimes it's implicit. And if you think about it, you know, I, as I said, I was an engineer for a long time and I was developing, uh, chip set server chip sets for multiprocessor servers, uh, back when we were having the, what we could call the processor wars and whether we were gonna standardize on a risk processor or a CIS processor.

And the industry naturally ended up, uh, standardizing on Intel X 86 instruction sets made by two vendors, and for a long time, that's what everybody did. But as needs change and things develop, we see other things coming in now that power is becoming very important. We're seeing a transition to back to a, a risk chip in the arm chip sets that are now becoming popular in the cloud in the servers, as well as the need for co-processor for three graphics which have turned into co-processor for AI processing, right?

And none of that happened through government intervention and didn't need to happen through government standards or a separate third party. That's sort of the natural market evolution. And I think I look at this, and that's what I said at the beginning when, you know, if there's really are too many cloud providers and too many different types of clouds, somebody's gonna go out of business or get acquired by another company at some point.

And that's not a bad thing. That's just sort of natural evolution of businesses, right? And, uh, you know, and so I don't, I'm, I'm not concerned that there are so many different cloud alternatives and, you know, and the other thing I'll bring up is you, and I'm a very much sort of market focused guy, and I'm talking about, you know, sort of what I would say maybe third party cloud providers, but there's also, as you said, Justin, in terms of cloud as an operating model, there's also building your own cloud and running your own cloud in your own on-premises environment, right?

As yet another option and to, to do so. And there's not even standards there for how you do that. And I think one of the elements that I pull out of, of Justin's commentary was standardizing on something that is the lowest common denominator across the pla the clouds allows you to essentially do arbitrage that you could move workloads to the place where those virtual machines and most business effective, not even just cost effective, but business effective to run.

But that means we're not getting the full value of any one cloud. And there, there's a conflict in me I that I as a, as an engineer want to build an efficient solution that, that uses the best tool to solve the problem. But I can definitely see that business perspective of we need to be able to change our mind about where this application runs, and we can't do that if we are using these deep features that lock us in.

And so there's a tension between getting the, the most value outta a single platform versus giving the most flexibility to the business. And that, I think, for customers is an, an interesting tension to try and work out and to work out when to go with the standardized solution. If it's just virtual machines, we can run them anywhere and when to go with, we really need this special feature and, and this particular use case within our organization cost justifies the degree of commitment to one cloud provider.

There's some unclear, uh, definitely opportunities for consultancy. So, Justin, have you got some consultancy thoughts around that? Oh, definitely.

I mean, we see quite a bit of, uh, that sort of work at the moment because people who did standardize on one particular kind of private cloud have discovered that the price just went up by a huge amount because the vendor decided to change their mind. Um, you know, Jack, we do, we do have some kind of industry standards, like S3 is probably the classic, um, that's kind of an object, um, storage standard, which is entirely owned. Like the definition of how that works is owned by Amazon and AWS, it's not actually an open standard.

It's not, you know, shepherded through any kind of col collaborative group that is a proprietary standard that everyone else has just kind of adopted. Um, all hoping that, uh, the company that runs that standard doesn't sort of wake up and decide to be evil more one morning. Um, that's the kind of thing that we see in consultancy is that where do we draw the line?

So how much do we bake ourselves into one particular ecosystem? And as you point out, Alistair, do, do we optimize for that in order to get the additional value? Because a standard is a flaw, not a ceiling, it's something that you can build on top of, so you don't have to limit yourself to just what the standard does, but generally you have to have a good reason.

And I, I dunno, I would disagree with you Alistair, a little bit about the, uh, desire for engineers to, to build the most efficient and, and, you know, the, the best and highest quality solution. I think as an industry, we chase fads and fashions even more than the fashion industry does. We change JavaScript frameworks more than we change our underwear.

So I, I think there's a lot of opportunity there for consolidation and, uh, optimization. And indeed we're seeing that right at the moment. So people are looking at their cloud costs at the moment and are trying to consolidate them either within that cloud or in many cases deciding that, you know what, the flexibility of cloud is fantastic, but for a lot of these workloads, they're pretty standard and boring, and we're probably better off just bringing them back in house and running them on infrastructure ourselves somewhere nice, static, predictable workloads.

We don't really need all the cloud. I was gonna say, Justin, I think that's in, in part because you said that, and, and I I wholeheartedly agree with you that cloud is, is an, is an operating model, right? And there was, I think in the early days of the cloud where there was these, you know, external cloud service providers that provided that operating model, that was an operating model that was very hard to obtain on, you know, on your own, in on premises environment.

And so if you said, if you looked at it and you said, this operating model makes a lot more sense for all the reasons we know and understand, go to a third party to get that solution right Now we see, okay, now all of those tools that we're proprietary that those vendors have developed are either available in open source formats or forms, or we can purchase those types of solutions from vendors to bring in-house and do that in-house where we couldn't do that at the, you know, at the, the early days of the cloud. And it's always a trade off of, um, do you invest in the expertise to do that in-house yourself or do you pay somebody else for that expertise of running that cloud infrastructure? And I think that's where companies are right now.

It's sort of the pendulum swung all the way to offloading all of that type of expense and effort and cost of running an infrastructure environment to somebody else. And now they're saying, well, maybe if we invest in doing it ourselves, bringing that expertise back in house, it'll be more, more cost effective. I'm not convinced yet that it's more cost effective to do it yourself for, because it's, it's a business that really operates, uh, that, that, um, works in economies of scale, benefits from economies of scale, right?

And the, the cost of the capital equipment costs from a smaller business to acquire the infrastructure is much greater than it is for the large cloud service providers. I think that there is another, uh, dimension of that, uh, in sense that when we start the cloud journey, when we move to those different vendors, generally infrastructure and the systems that we had in, uh, our, in, in infra premises, there was total mess. We didn't understand that when we move it to cloud, then because of the cost spike, there was a lot of cleanup, a lot of things change in the way that we start to understand what we really have.

And now it's kind of, you know, we are more mature. Uh, the companies are more mature, they understand more what, what this infrastructure, this virtual machines, these containers really mean in sense of the business, what they bring as a value to them. And that's why it start to be interesting to move it back because you start to understand how really, uh, how, how, how much really money it's making, uh, that that infrastructure and additionally, uh, you understand the risks because you pay really big check for that all over the last years.

And the it stuff became for the companies right now being more, um, uh, it, it's more understand, uh, it's, it's, it's more understand by business, right? So, and I think that this, this, um, put us in different position that we've been, uh, back in the days because we're starting somewhere else. We understand our business more, and then we can make more decision, more, uh, the decisions that are more aware of the, uh, risk and, uh, costs in the end.

That's why the different options open. Yeah, and to follow on from a bit in there that, that you mentioned Magic is the, uh, the CIOs who wanted to change their organizations. Um, I've spoken with several of them, and they will never say this on record, uh, for obvious reasons.

It'll become obvious in a minute. Uh, when they went all in on cloud, that wasn't really about changing the technology to use cloud per se. And it wasn't really that we think, oh, we, we absolutely want to go first on cloud.

The reason to do that was to change their organizations and to change their own operating model because they reasoned that we are not going to be able to retrain our operations staff or the way that we do things internally with our people because they are too welded to the old way of doing things. We would be better off pushing everything into the cloud, completely changing all of our people to people who know how to drive things in cloud. And then once we've done that organizational change, then we'll be able to start bringing the technology back in.

But all of the operating conditions, all of the ways that we work with the technology, all the ways the humans do things that will have completely changed along with the tech. And that was actually the goal. It wasn't really about the technology at all.

And so the fact that we're now seeing people bring things back in house, they've changed the way that their organizations function. That was possibly the plan all along. Although I would caution that many of the organizations doing this weren't really doing it on purpose.

They just copied what everybody else did. Uh, the smarter ones were possibly leading this, and we've just happened to get a, a change result across the industry just kind of by accident. But, uh, that's where I think some of this is coming from, and we're probably ending up in a better place at the end of all of this.

So if, if that's the case, and I fundamentally it makes sense and it's, it's, it's logical. And I agree with you because the people process, part of the old way of doing it was just horrendous for many, many reasons, right? And it would take forever to do things and the cloud brought in a self-service model that fix that.

But if people are now starting to transition to bring more of this back in-house, then the in, in my perspective, the too many clouds problem will, again, solve itself by some people are gonna get some, some organizations are gonna acquire and some organizations are gonna end up getting out of the business because they can't, as I said, it's a, it's a business that, that benefits greatly from economies of scale. And if you don't have enough customers, you can't pay to keep the lights on in these very big, very expensive, very power hungry data centers. And so you're gonna end up having to close down or get acquired, right?

I think we could continue to, to discuss this for quite some time. And I'm sure that over the course of Cloud Field Day, we'll discuss more around the, uh, drivers and, and realities of the cloud marketplace. We do need to bring this particular conversation to a close so we can carry on with further conversation.

So how can we, uh, catch up with you? So Justin, where can we find you on the line? Uh, well, you can find me on the inter tubes, uh, on LinkedIn.

You can search for Pivot nine or Indeed myself. com. Uh, and please subscribe to our weekly newsletter, the Crux, where we talk about this kind of, uh, we talk about this kind of issue every week, and always happy to get new subscribers and indeed talk to people about what their concerns and questions are And message.

Where can we find you? com. Uh, you'll find more information, uh, about those subjects there as well, uh, back with the technology and when you can choose from this.

Yeah, multidimensional world. And Mr. Poll, where are you online?

com or on LinkedIn where I publish a lot of articles about the Tech Field Day events. Well, thank you for listening to this episode of the Tech Field Day podcast. If you enjoyed the discussion, please subscribe to our YouTube channel or your favorite podcast application so you don't miss an episode.

Do consider giving us a rating and a nice review. This podcast was brought to you by Tech Field Day, the home of IT experts from across the enterprise and a part of the RUM group. com/podcasts or view us on text on tv.

Thanks for listening, and we'll see you next week.