August 15, 2023
Season 1, Episode 13
In this episode of Cloud Unplugged, Jon Shanks and Jay Keshur delve deep into the intricacies of team dynamics, talent measurement, and the importance of KPIs and OKRs. They discuss the challenges of managing teams, the significance of aligning team objectives with business goals, and share insights from their experiences in the industry.
In This Episode, You Will Learn:
Themes Covered in the Podcast:
Quick Takeaways:
Follow for more:
Jon Shanks: LinkedIn
Jay Keshur: LinkedIn
Jon & Jay’s startup: Appvia
[00:00:00] Jon: Hello, welcome to Cloud Unplugged. I’m John Shanks. And I’m Jake Ashaw. And today we are going to be talking about cloud platform engineering. Wow. That’s different. Yeah. Platform engineering obviously is a big term, but very generic, and we wanna kind of niche in a bit on cloud platform engineering and what it means and why it’s important to Differe.
[00:00:22] Jon: Just obviously save time and money and effort for the business overall. And the thing that you
[00:00:27] Jay: like the most, cognitive note load.
[00:00:29] Jon: So cognitive load. Yeah. So obviously cognitive load. . What’s cognitive load Jack? Cause
[00:00:34] Jay: obviously PLA soap. The term platform can be so ambiguous. Massively ambiguous.
[00:00:39] Jay: Yeah. And the fact that, so platform engineering doesn’t really mean anything cuz it’s cuz platform is so ambiguous. Yeah. Lots of things are platforms. My engineering are my engineering like a bridge, which is a platform bridge Engineers, a Tube station platform. YouTube station platforms.
[00:00:54] Jon: YouTube. Yeah, YouTube. She’s a platform. YouTube content. Yeah.
[00:00:57] Jay: Any of these things. So cloud platform engineering at least gives it a little bit more context and then, Platform engineering is becoming more of a known term in the industry, but this just, it reduces the cognitive load to see what I did there.
[00:01:11] Jay: Wow. You’ve been practicing by adding cloud
[00:01:13] Jon: platform engineering. Yeah, exactly. So I think the platform engineering is to co, like we were saying even if we to get back to like our industry, the DevOpsy Dotrice stuff we’ve mentioned before in principle. You could still engineer you could literally engineer anything for just for the sake of it.
[00:01:31] Jon: Under that terminology, there’s no real context as to what you are specifically trying to engineer as a platform. What is the platform, specifically your engineering. And that’s why. I think cause attaching to, if you’ve gone to a cloud and there’s lots of services there in the cloud, you could argue, and I know you don’t agree with this, that the cloud is the platform.
[00:01:51] Jon: You’re like, no, it’s not. It’s the service’s. The service. But there’s lots you can use. Yeah, exactly. However you wanna look at it. Yeah. How do we augment [00:02:00] the workflow for teams to take advantage of the cloud that we’ve just gone to and that we’re paying money for? , but also because it costs money. To be there. How do you also make sure that you are engineering to manage that cost properly for teams so it doesn’t exponentially grow? And how do you manage the security properly for those teams so that you are reducing the risk when you are engineering to get to the cloud properly. And I think that in itself, I think somebody was telling me today, There’s been just Amazon alone every year for the last six years, there has been 40 services released.
[00:02:37] Jon: Yeah, that’s crazy. 40 services released. That’s crazy.
[00:02:41] Jay: And 1,600 features of existing services.
[00:02:46] Jon: Yeah, and there’s some so many thousand APIs endpoints as well to it. Nuts. That’s bewildering, isn’t it? Really? To some degree.
[00:02:56] Jay: It’s pretty amazing that, that you could niche in on so many things and just,
[00:03:00] Jon: or not niche in or whatever.
[00:03:01] Jon: And you’ve got 40 per Yeah. . Yeah, exactly. Just do it.
[00:03:04] Jay: Do it all. But there’s obviously a lot of demand for all of these solutions. And how you can put. In the end, compute, networking, storage, all of these things together to create an outcome for an organization, which is exactly what a platform is in the end, right?
[00:03:20] Jay: It’s making sure that you can configure all of the things together to provide enough of a solution. You being an expert in those things create enough of a solution for someone else to not have to be an. In those things. Yeah, like cloud is exactly that. They’re gonna rack the infrastructure, they’re gonna do the physical layer, they’ll think about the virtualization, all of that kinda stuff.
[00:03:43] Jay: The security both physically and of the thing that they’re providing. And then that’s the platform, yeah. That they’ve built and then you’ll build in another platform on top of that to then again, abstract. Your developers away from the knowledge that you have or [00:04:00] the way that you’ve put that stuff together?
[00:04:01] Jay: Yeah,
[00:04:02] Jon: exactly. To get the actual outcome. Yeah. Yeah, exactly right. Yeah. Cause the developers aren’t there to get. Like bewildered, like we are of all those services and what they all mean, and however many millions of parameters that you can pass to a specific service. And then having to go and read the docs of each service to then work out what’s relevant to me in my app.
[00:04:22] Jon: That’s not a good use of people’s time if you are there to write business code and business logic. Yeah. Also, it would be
[00:04:28] Jay: really hard if, imagine if you. If every organization needed you to know how to manage infrastructure or how to be a, an operating system, admin Linux or Windows and all of that kinda stuff, and then write code and then know the business function.
[00:04:45] Jay: You’d never hire anyone. you’d never hire, honestly or there’d be. Ridiculously
[00:04:49] Jon: expensive. Yeah. Yeah. They would. And there probably are people like that. Yeah. Yeah. Who are ridiculously expensive like engineers who are probably like, when you guys stop talking about me like this because we need to get, the demand up for my skills or that one person
[00:05:03] Jay: now has like lots,
[00:05:05] Jon: A massive Oh yeah.
[00:05:06] Jon: Probably like hosting underneath and I’m available . Exactly. Putting answer, I’m a full stack everything engineer. Yeah. I know it all. I build bridges too. Yeah. But yeah, so I guess the assumptions are that we’re making on why you would wanna do cloud platform engineering is developers probably don’t care about a lot of things to do with the cloud apart from things that pertain to driving their outcome.
[00:05:31] Jon: Yeah. Cuz they’re measured obviously against getting something live in the end and getting it into customer’s hands or being able to demo the things in front of people. Yeah. Them trying to spend a load of time working with whatever this inbetweenie platform to the cloud platform. If you wanna call the cloud a platform, or if you’re just saying the cloud’s a service and you’re gonna build a platform, however, that platform’s configured matters in the end, right?
[00:05:56] Jon: , because at the moment it’s just a bunch of services. Yeah. [00:06:00] And there’s those services exist. Cloud account or a subscription or a project or whatever. You, whatever cloud end you’re in, but something needs to organize all of that right from the beginning. Pick the right
[00:06:12] Jay: services to use.
[00:06:13] Jay: Make sure obviously they’re set up in the right
[00:06:15] Jon: way. The architectural principles around the cloud to begin with, Yeah. How do you streamline that for a project? How do you streamline that for the applications? How do you make sure non-production and production is separated automatically in this platform?
[00:06:26] Jon: Like it isn’t just. Hey, IT dev needs to get a thing, because you could say, we’ve spoken about all these things on podcast before, but you could share, if you’re small enough, it might make sense. But if you’re an enterprise, you wouldn’t profess to share things, right? Cause the security risk and the data’s different and the operational requirements might be different.
[00:06:44] Jon: The SLAs might be different with the app, right? So being able to construct a workflow that matches the delivery. Standards, and security standards around delivery is probably more, what I mean for the cloud is also important. So
[00:07:00] Jay: let me see if I understood you correctly. So what you’re basically saying is trying to put the things together to make it really easy for a developer so that they don’t have to.
[00:07:10] Jay: Worry about the principles they’re taken care of in the design. So the platform that you’ve created, it just makes it super easy for you to get an outcome and align to the principles that you have either best practice in, in the industry in general,
[00:07:26] Jon: or your organization specifically. Yeah, because the cloud’s an opinionated, this is the thing, the clouds an opinionated about how you should construct all of these independent things.
[00:07:36] Jon: However, it then does have a load of documentation about how you should construct all of these things. Really? Yeah. That’s like the well-architected frameworks, all this sort stuff. But it hasn’t formed an opinion really. It’s here’s some suggestions on some opinions. They’re pillars, aren’t they?
[00:07:51] Jon: Pillars you can be guided by, I know you love this. Is it an operating model? ,
[00:07:55] Jay: this is actually not, this is a well architected framework. Oh, .
[00:07:59] Jon: Okay. Sorry about mistake.
[00:08:00] Jay: Know your big documentation bits, ?
[00:08:04] Jon: No. So one feeds into the other, yeah,
[00:08:05] Jay: totally. So basically there are things that you need to design for, and that’s what’s architected, security, resilience, performance, all of those things.
[00:08:13] Jay: But they just basically, Tell you a bunch of like opinions or things that you should take into account,
[00:08:20] Jon: but not necessarily Yeah. Considerations
[00:08:22] Jay: of, yeah, exactly. Consider considerations.
[00:08:24] Jon: Just a lot of reading. Yeah. Yeah. Really it’s like a thesis of stuff that you’ve gotta go and read and become an expert and then
[00:08:31] Jay: become an expert.
[00:08:32] Jay: So the thing that you’ve now created, even though you’re supposed to abstract away the hard bits to make it really easy for someone to consume you. Because. You’ve also got this like massive documentation everywhere that has evolved over time, that someone now needs to be an expert of, just to understand what you’re trying to say and then how that then is reflective in the platform that you’re trying to build on their
[00:08:58] Jon: platform.
[00:08:59] Jon: Yeah. And then also can you just pay as loads of money for that please? Yeah. You’re like, wow, okay, thanks for that. It’d be great if someone
[00:09:06] Jay: have an opinion.
[00:09:07] Jon: So this is how you want to clean your car. There’s the, yeah. It’s gonna be 50 pounds. Yeah. And here’s a documentation of how to get a really shiny, nice car.
[00:09:16] Jay: And that last’s gonna take you like at least two
[00:09:18] Jon: hours to Yeah. But we give you the. Yeah. And that’s all the, there’s all the house pipes, there’s all the things for you just there. Yeah. Off and go. And
[00:09:24] Jay: maybe you wanna test this on other cars before you clean
[00:09:27] Jon: yours. Yeah. Yeah. You wanna test it? It’s gonna get that cleaned first.
[00:09:30] Jon: Yeah. Before you tell everyone else that you can clean cars. Oh, crazy. It is a crazy world. Such a weird industry. Yeah, it is. But saying that, I guess because of, because they’re something, specific individual. Problems per service. And everything’s disaggregated in some ways. Yeah. You are there to get the Lego bricks and build whatever it is you’re trying to build out of these Lego bricks.
[00:09:51] Jon: Yeah. And that’s where the box stops a little bit in their shared responsibility model. Yeah. Which then means you do, you could do that each time per project. [00:10:00] Very arduous. Probably likely to be reinvention of the wheel going on across different pockets. Or you find a common way, like a platform of like, how do I do this programmatically?
[00:10:11] Jon: How do I do it repeatedly for every single project? And where do I standardize in all of this stuff in one place so I can guarantee that every. Piece of the cloud delivery has met expectations of the business obsess and is consistent and repeatable and validated and tested. And I can make changes in one place and easy to operate.
[00:10:29] Jon: Yeah. Yeah. And easy to operate and easy to get visibility on. And that’s why you do cloud platform engineering to find a platform or create a platform or buy a platform or find tools or whatever it is you’re gonna do. To. Build something like that.
[00:10:43] Jay: That makes sense. Yeah. So cloud platform engineering, just put some stuff together on cloud, just literally just to draw together, add all these leg Lego bricks on top of each other and eventually you get a house.
[00:10:54] Jay: Yeah. And hopefully that house is easy to maintain cuz you, that’s what that team is. Designed to do. But don’t you think though the term ?
[00:11:05] Jon: Next question.
[00:11:05] Jay: Not a loaded question at all. Don’t you think though? , so like platform engineering as a term is like, exists now, but the fact that the business just wants the outcome, they just want, something.
[00:11:18] Jay: Produces the time to market for the thing that they’re building, reduces the cost, the security, all of, increases the security, reduce the risk, all of those things. But now there’s these terms like platform engineering or cloud platform engineering that they’re attached to the work rather than the outcome.
[00:11:36] Jay: Do you know what I mean? , so you’re not nec necessarily measuring. You can take the amount of money that you spent on that team or that function internally is actually providing the roi cuz it’s across everything and you took a lot of time to potentially build that team or whatever, rather than trying to pick something off of off the shelf that exists.
[00:11:59] Jay: Maybe there aren’t that [00:12:00] many solutions off the shelf that exist in this space.
[00:12:03] Jon: Yeah. It’s not, I suppose though, like there will always be some level of engineering needed. Yeah, sure. And I think it’s what you are saying is it’s maybe promoting because it’s a little bit of a. Generic bucket.
[00:12:18] Jon: Yeah. It’s potentially promoting really large teams to solve any problem. Yeah. Of the business of which might not be justified necessarily because there may already be a solution to it. And a lot of times, we’re all a bit like this, including myself. If you’ve got an idea, you want that idea to be original and then when you find out that it wasn’t original, 10 other people, you’re trying to find the one thing that makes it not the same
[00:12:45] Jon: So you’re like, that isn’t quite the same exactly as my idea because it doesn’t do this, therefore let’s write a brand new thing because of that one thing that didn’t exist. Spend what,
[00:12:54] Jay: 5 million pounds on this team? Yeah. Because of that one problem. One. One thing that makes it unique.
[00:12:58] Jon: Exactly. And I’ve been cover board with that cuz you’re own human and obviously you know you.
[00:13:04] Jon: It’s natural to a point, and I guess there is a danger of that behavior becoming quite systemic in businesses. I think there was also, this is a little bit off a tangent, which we always do. We trying topic sometimes, but there was a post about someone going back on because obviously got petabytes of data and actually.
[00:13:23] Jon: Then they’ve got application workloads and other things, and really just the cost wasn’t justified. And I think they were saying that they could save 1.5 million a year or something by just buying the hardware and other things. I’m plagiarizing it in probably incorrect ways. Yeah, I think, yeah.
[00:13:39] Jon: Another thing you’re talking about, the way they’d costed it wasn’t at a project level. So what I found interesting was you’ve costed it as an entirety. Of like X and Y. We are spending X over here of X infrastructure, not correlated to any project. And we’re now spending Y over here. In terms of infrastructure.
[00:14:00] Jon: As a whole, and it costs this much, and you’re like, but you haven’t worked out what projects are paying for what within all of that. First to work out the cost per project and then actually what it took from a staffing per project. So actually get the real cost per project on delivery. Yeah.
[00:14:17] Jon: What you’ve done is look at it operationally. Yeah. And infrastructure. and it might still end up cheaper, which is fine. I just found the cost model slightly wrong and tilted to the wrong place. Yeah, because you need to look at it as how much resource capacity it even takes to deliver that project or set of projects on top of the cloud.
[00:14:35] Jon: On top of all of the things. Yeah, just total cost of ownership, really actual full, when to end cost. Exactly. You can’t just. Business won’t look at it necessarily just from that lens because it’s all costs in lots of places. So you do need to correlate it properly. I
[00:14:49] Jay: actually don’t think I have seen this article, so they just did a comparison on the infrastructure rather than the people that they need to manage that
[00:14:56] Jon: infrastructure.
[00:14:57] Jon: I think they might have said they had, I dunno, the ins and outs. Okay. So I don’t wanna be unfair too much, but they’ve definitely done the cost and they did stands. It’s not like I’m saying Okay, it, there wasn’t some legitimacy to it. They probably already have people. I guess what I, what you couldn’t really see from a modeling perspective is the relationship between the people and the cloud and the infrastructure and everything else in context to a project, right?
[00:15:20] Jon: And maybe there’d be even cheaper a hosting mechanisms for certain projects, in which case you going on prem or even the cloud. That specific clouds in Amazon or whatever it’s cost you money may not even be the most cost effective place for that project. Yeah. So you haven’t really looked at it through the you’ve had a bias Yes.
[00:15:37] Jon: That’s been biased already before you’ve been objective and say objectivity would’ve meant many lenses per project and then worked out where would the cheapest place to host that project? What was the overhead? Some going to that place? I think,
[00:15:50] Jay: That’s, but that’s also just one. So in whenever you’re doing any of this type of, comparison, You have to do it from more than one lens.
[00:15:58] Jay: Yeah. What you’re suggesting here is just doing it from the project lens, but I think there’s value in doing it from both cuz you’ll understand different things. So let’s say that total infrastructure cost and the, operational cost and all that stuff. They’ve done a, maybe a total cost of ownership there.
[00:16:14] Jay: But if you did it the other way, which I think I definitely agree on, like the project scenario as well, and like per project, if you weren’t doing, say, a centralized platform, whether that platform is gonna be on prem or in cloud, what’s the time to market? What am I driving for the organization? Is it consistency across the board?
[00:16:30] Jay: Is it, can each project be on its own? What does that mean to the developers? What does it mean to their skillsets? All of that stuff. So you have to do it from both. Top to bottom. Bottom to top. Yeah. It’s really hard. Obviously,
[00:16:43] Jon: and it’ll take a long time. Yeah. It would take quite a
[00:16:44] Jay: long time.
[00:16:45] Jay: Yeah. But then you’ll get to a better understanding really, of the decision or the impact of the decision that you’re gonna about
[00:16:52] Jon: to make. Yeah. It’s so strange. But again, that’s now engineering another platform. Cuz you’ll have to, and that might be the right thing in the end for the business and it could have ended up cheaper and maybe that calculation was enough, who knows?
[00:17:03] Jon: But yeah, it. Instinctively felt a little bit off to me just because I was like, now, but then I guess it boiled down to the chargeback models of if there even is a chargeback model. Cause it’s all flat and there is no pockets of money and it’s just it’s just. Just line items coming out from how you operate as a business and you haven’t sought to attach some cost back to a cost center, right?
[00:17:25] Jon: Or a line of business to say that’s A or a p and l, right? So that’s the profit and loss area. That’s profit and loss area, that’s profit and loss area. And actually I need to make sure that the p and ls of all these areas getting into financial space, , it’s gonna make. Functional from a CFO’s perspective on those decisions back to the business.
[00:17:42] Jon: So actually it’s easier to correlate rather than we’re spending loads of money on cloud and we’re gonna go OnPrem, and you’re like financials, the CFO surely would’ve had a say oh hundred. Maybe I should have had a say in that as well. A
[00:17:52] Jay: hundred percent. But the other thing I guess, that, one of the other difficulties of cloud really is the different [00:18:00] charging models with every service.
[00:18:01] Jay: And so because everything is consumption based, that’s the world that we live in now.
[00:18:05] Jon: And then it’s also a little bit free. Yeah. Yeah, exactly.
[00:18:09] Jay: Get you hooked on the junk, get you hooked on
[00:18:11] Jon: the joke. So yes, there are charges, but right now for you it’s free. He’s just got like a
[00:18:17] Jay: guy standing on the corner.
[00:18:19] Jay: Oh look. Have some data set up. Exactly. You want some of those data?
[00:18:22] Jon: Yeah, exactly. Have a little taste. You just won’t cost you anything. Just a little tiny little try. Just a little ni. Yeah, you get
[00:18:29] Jay: a little bit of a free, and then you have all of these different ways of charging for all these different services, and it’s really complex.
[00:18:35] Jay: You might have two or three metrics on a service. So let’s say it’ll be, this type of machine that has this profile of CPU and RAM or whatever. But then you also have disc attached to that on the size of the disc, but maybe the performance of the disc so already,
[00:18:53] Jon: and then
[00:18:54] Jay: the three, the through.
[00:18:56] Jay: Onto that disc or throughput of the network. And that’s hard to model for, right? You have to really understand it in detail and you also need
[00:19:05] Jon: to understand where you’re gonna be. Exactly. So no, you have to forecast it even cuz you, we are not gonna really necess you’ll know enough, but not to any sense of accuracy.
[00:19:14] Jon: Yeah, exactly.
[00:19:15] Jay: In the end, and there’s obviously choices that you can make architecturally. Yeah. So that your. Minimizing that cost. And obviously that takes a lot of time and expertise. But if you were just looking at it, maybe without some of that expertise, then you can quite easily say this goes away if we’re on-prem, cuz we own the kit.
[00:19:33] Jay: Yeah, it’s our network, it’s our cabling. Isn’t no one’s gonna charge me to move something from this side of the rack to this side of the rack. So it’s definitely simpler, but I think there’s a way. Optimize for it if you know what you’re doing.
[00:19:48] Jon: But that’s, I guess that is it, isn’t it? With the cloud platform engineering link is those, because even oh, if you’re going out over the internet and it’s going, that’s even more expensive.
[00:19:56] Jon: Yeah. Why don’t you lock into our transit gateway?[00:20:00] Do, I mean our direct connect? Cause it’s gonna be cheaper for you because the traffic start going through and that’s gonna be much cheaper, a much cheaper price point. . But those decisions end up mattering to how you will stitch things together, how you’re gonna engineer outcomes together.
[00:20:13] Jon: Because the more you are, the more you are driven by the business requirements to maybe reduce cost, right? In relation to offerings that the cloud can give you. Because you’re not gonna not use them necessarily. Cause what The service as in because they’ll be, what they’re doing is finding alternative ways.
[00:20:28] Jon: Yeah. And the cloud’s providing you with choices and some of those choices in context to what you’re gonna be doing. Makes sense. So if it is yeah we should have a direct connect cause it is gonna be cheap and got loads of internal traffic and blah blah. again, then things have to then connect in.
[00:20:42] Jon: , right? So then if you’re doing platform engineering, you’ve gotta work that through. Oh, now does everything connect in to some gateway so that all services that are internal can actually see each other and route to each other properly and all these other things. And this is all like, this is why it is a, Can be a complex place.
[00:20:59] Jon: Yeah. Because those are legitimate needs of the business for things to work. Yeah. And the cloud provider isn’t giving you a out the box solution. Exactly. And so you’re gonna have to come up with something. Everything’s
[00:21:08] Jay: a trade off. You have to weigh all of this stuff up
[00:21:10] Jon: versus running your own everything.
[00:21:12] Jon: But you’ve still got engineering to do. Yeah. It’s just different engineering.
[00:21:15] Jay: Different engineering, different skillsets. And you have to understand like the, because like you said, Amazon is Azure, they’re adding all of these different services every year. How do you know you are keeping up to.
[00:21:27] Jay: The cheapest and best way to operate that thing. Yeah. So that’s probably why you have an internal team that’s always doing that almost r and d, and understanding what the best practices in the industry, committing that back to the organization, if it aligns with their business objectives on all that stuff.
[00:21:43] Jon: You’ve thought though, with cost. Cause now there’s three cloud providers the mainstream hyperscalers. Plus obviously others that there, you would’ve thought the competitive element might have actually adjusted costs and it really hasn’t has it? It just didn’t, it just didn’t really, you haven’t seen [00:22:00] any reduction or reduction of the costs, even with competition increase, which is odd.
[00:22:04] Jon: I think there is though,
[00:22:06] Jay: right? Like they is there, they. Just
[00:22:09] Jon: On. They don’t need to compete from a price cause demand’s so hard at the moment.
[00:22:12] Jay: I think they differentiate and then they compete. So they make it hard for you to compare apples to apples.
[00:22:19] Jon: True. So so you can’t really Exactly.
[00:22:22] Jon: Imperatively match and be like, that’s gonna be way cheaper. Oh, a hundred percent. Like
[00:22:25] Jay: an instance type in one cloud provider for example, will have, six VCPUs and 16 gig Ram. And on the other, You won’t even have that choice. It’ll be or like it’ll be a different process. Top of that it obscure.
[00:22:37] Jay: Yeah, exactly. So because they differentiate and then differ and then their pricing models is different
[00:22:44] Jon: across the Yeah. So you used to even try and work out with it with what the comparative is Exactly. Even
[00:22:49] Jay: different in the different regions of the same lab provider. So it’s so hard to ever get a real picture.
[00:22:56] Jay: But do you think if
[00:22:57] Jon: you didn. differentiate. Yeah. And you could prove you were cheaper. You’d actually gain more traction because you would legitimately look better comparatively if the customers made a choice. Cause the customer I Cause you can prove that you are cheaper. Yeah. Easier, more easy.
[00:23:13] Jon: And soak can the customer then you might be more likely to. Make more money through adoption versus obscuring it. I wonder if it must have done the math modeling on it. , this is totally not the podcast episode at all. Way . But yeah, it’s off topic, but there must have, maybe they’ve done some research on it to work out.
[00:23:32] Jon: Whether you’d make more profit on obscuring or more profit from being looking more competitive. I dunno.
[00:23:38] Jay: So this is not quite directly linked, but I think I’ll talk about it cuz it’s associated, we’re talking about costs, we’re talking about, you know what the cloud
[00:23:45] Jon: providers, you’re now trying to find a way to stitch it back to cloud platform engineering.
[00:23:48] Jon: Not really.
[00:23:49] Jay: It’s a little bit off topic, right? But the kind of, Salespeople of cloud providers now, right? The account managers, the customers, solutions engineers, whatever they’re called, [00:24:00] most of them are now targeted on the savings that they can pass down to a customer rather than how much spend there is on a customer account.
[00:24:10] Jay: So what they have modeled, and the reason that they do that is because they’ve modeled that the customer is going to spend more in the end
if
[00:24:18] Jon: they think it, they’re getting
[00:24:18] Jay: value if they’re getting value. So it’s very related to cost. Yeah. It’s very related to the kind of human psychiatry, of like how people think about them getting value on the thing that they’ve bought and seen that over time.
[00:24:31] Jay: But the cloud providers, They have followed these data points and so they absolutely know across all of their customers that this is the thing that is gonna get you hooked on the drug. Yeah.
[00:24:41] Jon: Yeah. Yeah. It’s mad, isn’t it? In some ways. But also it’s great. Look, it’s not like these things weren’t in existence before.
[00:24:48] Jon: It’s always been vendors and vendors have always been out there and coming up with solutions and finding good ways to charge and be pricing. But I think people would be using.
[00:24:57] Jay: People wouldn’t be using cloud and all these things if it didn’t mean that their business couldn’t still accelerate time to market and be efficient.
[00:25:05] Jay: Businesses, like of course the value outweighs the cost. That’s why all of these businesses like imagine how many businesses have, been created over Covid. And it was just a massive entrepreneurial kind of hype, wasn’t it in that time, right? Yeah. All of these people were working from home.
[00:25:23] Jay: They’re not gonna rack up a little server in their house. They’re gonna go and create a business cuz they have a bunch of time now and use cloud to do it. Yeah, that wouldn’t have been possible.
[00:25:32] Jon: And I guess that’s the thing as well, to know if there’s any element of scale in your business doing that well.
[00:25:39] Jon: Enabling any element of scale. In that complex landscape, you need some people. Not saying you need like an army like get go and get a giant platform engineering team for a cloud platform engineering team. But you need technologies that enable and people and over it to actually get some conducive [00:26:00] outcome over the top, cuz otherwise the time to value on recognizing it, you might be able to do it.
[00:26:07] Jon: But it probably wouldn’t have been secure. It might not be. Yeah, and the probability of it then being repeatedly automated with all of the best practices in there is probably unlikely. And you might not realize how un best practice you are. Yeah. Until something goes and scans it all and then someone comes in and tells you and doesn’t audit and actually this is really like a lot, there’s a lot of malpractice here and yeah, this hasn’t been updated and you’re not, you’ve got keys.
[00:26:30] Jon: Static that you are cycling and you not, it’s so much attention to detail Yeah. Of what you have to do to stay secure as well. Yeah. Like the policies are overprivileged. Exactly. And actually you should be doing single sign in and why, you’ve got long-lived credentials over here and why are you doing this and why you doing that?
[00:26:45] Jon: And it’s like the list is insane. Of all the things you can do wrong and as well. And it grows Thing that you’re consuming, it grows with these thing
[00:26:53] Jay: You are consuming it grow. Even if you kept your thing as it is now, because the cloud vendor is also changing and the best practice is changing.
[00:27:02] Jay: Yeah. So it means that the PO the best practice policy, your best practice now today isn’t necessarily gonna be the best practice of a year’s time. Yeah. So you need to monitor that. Yeah. Cause it keeps altering. Because it keeps altering, and the services
[00:27:15] Jon: keep changing. The services keep changing on
[00:27:17] Jay: mature APIs.
[00:27:18] Jay: There’s new. Features of the services that exist and all that kinda stuff. Yeah. So it’s just an ever, you can definitely understand why this domain exists and why it’s such a niche. That’s
[00:27:30] Jon: why I, that’s why I was, that’s why that was important for, cause I think at the moment there is no, from what I’ve seen, cloud platform engineering group.
[00:27:37] Jon: And it warrants its own domain because you’re like, it’s so fast. Yeah. To then just put it under another vast topic of just all platforms of all the types called platform engineering just doesn’t feel right. Yeah. And I know it’s yet another term. Term in the already. Hey, we created a new term.
[00:27:56] Jon: I know I’m not a fan of it all cause , but the problem is that it. [00:28:00] Concrete enough and there’s then probably like Amazon Cloud platform engineering, right? Or yeah, developer cloud platform engineering or Azure ones. It’s not even that you have to stay there. It’s probably gets more and more niche. Niche as you go down.
[00:28:12] Jon: But I think the clarity of what it is you’re really doing is like this is gonna be an Amazon cloud. Platform engineering or developer, cloud platform engineering team, that’s really specific. It’s for developers. Bit mouthful, ,
[00:28:24] Jay: it’s, have you spoken to the developer cloud platform engineer?
[00:28:26] Jon: Team? got an acronym. Acronym it. But still I think otherwise it’s not, you’re not sure. What it, who it’s for or what it’s for necessarily, cuz it, otherwise it’s too generic. So in some ways, you don’t have to say it all the time, but you should written
[00:28:46] Jon: You’re not allowed to acronym it. You have whole, you’re so tired by the time you, the end of sentence, you know what? It doesn’t matter’s. I’ve gotta go home anyway. Cause I’m about to my, it’s already half five, but I’ve already just finished my sentence. That’s why it’s got platform .
[00:29:04] Jay: We figured it out. That term doesn’t
[00:29:06] Jon: exist.
[00:29:06] Jon: Yeah too. Don’t bother. Don’t this problem. Yeah. She was gonna come speak. It’s also an explained where you were, who you were. It was time for me to go home. Oh dear. Oh yeah. Anyway, I suppose there’s not a huge, we could talk ins and outs of it all, but I think there’ll extend, I suppose there’s also other things that.
[00:29:29] Jon: The cloud that might have to go in it, which is a bit frustrating. Cause I suppose at some point there’s then things that might, you might not consume every single thing in the cloud because it’s the best thing like CI or
[00:29:39] Jay: you’re kinda probably in the cloud in some way. Like it
could
[00:29:42] Jon: be a cloudy, it’s a weird service, but it does start to bridge non cloudy.
[00:29:45] Jon: Yeah. Traditional cloudy things. But whether they’re sas, then start theoretically cloud. I don’t, I wonder if.
[00:29:51] Jay: Cloud really is just and public and private cloud, right? It’s just if you were to really dumb it down, is [00:30:00] it just infrastructure as a service platform and service software as a service and any, anything that falls into those things or
[00:30:07] Jon: maybe considered cloud.
[00:30:08] Jon: Yeah. I don’t know. The same thing though that I have, I don’t know. And actually, cuz what makes me laugh as well with public cloud is when you speak to people, you’re like, when public cloud goes on-prem, it’s still public cloud. When an on-prem goes to public cloud, it’s hybrid. When on-prem goes to public cloud.
[00:30:24] Jon: When a public cloud decides to have outpost noise, are the things you ask people, does that mean it’s now hybrid? Yeah. They’re like, no, it’s still public. But when you talk about something like VMware, it’s like when an on-prem goes to public cloud, they’re like, that’s hybrid. And you’re like why is it not hybrid when a public cloud goes to private?
[00:30:40] Jon: Yeah. I didn’t think
[00:30:41] Jay: that was true though. I
[00:30:42] Jon: think that, people, if you ask people like, what is it when the pub, is the public cloud still called public cloud? If there’s if they’re doing on-prem services, right? Or are they now really a hybrid cloud provider? Most people would be like, no, they’re still public cloud, because that’s what they know them by.
[00:30:56] Jon: Okay. But then when you invert, when you reverse it and you’re like, so then when you are private and you start to go to public, you’re classified as hybrid. But you are the other way round. You’re not, you stay public. So I’m like, how does that work then? And doesn’t make sense to me. Even people’s, I’m not saying everybody say that though.
[00:31:12] Jon: I think
[00:31:12] Jay: actually come to think of it, that might actually make sense, right? Because when you are in public cloud and then you have, used one of the cloud services like outposts or whatever, to as
[00:31:24] Jon: opposed own by Exactly. Cloud
[00:31:26] Jay: vendor’s. The model, it’s the model.
[00:31:28] Jon: You’re still, so you’re still using a public cloud because you don’t own any of it.
[00:31:33] Jon: You still as a service, you’re not, it’s, but you might be still using VMware as a service, but it’s not.
[00:31:38] Jay: That’s the point, right? So when you are in your own data center, it’s not a service, it’s just infrastructure. True’s not, yeah.
[00:31:45] Jon: So that’s why. Yeah, that’s why. Yeah. Yeah. Oh, I was just clarified that.
[00:31:48] Jon: That’s, there you go. This always stay, it always stays public cloud until the point that. Own the kit. I’ll take some accountability for it.
[00:31:55] Jay: Yeah. If it’s on your books, if it’s, you’ve paid capital. Yeah, that makes sense. If you need to own it, [00:32:00] whatever, then
[00:32:00] Jon: It’s yours. That ruined my facetious little statement, didn’t it?
[00:32:04] Jon: My controversial facetious statement. Correct. And on that happy note. Yeah. So cloud platform, nothing left to talk about. Do you think Was just another one solved?
[00:32:15] Jay: Another one solved. We find, I, I mean it, I think it’s gonna be actually really important for people to start aligning them towards cloud platform engineering, right?
[00:32:23] Jay: Because they, you’re now talking about something that’s a bit more specific, a bit more specific that you can kind of niche in on and the problems that need to be solved in that area, rather than just saying platform engineering or something. I think we
[00:32:36] Jon: did a, I think we did a podcast and we were talking about roles as well.
[00:32:40] Jon: I think you asked me around like what you would call if you weren’t gonna call them DevOps engineers. Yeah. Or these terms, because they don’t really mean, cause I certainly don’t really mean very much anymore. Controversial
[00:32:51] Jay: again. Yeah. That was in the the state of Puppet, the puppet report that came out.
[00:32:56] Jay: State of DevOps. They said we tend not to use the word DevOps anymore cuz it means nothing .
[00:33:01] Jon: Yeah. It doesn’t really mean anything. That’s what I’m, doesn’t So you’re saying, what would you call ’em? And I was like I’d call ’em by terms that already exist like you’re a. Engineer because you’re engineering things for cloud.
[00:33:11] Jon: For cloud, yeah. Yeah. So you just call yourself that and it’s actually quite specific. Or you’re an Amazon cloud engineer if that’s all you do. Yeah. And that’s your skillset. And there’s nothing wrong with that. What about, it’s fine to tell you, tell call yourself what you do You think this is okay? It’s still not
[00:33:25] Jay: attached necessarily to the app.
[00:33:26] Jay: So let’s say you are, I know it’s
[00:33:28] Jon: not gonna touch. No, I know. But a developer’s not called like business logic producer, are they? Should they be?
[00:33:33] Jay: GitHub Engineered . It’s a location, an outcome, but it’s
[00:33:37] Jon: theret. Anything though there isn’t anything else Yeah. That you could attach to cuz it’s a facilitated role.
[00:33:43] Jon: Yeah. So I suppose you are facilitating an outcome for someone else, which makes it a harder. Job, and you might take DevOps principles without a just go your cv that you understand the methodologies, not that you are a DevOps, that you just understand how to do it. That’s it. Yeah. What it means, and yeah, I think overall, but [00:34:00] why I just talked about, oh yeah cloud from engineering,
[00:34:04] Jay: coffee.
[00:34:06] Jay: So overall, I think what you just said makes sense, but the reason that. Ambiguity. So like the DevOps engineering thing, people
[00:34:14] Jon: were people all in jobs ,
[00:34:16] Jay: but people started like abusing the term. So yeah, they would call the DevOps engineer when they were just infrastructure or something like that. Didn’t have the practice or the mentality or whatever. So then you kind of niche in on term hope that the industry aligns and uses the term in the same phrase. And when it starts to be. Badly. Then you have to figure out a new, better term to use to reduce the complexity or reduce the cognitive load on what people like.
[00:34:44] Jay: You shouldn’t have to explain what a DevOps engineer does, but every single time. Now what about a cognitive
[00:34:49] Jon: load engineer? ? Yeah. What is that load? I engineer down. I reduced down the code. Load. Load. Yeah. I engineer. It’s down. Maybe that’s like a psychologist. . Cool. Thanks everybody for listening. Obviously you can reach us on Cloud Unplugged on YouTube and Twitter and things like that, so it would be good for people to tell us what their thoughts, tell us what your thoughts are.
[00:35:13] Jon: Yeah, exactly. And if you don’t agree, even better. If you don’t agree, just don’t say anything.[00:35:21] Jon: obviously that’s not true, but yeah. Anyway, thanks for listening. Cheers.
Part of the Appvia family.