Follow me:
Listen on:

Day Two Cloud 184: Think Multiplatform, Not Multicloud

Episode 184

Play episode

Today on Day Two Cloud we put on our thinking caps about platforms, cloud, and multicloud. The last ten years or so has been a push for “cloud-first,” but any wholesale approach to “X-first” (cloud, edge, digital, etc.) is problematic. We discuss why. We also look at cloud cost controls and how they compare to on-prem cost controls, and why enterprise cloud adoption may not be as widespread as you might think.

We also explore strategies for CTOs, IT managers, and engineers on how to grapple with cloud strategy, implementation, and operation.

Our guest thinker is Jon Collins, VP of Research at GigaOm. This episode was spurred by a thoughtful blog post by Jon.

Show Links:

Time Is Running Out For The “Journey To The Cloud” – GigaOm

Cloud FinOps 2nd Edition – O’Reilly

@jonno – Jon Collins on Twitter – Jon Collins on Mastodon

Jon Collins on LinkedIn


[00:00:04.410] – Ned
Welcome to day two. Cloud. Today we want you to put your thinking cap on, pour yourself a nice cup of tea perhaps, and sit back with our guest Jon Collins. He’s the VP of Research at GigaOM and he has some thoughts and opinions about Cloud multicloud platforms. Multiplatform? What does it all mean? Ethan, what does it all mean?

[00:00:28.490] – Ethan
What it means is we’re on a journey. Actually, he’s going to say that he hates that term and we’re not on a journey as such because it’s so much more complicated than that. Not everything is going to go to Cloud, nor will it ever, according to Jon. And he has some, as you said, cerebral thinking. Yeah, lots of thinking that Jon has done about this topic and reflecting on the reality of enterprise. It net, it is not all cloud these days.

[00:00:54.450] – Ned
Absolutely. So pull up a chair and enjoy this episode with Jon Collins from GigaOM. Well, Jon, welcome to the show. We’re very excited to have you and talk about what could be a controversial topic. Should you stay on the cloud, should you move everything back? But before we get into that, why don’t you tell the good folks out there a little bit about yourself and who you are.

[00:01:13.460] – Jon
Okay, so it background. Started as a programmer, did systems management, ran a Unix environment, broke everything, got shouted out a lot, ran a help desk, had the therapy, wrote some books, did all that and then became an analyst. And it’s really great because you don’t actually have to explain yourself anymore, you just have opinions about what other people do, which suits me, but I still miss that, to be honest. I missed the kind of the cut and thrust. I did run a little healthcare startup for a while, which was fun. We went into a hospital and we tried to solve their problems and we didn’t get very far because healthcare problems are bigger than we are. But it was fun till the money ran out. But the log in the shot these days I’m kind of a gig titled as the VP of Research, but I’m kind of not the smartest person in the room. I’m the one who tries to understand what everyone else is talking about and how it all fits together. So my area is more on the DevOps and application deployment side, so I do get that and I get a lot of security because I’ve got that in my background as well.

[00:02:29.150] – Jon
But then the rest is more trying to take an architectural view of how it all fits together.

[00:02:35.650] – Ned
As part of your work as an analyst, you get to talk to various enterprises and groups that are out there doing the day to day to work and you get more of a broad view as opposed to just like the one view you get from working at a specific company.

[00:02:49.030] – Jon
What I would say about end users is the great thing the trouble with analysts, and that’s a very deep rabbit hole. We don’t want to get stuck down there too deeply. But yes, end users come to us and ask what they should do. But the great thing is, generally, people working in small companies, large companies, medium sized companies, they’re solving problems day in, day out. They’ve already got a reasonable grasp of the pain. It’s not up to us to say, oh, you need to change. Oh, you need to sort your lives out, get your act together and so on. Our job is more to understand, to listen, and then try to start essentially shaping solutions in a way that then can be fed back. And it’s a peer relationship. We’re not trying to kind of tell everyone, tell everyone in the world what’s right. It’s more I see it sometimes as kind of just outsourcing of brain cells, because when I was in that position way back, I just didn’t have time to problem solve. I was too busy just coping. Whereas now I do have that time. I’ve got the luxury of just sitting back, getting a piece of paper, nice cup of coffee, reading up, et cetera.

[00:03:58.080] – Jon
And when people that I work with struggle and say, oh, I don’t understand this, and then finally, after a few days, they’ve got it and they go, oh, great. Literally, that’s the job. It’s literally to take that time, it’s to struggle, it’s to then understand it and then feed it back to the world. So it’s a great place to be, right?

[00:04:17.330] – Ned
As an analyst, you don’t want to be issuing edicts from your ivory tower. It’s that listening and then analysis of what you’ve heard and having the time to do that. I agree. When I worked at a small company, I was running around with my hair on fire all the time. There was no chance to take a think, sit back with a cup of coffee, no, you got to go put the next buyer. So I did rely on the work of analysts to think about the problems I was encountering and help me find solutions that fit what was going on with me. So let’s turn that gaze of the analyst to the world of cloud. And you wrote a really interesting blog post around where cloud has been and where it’s going. And I want to start with just the idea that’s been prevalent in the last ten years, which is that everything’s cloud first. And I heard this constantly when I was in consulting, you know, from the from the sea level down, was, we’re taking a cloudfirst approach. What’s wrong with that philosophy?

[00:05:22.620] – Jon
It sounds great, doesn’t it? And it goes back to opinions as well. When you say you shouldn’t have opinions about things and edicts and so on, that is great. It’s brilliant to just say, hey, everyone should digitally transform, and, you know, it should. Or back when I started being an analyst, it was ebusiness e business or no business. And you throw out these things and it would all sound around cloud first. Yeah, do it. And it’s kind of at board level, it’s an easy win. Say we’ve got a cloud first strategy and we’ve got this and we’ve got that. The good thing about those things is they’re never wrong. It’s almost like back in the day it was, you’re not going to get fired for buying IBM these days. You’re not going to get fired for kind of just jumping on these trends. The trouble with it is that it’s never worked. So bear with me as I say this, and I was writing about hybrid cloud back in 2008, I think it was, that I found my first blog post on the Register that was kind of referencing it. So I know I was talking about it then.

[00:06:33.550] – Jon
And the situation that we’re in today is not very different to the situation that we were in back then, which is that, and you’ve got me on the spot, so I’m being very careful how I choose my words and I’m speaking really slowly. So the idea that everything could be a wholesale approach is the flawed idea. It could be called cloud first, it could be called edge first, it could insert whatever diamond first, insert whatever term you want there. And so it’s not that it’s wrong in principle, it’s that the practice has constantly been, and continues to constantly be compromised by reality. And I remember once someone talking to me about the reality of Enterprise. It and they likened it to something, and I don’t know if this is what they were talking about, but it’s where I’ve ended up with it. In my head. They said it’s like the Death Star. So you look at the Death Star and it’s kind of all you can see is this complex surface. And yet within the Death Star, it goes deeper and deeper and deeper, and it’s complexity all the way down. To paraphrase Stephen Hawking, it’s not about just solving that superficial stuff and saying, you’re done.

[00:08:00.280] – Jon
The complexity goes all the way through the organization at such a level that and you look at, for example, I mentioned the NHS. The NHS architecture ain’t for moving. It’s like saying, let’s move the city into the cloud. It’s literally a similar analogy, let’s just lift it up and fly it up in the air. Ain’t going to happen. So it’s not that I don’t believe in the cloud first approach. Sorry. It’s a long winded answer to a short question. It’s that if you’ve got the cloud first approach for new applications, if you start putting kind of additional wording on that, yeah, absolutely, let’s go with it. If you say, let’s move to the cloud without additional phrasing, that suggests that that’s at all probable or possible. That’s where I have the problem.

[00:08:50.090] – Ethan
So is it that cloud first? Would it work for a new organization or does it not work for the average Enterprise, as you were saying, because of the Death Star complexity, there’s so much going on that you couldn’t just move it to cloud even if you wanted to.

[00:09:07.550] – Jon
If we say the cloud that’s suggestive of certain things, if we say cloud that’s suggestive of other things, the cloud is suggestive of architecture and then we can get into dynamic elastic, scalable, et cetera, et cetera. If we say the cloud, it employs a singular destination. And actually if we look at all the as a service providers and they’ve got, I think, large and small so right up to the AWS and as yours and down to the kind of MongoDBs and airtables and Monday dot coms and whatever else there’s been this land and expand model try before you buy just use a bit of it and before you know it you’re using 1000 different little things and that’s cause so this kind of a Dcloud as a destination or just a cloud. But if it’s just cloud it implies a thousand destinations and then the problem comes because you’ve then got a thousand targets that you’re aiming at and a thousand problems that you’re solving for or a thousand times a thousand problems that you’re solving for around integration and so on. You’ve created more problems. You haven’t moved to a singular place where everything’s good.

[00:10:29.550] – Jon
You’ve moved to a thousand places and created a whole bunch of other stuff that you got to deal with.

[00:10:35.880] – Ethan
It’s the same challenge any enterprise I’ve worked with. You buy a tool to solve a problem, it’s probably a bunch of different buying units that have buying authority and they can pick up a thing and there isn’t necessarily a cohesive it plans you end up with a lot of spread that way. We translate that into cloud, we move some stuff to AWS and we move some stuff to Azure for those sort of workloads. But there’s also a bunch of SaaS services that we’re consuming as well. And so you’ve got this spread of products that go all over the place. And instead of you’re building it all and standing it up on your own infrastructure, it’s just on everybody else’s infrastructure, the cost model of which may or may not be beneficial and the consumption of which may or may not be homogeneous in style and probably isn’t. There’s probably six different ways you’re consuming all of this stuff.

[00:11:20.670] – Jon
Yeah, and I’d pick up on the kind of nigh on gospel point. It’s been nigh on what people have been told should be gospel and people are going oh yeah, we definitely need to move to the journey to the cloud is a phrase I dislike intensely because we’ve been told yeah, we’re on a journey to the we’re going to the cloud. It’s all about this kind of again, it’s reinforcing the notion of a singular place. And actually I’m not sure we were ever going to get there from that point of view. But it’s been and I don’t want to say that the hyperscaler marketing people were deliberately conning the world, because that would be wrong of me. And I don’t think it’s true equally to just keep saying, you’re on a journey, let’s do it, gets you so far, by which time they’ve got a whole bunch of revenues out of that situation, and there’s an ambivalence as to whether or not the destination exists. Because the money is good, that makes sense. Why stop them? It’s increasing our footprint, it’s increasing our customer base. So why wouldn’t you?

[00:12:42.290] – Ned
Yeah, well, when you talked about the Death Star, and I think of that as a single concrete object, right? And the whole point of the Death Star was the ability to move to other solar systems and then blow up planets, which lovely, but the point is it was a singular unit and that was one of its downfalls as well, is that it did work as a single cohesive unit, so it couldn’t scatter. It was just this big hulking mass. And if you’re thinking about the journey to the cloud, the idea that’s painted in one’s mind is you have this single object to the Enterprise that is on this journey to a particular destination. And that sounds like a really good story, but the reality of it, as you’ve kind of expressed, is that it’s actually a whole bunch of destinations. And so you have to take this singular object and just imagine it fragmenting like a diaspora of all these different components of the Enterprise, going in 100 different directions to embrace the SAS or the cloud that meets their needs. And how do you manage that when you’re used to this monolithic structure and now you’re moving to microservices but for.

[00:13:55.800] – Jon
An enterprise, and I think, in fact, what you’ve done is you’ve flipped the notion of a journey to the notion of travel, which is brilliant, and did I do that well? And bringing in the diaspora idea, staying in the same place wasn’t ever going to be possible. So getting people on board with the idea that they’re going to have to spread and actually, what the cloud gives us, and you bring in microservices and so on, is massive scale, massive distribution, run anything, anywhere, then it gives us problems of sovereignty and compliance and all those things are going on. But that’s the reality. We’re not on a journey towards anything, we’re on a journey away from where we were. And it’s an expansion journey. It’s a bit like going to the stars, as you say. We’re not heading, we’re not going to the moon, we’re going to the stars. And this could be construed as kind of philosophical banter, but actually, I think it’s massively important because there’s revenues tied up in getting people to think in a certain way, and there’s revenues and there’s revenues and solutions tied up with getting people to think in the right way versus the wrong way.

[00:15:14.890] – Jon
So I think if we think of it as a journey to the stars, massively distributed, the issue starts to be all around the network, how to manage that. The issue starts to be all around configuration and synchronization and where is anything and so on and so forth. That’s reality. That’s actually what’s going on and that I embrace. It’s not that cloud you ask the question, does that mean cloud isn’t the answer? This stuff is happening anyway, but the idea that we’re on a journey towards a single place is the falsehood that.

[00:16:00.710] – Ethan
I would cloud is not the answer or the cloud public cloud is not the answer. Cloud is. Ned, we were talking about this before the show a little bit. Cloud is an operational model. Cloud as a way of consuming it could be a destination. But public cloud as in AWS, Azure, SaaS services, places you park, compute and get things done or consume services may not be the one way you do things. There are, and we know this from this is reality a variety of ways that we consume, including on premises bill.

[00:16:43.470] – Jon
There are still monolithic applications on premise and then monolithic, modern monolithic we went through the lamp stack phase and then into the open stacky world and virtual machines and everything else. Still a massive investment in those things. And sometimes it just doesn’t make economic sense to move from whatever you’ve got and other times it doesn’t make risk sense. So I’d love to change London. The sewer system is just terrible and there’s loads of you literally can’t and there’s the tech equivalence of that. You can’t just kind of go in and change your data paths. When I was working in a hospital, I literally heard that story that you should never hear, and given that this was healthcare, you’d never, ever hear, which was there’s only two people know about that system. And if one of them and they can’t ride in a taxi together, because if something happened to one of them, we don’t want it to happen. But to both of them, that’s the reality of one very small parts of a very complex system. That’s what we’re dealing with.

[00:18:00.350] – Ethan
Well, Jon, how much does cost you brought up cost in budget and economics a moment ago. How much does that weigh into this? Spreading out of workloads and software everywhere.

[00:18:16.510] – Jon
This is really where it’s really interesting. And again, it’s reality check. A many organizations don’t know how much money they’re spending on cloud based services and solutions today. They just don’t. And don’t ask me for an official stat on that. If anyone wants an official stat, just look at your own organization and say to you and use yourself as a sample of one. And the reason for that is in part because the solutions have come in from the ground up. So there’ll be a credit card purchase here or a freemium model there, or an open source thing over there. And every single system that is used will have a cost. There’ll be a manpower cost associated with it just in terms of managing it, or there’ll be an integration cost, or there’ll be an extra piece of software that manages it, but then has to have a paid license in order to manage that as an additional module or whatever. Generally there will be a cost associated with it even if there’s no direct licensing cost. So that at the moment, we’re seeing an absolute explosion in phenops companies. Anyone with a spreadsheet can become a phenops consultancy now, which is fabulous.

[00:19:36.850] – Jon
And once again, I’m missing the boat because I should be immediately calling myself a phenop consultant and just going in there and saying, let’s do a software audit and let’s write it all down and give you a figure back. But the reason for that explosion is people suddenly the awareness of, well, two things. One is the awareness of the fact that people don’t know how much they’re spending, and then they start to look and they find it’s quite a lot, particularly in these more recessionary times. And the second is that the growth of cloud based platforms and services has hit the CFO at the point that finally the CFO in generalizing here, but has said, actually, no, I’m not going to just change my entire way of amortizing asset purchases over three years just because the It department tells me that I’m doing it wrong. And when you look at subscription based models, they don’t necessarily make the most sense from a business finance and business planning perspective. They seem to make sense because this was the theory 510 years ago, it would be cheaper that way. When it’s not cheaper that way, all bets are off.

[00:20:58.930] – Jon
And if you’d prefer to spend three year cycles a capex model, you decide what you’re going to buy and you lock it all down up front and then you stick with it whether it was the right thing or not. Sure, there are disadvantages to that, but it’s not necessarily 100 times more expensive than the alternative.

[00:21:19.930] – Ned
I think if you look at the cost models that it was pushing over the last five, six years, there was a certain amount of hubris in there. Like, we’re smart, we know tech. That means we can figure out finance too. And coming to the CFO and going, now you don’t understand this is the better way to do it. And the subscription based thing seems really good. Just kind of like how in the US. We had bundled cable where you had all these channels you didn’t care about and you were paying like this lump sum kind of thing. And then suddenly we had all these streaming channels where, oh, I only have to pay $15 to get all the streaming I want, but now I have to subscribe to 20 different streaming services to get the content I got from one cable bill five, six years ago. And I feel like I want to get your thoughts on this. Are the CFOs now pushing back and saying, no, we have to we have to stop the bleeding and maybe bring some stuff back in house and shift from a subscription back to an upfront capital payment for things?

[00:22:25.470] – Jon
I think there is some pushback, and don’t get me wrong, when I’ve done work around CFO, there’s a lot of very old fuddy duddy CFO thinking going on. It’s kind of accountant type thinking isn’t necessarily the most forward thinking approach. And that does need to change because the world is more dynamic. And however things are moving forward, financial models have to move forward with that as well. The business economics is changing, and you have to keep on top of how those changes are coming about. You can’t just assume that how you did it in the 60s is still going to work. Having said that, the pushback that is coming at the same time AWS a recognition that it plays to the weaknesses in human behavior and a bit like you’re saying about the cable subscription versus the Netflix Plus, the Apple Plus. Suddenly you realize you’re paying for all of them, and each one has kind of pushed up its price to kind of $8 or $15 or whatever, whereas before, altogether, you’d be paying about $20 for the whole lot, and then you’re not using all of them. That similar model is now being applied to individuals in teams, to individual groups.

[00:23:59.390] – Jon
The whole Martech revolution, it’s just a chaotic if you look at the kind of the periodic table of marketing technology companies, it’s huge and massively complex. And a lot of that is predicated on the fact that the way that marketing teams spend their budgets is often tactical. So it’s literally leaning on human psychology. It’s going, oh, well, if your tactical spend, we’ll give you tactical purchase and hope that you don’t notice month or month that you’re not using it enough. And so all of those things are coming back up to the CFO and he’s going, Hang on, why am I running databases from 72 different vendors, right? And if you look at the DevOps where one big bank said, we’ve got 5700 pipelines because we’ve got 5700 applications that we’re building, and each one has a completely different pipeline. All of this is about the kind of it’s almost the paradox of choice applied to the enterprise that rather than being stuck in front of the yogurt aisle going, well, I don’t know anymore. I’ll just buy whichever one comes, whichever one’s got the best special offer. We’re literally doing that in the enterprise, and it proves very expensive, particularly if you apply the gym membership theory to it, which is, yeah, you buy it and then you don’t use it because it was all good intentions.

[00:25:25.130] – Jon
It’s all playing to our psychological weaknesses.

[00:25:31.630] – Ned
One thing I want to push back on a little bit in terms of the CFO having to come into the modern era and rethink some of their financial models, I think there’s definitely a certain aspect of truth to that. But at the same time, when you see people that don’t have the historical experience and context of finance jump into finance and try to do something new and revolutionary, you have stuff like Ftx, we tried to do something new and revolutionary. And either they get it horribly wrong and you’ve got like Nfts, where even if they’re not a scam, they’re probably not worth it, or you just have outright fraud. So I think it’s important to balance the experience that people who have been in the financial world for a long time have with the era of new ideas and concepts that have come out of the technology.

[00:26:23.300] – Jon
Old buddy duddy grown ups that tell us that it didn’t work last time and there’s nothing more infuriating, but yeah, we absolutely need that. There’s an interest that I’m thinking of when I spoke to a couple member’s, surname now, and he’s left. But Steve Someone was the CMO of Harness, the CD company, and he’ll come back to me. He’s a jordy from Newcastle, and he said Harness was supposed to be a CD product. Literally bundle up your applications and then deploy them. They built in this financial measurement module, which then you could kind of see something running on Azure, see how much it was costing you, then you could kind of just do a calculation of how much it would cost. You if you run it on AWS, and then if it was going to be cheaper on AWS, you could literally just redeploy over on AWS, and it would take you a couple of hours. And suddenly they found that massive growth for the company at the time because people were buying their product in order to when they started getting the visibility on what the costs were and how much they could be saving if they didn’t just leave things as they were, that was very exciting for organizations.

[00:27:47.380] – Jon
So all of that to say that this lack of visibility is being used as part of the business model and the CFO in his or her fuddy duddy old ways needs that visibility. And really, I guess the only thing I’m advocating for is let’s get the visibility right and not just across the as a service portfolio and that’s really important. But then the costs of migration, the costs of data egress if you decide that you don’t want to work with a cloud provider anymore, the risks, as we’ve seen with recent conflicts and so on, of having your data in the wrong country and what that might mean, et cetera, and the costs associated with risk mitigation there. So it is all about getting those cost models right.

[00:28:46.090] – Ethan
So visibility issues aside we’re not going to solve those. We’re not going to solve those today. We’re not going to solve those this year, I don’t think. It’s certainly a very hot topic across the industry. But what you you’ve argued, Jon, that cloud adoption is not really via cloud first or cloud only, not financially viable, not operationally viable for the typical enterprise. Okay, what do you think a future model of it looks like?

[00:29:15.160] – Jon
I’m glad you asked that. So there’s the model I would advocate for. There’s the beautiful service oriented, everything is a container, everything configuration managed, everything dynamically orchestrated. Policy is code driven, infrastructure as code githubs, full cycle. We could draw that picture, and it’s great. And that would be the perfect blueprint for how the future of application should work. Applying into that, the management level. And I think that’s the big thing that’s missing from today’s approaches. And then we go down a DevOps rabbit hole and agile rabbit hole of organizations that want to be agile and say they’re being agile, but they’re not. That just being chaotic. Governance isn’t an add on. That comes later. You need to start with that. Otherwise the whole continuous integration back when we started talking about that ten years ago only works if you’re really robust at applying process principle. Otherwise, it very quickly falls into a heap. You try and do three deployments a day, and you go, well, we can’t, and you create a huge bottleneck and text testing, and it all falls apart very quickly. So governance, it has to be governance kind of driven, if you like.

[00:30:45.490] – Jon
Governance from the kind of policies and management and all those things driven. But that’s the theoretical blueprint of joy. And I know even some of the big organizations, like some of the companies we’ve mentioned that started cloud first, they were built on AWS, trying to operate at massive scale, then equally hit problems of configuration management of so those challenges always exist. But again, the theoretical model of that’s what you can build, absolutely. The actual model of having that running alongside everything else, the multiple Death Stars that exist in the standard Enterprise. What I think we’ve done as a kind of philosophical situation is we’ve denied that that’s true. We’ve literally said they’ll eventually move into the cloud, so let’s not worry about them. And that just isn’t the case. So the real model is we’ve got to see our entire architecture in terms of all the cloud first, because we made it that way and we want it that way, and it’s beautiful. Thank you. Then all the other stuff, each properly managed, and then all of that feeding into a single kind of governance framework and dashboard and so on and so forth. You can’t have it kind of the beautiful world over here, all being kind of well governed and so on, and everything else will just let it fester, because that way just adds risk and adds cost.

[00:32:31.960] – Jon
And so on. Generally these conversations go into oh, you mean multi cloud, oh, it’s ending up as hybrid, et cetera. I actually think it ends up as a multiplatform architecture and part of that platform is a bit crappy. It’s not how we want it, but it’s a bit like, I don’t know, the middle child. It’s it’s the bit that person who always seems to be at the pub when you go down there and you got a kind of bit smelly and really bad sense of humor. But they’ve been around a long time. You can’t just kick them out.

[00:33:14.450] – Ethan
You mean learning to live with that smelly patron that’s there as opposed to we’re going to bring them into the future here and we’re going to clean them up and everything’s going to be great. You’re saying live with the reality that you’re never going to get that piece of It architecture moved to cloud or friendly to infrastructure as code or however you want to describe it, you’ve got to live with it as is.

[00:33:37.560] – Jon
Yeah. And I think if you take mainframe for example because heck, why not? Because it’s a bit like the godwin’s law of tech, isn’t it? All conversations ultimately lead to mainframe and then you have to shut up. But the thing that AWS started up a mainframe group last year and they deliberately did that for two reasons. One is their public reason, this is my take. One is their public reason, which is over time they want to migrate whatever’s on the mainframe. Instagram also ever so handy, possibly more real for the next decade or so. Reason is they’re never going to shift that stuff and therefore they’ve got to work out how to make their stuff work with the mainframe stuff. And there are valid reasons why they’re never going to do it. There’s the data model reasons, as I mentioned before, there’s the risk reasons, there’s the fact that the mainframe is actually very good at doing the things that it does. And we saw this back in the days of Microsoft trying to prove that, you know, back in the 90s saying open serverless are just as good as anything you’ve got out there.

[00:34:44.700] – Jon
But funny enough, 30 years later things are still on the mainframe. So it’s a very long game, Microsoft, and still being played. If you look at it from a multiplatform perspective, you go, well hang on, we can start running bits of the cloud as such inside the mainframe. We can put virtual machines in there, we can run Linux on them, we can put Kubernetes on that, we can put DevOps tool chains in there and then suddenly we can start accessing the mainframe data without having to get it out of the mainframe and suddenly we can do real time antifraud it’s great. Why wouldn’t you, why are you going to shift all of that all the way to some third party provider with massive risk and a whole new architecture when all you have to do is just spin up a few containers inside the mainframe and start accessing that duty data. You can do that in a couple of days, whereas the alternative would take years.

[00:35:49.970] – Ned
So much of what you’re talking about is operational in nature. It’s about changing processes and not switching locations. It’s not a location argument. And I think that’s kind of what we get stuck on when it comes to the cloud is we just have this in our mindset that going to the cloud means literally moving the workload to a different location. And what you’re talking about is, no, you’re going to bring the cloud operations or just better operational processes we’ve figured out over the last ten years to work with our systems that we already have today. So you’re not going to change that patron to a perfect citizen, but maybe you can interact with them in a better way.

[00:36:39.490] – Jon
And I hope whoever’s listening to this didn’t associate me talking about the smelly guy in the bar with the mainframe engineer, because it’s not about and it’s almost ages to kind of go far too far down that track. To kind of say, well, there’s all the old people that are doing that old stuff and it should all be thrown away and we should replace it by this koolaid drinking generation. That where everything’s just going to work. And a lot of the things that you’re talking about are very old principles. And I even go back to containerization. The art of good containerization patterns are pretty much going to go down back to Jordan and Constantine’s 1975 paper on structured design, because it’s all about cohesion and coupling and reducing dependencies and so forth. It’s good old stuff. There’s nothing wrong with it. So I think the only danger with cloud is we get too high. This could almost be the thread right the way through. We get too hung up on the word. And then, because we love labels, it’s a bit like prog rock or or, you know, acid jazz or whatever, it’s like, well, that isn’t acid jazz.

[00:38:00.150] – Jon
What are you talking about? We have these huge arguments that’s not real cloud. I can hear people saying already. So we kind of get stuck on the terminology. And actually it’s about just deciding where’s the right thing for something to run most efficiently and with minimal risk and maximum effectiveness and all that, and then also applying the right controls. And I think that it’s why I get quite excited about Githubs and infrastructure code, for example, because now that you can virtualize things, it means you can have my dream situation, which is you can say everything worked really well last Tuesday at 03:00 P.m.. Let’s go back to that. Let’s just go back to that state which you couldn’t do with old hardware and old architecture. So the software defined view of the world, I think is great. But then we’ve got to keep when it comes to back to what we’re saying about the cloud costs, we’ve got to keep control over not just our ability to do things, but our ability to measure value from those things. Because otherwise we’re just, I don’t know, creating a whole series of Mickey Mouse sorceress apprentices, and they’re creating more and more brooms and it’s like, whoopi, look what I’ve done.

[00:39:26.330] – Jon
And then there’s no one there. Clearing them up afterwards.

[00:39:29.610] – Ned
1000 brooms and all you need is a vacuum cleaner.

[00:39:32.500] – Jon
I hear you.

[00:39:34.170] – Ned
So let’s assume that I’m an It manager at an Enterprise and I’m listening to this podcast and I’m like, so what do I do in the next three years? What’s my plan? Is it all just kubernetes? Is that just what I need to do?

[00:39:52.370] – Jon
Well, interestingly. I mean, I went to Cubecon in Valencia, and it was absolutely heaving, which was just post covert. This is uncomfortable, but definitely I think I’m a huge advocate of architecture and cohesiveness of architecture and getting the level it’s a bit like the 1975 thing. If you get the level right, then you can build on top of it and you can you can change things below it. The seven layer model in networking is is fantastic at this as well, because it just says, here’s what we’re doing at this level. And I think Kubernetes at that level is a great tool for building on top of and it seems to be what we’re kind of going for, rather than docker swarm or whatever else might have been possible at one point in time. But the point isn’t about Kubernetes. That’s an orchestration mechanism for microservices. The point is about microservices, and then it’s about managing those micro services in the right way. So I would say so you asked about the It manager, I think generally to your point earlier, and we can debate this one, but it breaks into two parts. It’s the people building stuff and then it’s the people running stuff.

[00:41:16.600] – Jon
So the people building stuff. Yeah, pretty much. I think service wrappers is the answer. So get your head around those patterns. And again, I’m going back a bit, but it’s not that different to what we were doing in component based development or in service orientation or whatever. It’s just understanding the chunks of functionality, how you want to chunk stuff up so you can build stuff efficiently. Get your head around that, if you haven’t already, and get your head around the current tooling that enables you to do that. I think that would be a really good thing. And then on the operational side, I think it’s about managing for effectiveness. So that’s where I would stick with I would be learning some new things, but most importantly, I would be trying to understand how to manage my entire environment as a cohesive architecture. And that does go into what my colleague Ron Williams starts talking about operational awareness and you start to play. The Observability goes in there and AI vROps goes in there, et cetera, et cetera. But ultimately it’s about how do you fix something when it’s broken and it’s meantime to resolution and those sorts of best practices across the two.

[00:42:54.730] – Jon
While I think about it. Azure the Dora principles, which I’m not a huge fan of for the simple reason, is they get you to a starting point, they don’t get you to a conclusion, but having the ability to kind of put those measures in place. Which brings me to the third piece I would have at the Pie, which is, how are you managing it all? And I mean from the point of view of it’s, where the GitHub stuff fits in, it’s where Atlassian tools fit in, it’s the whole kind of how we’re going to define our epics, our stories or whatever else that we’re building in a way that operations can understand them. How can operations report a problem back in a way that the people building stuff won’t just go, ah, it’s just them complaining again, etc. So I would be putting that triangle together and seeing how we can make those three pieces work.

[00:43:56.980] – Ethan
So, Jon, with that holistic view, that triangle you created, that managers would more take that view of their It and their It operations, what advice would you have for those folks in the trenches that are hands on using the tools, actually doing the operational, the engineering work? How should they be looking at their careers? How do they scale up at this point?

[00:44:19.590] – Jon
It’s a really good question. I’m not a great believer or advocate for this idea that developers are the great kingmakers and they should just do what they like and learn all these new tools and all these new languages and so on. And we’ve got this massive fragmentation right now. And I think there is a point where they have to start becoming a bit more boring and not just seeing a pull request every morning is the thing that sometimes it’s about not doing things rather than doing things. So I think I’d be hoping developers in that world start to see themselves sure, as gatekeepers, maybe, rather than keyholders, rather than king makers. They do hold the key to the future, but then what skills you need to build around being a good key holder? And it’s about learning. I’m probably starting to sound like a broken record, and I don’t mean to, but the architectural principles and so going up a level, so even if you’re learning Go or you’re learning whatever language is the one that seems to be popping up, you’re always doing it within an overall. How am I going to kind of manage this in Git?

[00:45:44.520] – Jon
And I mean, there’s tools like what’s it called now? Zenhub I’m a big advocate of value stream management, which is largely about applying business process modeling principles to the development and operations process. So when you’re building stuff, how do you build it in such a way that you’re not spending more on building it, then you’re going to get value out of it at the end kind of thing. And what happens when you hit the bottleneck of testing and then everything stops for a month and no one can build anything, et cetera. So it’s addressing those sorts of concerns. I’d be looking at tools like that to augment what I’m doing as a developer and seeing development just as starting to take responsibility. I’d be starting to I want to say developers grow up. I don’t mean by that. I mean just kind of as the development world increases in maturity, it then starts to get a handle on building things for the right reasons and knowing to ask for reasons, et cetera. And the other thing I think, from a purely practical perspective is learning security skills. I think that the biggest cause of unnecessary expense is building things without having thought about security as you go along.

[00:47:26.610] – Jon
So every project I’ve ever been a.

[00:47:29.520] – Ethan
Part of, oh yeah, we need to secure this. We should have thought about this in the opening meeting and the kickoff.

[00:47:34.800] – Ned
Not now.

[00:47:36.070] – Jon
It’s interesting. I can’t remember who said the stat, but they said something like, for every 500 application developers, there’s two security people. It’s literally that kind of imbalanced. And I think a developer with security skills well, I’m sure, you know, from your experience, I’m sure it’s still true that a developer with security skills is gold dust. So if you’re looking to differentiate yourself from the other developers, just pick up some do your whatever it is ISS course or whatever, to just pick up some basics.

[00:48:17.830] – Ethan
It’s a huge topic on the development side because it’s not just the code you’re writing, it is also the code you’re implementing or the code you’re leveraging open source libraries and things and understanding how they all work.

[00:48:30.870] – Jon
Absolutely. It would be very I’m imagining, and I don’t have direct experience with this, but to become the go to person when things start not working properly, like, oh God, did no one check that library? Who should we speak to? Let’s speak to Sheila. She knows about this stuff. You want to be when it’s harder and harder to differentiate yourself. I think one of the issues with one of the positives is there’s still a massive dearth of talent required, even with all the layoffs recently, I know in the UK with like kind of 200,000 developers short of the number of job applications that are out there. So there’s massive opportunities. But then the question is, how do you kind of be even better than all the other ones? And so I would go up into architecture skills and security skills and probably the as code stuff, the infrastructure terraform and so on, and be building out skills. Because I’m not saying it’s easy to learn a new language, but everyone will be learning new languages all the time, but they won’t necessarily be learning the stuff that’s around the core skills.

[00:49:54.290] – Ned
Right. I like that you’re focusing on fundamentals and focusing on expanding out your skill set beyond just development or operations. So bringing in some security or maybe even some financial ops ideas if that can fall under your purview. Because if you can help save the company money, they usually like that too.

[00:50:17.610] – Jon
I think it’s worth it depends on the career path, obviously. And I know people that have gone up into management, I’m sure we all do. They’ve gone up into management and thought, Agile, do you know what? I really liked Life when I was just programming stuff and I just can’t can I go back? And the answer is yes, sure. Some people I know starting to retire now and they’ve had a successful career as a programmer right the way through. And I’m vaguely jealous of them. But yeah, they settled early and they carried on and wasn’t that fantastic? So I think good engineering is always fantastic. Equally where this whole session together started was kind of the fact that things are out of control. So I think that the real kind of and we went through the kind of philosophical debates around kind of terminology and so on, but the real kind of the people that we need in the future are the ones that can help us see through it all coherently. And that requires I would very much I’m thinking patterns and anti patterns as a great kind of both from a design perspective and then from a financial modeling perspective and then learn to be good communicators.

[00:51:50.250] – Jon
I mean, that’s always in a sea of geeks, the good communicators stand out and it’s stuff that can be learned. Why not?

[00:52:00.780] – Ned
So it’s not a solution you can buy, it’s a skill you have to develop. I think that’s I’ll put a little cherry on the top with that one. So, Jon, if folks want to hear more from you, where Azure? Some good places to find you and your writing out on the internet.

[00:52:17.230] – Jon
Well, if anyone’s got any questions, they can always ping me directly. If we’re all still on Twitter, I’m at Jon O. I think I’m at Jon O. 101 on Mastodon. You can find me so I can’t remember which server Mastodon dot something and I’m always open to learn more. Had a very good debate around Chat GPT and I said, Well, I think it’s like this. And someone gave me reasons why it wasn’t. I was like, oh, I don’t think it’s like this anymore. So I’m always open to having my thinking changed and that’s probably a good starting place. Just ping me with any questions. Find me on LinkedIn. Happily bore people with a long series of blog posts they could read at any opportunity, but just find me.

[00:53:11.100] – Ned
Awesome. We’ll include a link to that, as well as the blog post that kicked off this whole conversation. Jon Collins, thank you so much for being a guest today on Day Two Cloud. And hey, virtual high fives to you out there, listeners, for tuning in. If you have suggestions for future shows, we’d love to hear about them. You can hit either of us up on Twitter at Day Two Cloud Show, or you can fill out the request form Day Two Cloud IO. If you like engineering oriented shows like this one, visit packet pushers net subscribe all of our podcasts, newsletters and websites are there, including the shiny new Kubernetes netties Unpacked with Michael Levan. It’s all nerdy content designed for your professional career development. Until next time, just remember, Cloud is what happens while it is making other plans.

More from this show

D2C218: What’s Inside The AI Magic Box?

AI and machine learning are being more widely used in IT and elsewhere. Today's episode opens the AI magic box to better understand what's inside, including software and hardware. We discuss essentials such as training models and parameters, software...

Episode 184