PurePerformance - The Future of DevOps: Can ChatGPT be Your Ultimate Engineer?

Episode Date: April 10, 2023

DevOps didn’t die when the world started raving about SRE. And while some proclaim that platform engineering finally kills DevOps it is more an evolutionary process to bring DevOps practices to a new audience that is building and running apps on a new technology stack.But what about ChatGPT? Can it be the best DevOps engineer you ever had? Will it be able to build and optimize our delivery pipelines? Will it tell us which products to build and how? Which architecture to choose and how to best design it for operations?Tune in and hear from Stephen Thair, DevOps Thought Leader and Founder of DevOpsGroup, on what he has seen over the past decade working in the DevOps space and why he thinks that while ChatGPT will be disrupting many jobs it is a great opportunity to boost creativity and efficiency for many DevOps and non DevOps folksAlso don’t miss to read Stephen’s 2023 predictions we mentioned in our discussion

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance We're all sitting here, at least in the States, on eggshells, waiting for some big stuff to potentially happen. But nothing yet, and I got nothing. See, it's the most boring intro ever. I totally failed you, and I am sorry to my Austrian overlords. And I just don't know what to say.

And I was going to try to squeeze in a Monty Python joke in there for our guests. But, you know. But, you know, better this than your strange nightmares or strange dreams that you had the last two times. Because they were awesome. Yeah, well, I figured I needed to give those a break. I'll come up with a good, you know, nightmare next time, except for, you know, the regular waking nightmare that is my life. But except for my job. I love my job. My job is the best part of my life, I gotta say.

Hey, a quick side note, though. I was just looking into some stuff because some things are going. In May, and I want all of our listeners to realize this, too, in May, seven years of this podcast, Andy. Seven years? So we're getting close to May. It's going to be seven years.

I didn't know that because it feels, I guess, with the whole pandemic, it feels like we lost three years somehow. It doesn't feel that long. We kept on going, but I think our listenership went down during the pandemic because people were commuting. Either that or this got sick of us. Either way,

fantastic stuff. To continue the ball rolling, we have more fun topics, right? Exactly, exactly. And I remember last episode, and I want to actually start introducing my guest. Because one of the things that I think from a DevOps perspective has impacted us a lot in the community was a famous saying by Werner Vogels from Amazon. He said, back in 2006, you build it, you run it. And I think with this quote that he made,

he inspired a lot of us to actually think about what does DevOps really mean in practical terms? Reducing and removing the boundaries between DevOps. Yet, in the last episode we had with Luca, he said, you know, you build, you run, it doesn't scale. And then he made an interesting reference. He said, you know, think about it. Werner Vogels made this famous claim back in 2006. That's 16 years ago, 17 years ago, if you do the math. Which means back then Amazon

was a much different company than they are now. And they outgrew probably that as well. Now, without further ado, I know we have a guest today who has been in the DevOps space for many, many years. And I would like to hear from him, first of all, what inspired him to start with DevOps? How many years he has in DevOps? What's next? We want to talk about platform engineering.

We want to just hear from him. And now I'm really shutting up. Steve Tyer, thank you so much for being on the show with us. Welcome. Thanks, Andy. Thanks, Bharat. My name is Steve Thayer. I'm the co-founder and former CTO of a company here in the UK called DevOps Group. We were founded nearly exactly 10 years ago. Literally, it's our 10th anniversary in two days' time. Probably by the time this podcast goes out, we'll already have turned 10. I've been in the IT industry for 33 years, pretty much doing nothing but web platform, web operations for 20 of that, and then moving in,

you know, halfway through that, moving into DevOps, and we started DevOps Script 10 years ago. Where's DevOps? What's happened? How did we get there? Oh, there's a lot we could talk about. I think you mentioned we were talking just before we started about, you know, is DevOps dead and is platform engineering the new thing? And I go, no.

You know, in the same way, it wasn't a new thing when SRE, it wasn't dead when SRE came out. You know, it's, you know, I like the way that, you know, Google set up SRE. They sort of, you know, it implements the class DevOps. You know, it's our way of doing devops but it's not you know and to say platform engineering is a replacement for devops is i mean to be honest it's naive if you really want my honest opinion of it you know it's you know the market has got to market you know and

putting out a putting out an article that says devops is dead and everybody jumps on it on Twitter and LinkedIn and goes crazy. You know, I understand, you know, you've got a court controversy. But, yeah, DevOps is far from dead. And, you know, we can talk about that for as long as you want to talk about it. Yeah. Actually, this triggers a memory. Brian, I'm not sure when did we have the episode. I think it was earlier this year.

We had a Googler on the show, and he actually said, you know what, at Google, we didn't know what DevOps was until we went to one of the DevOps conferences two years ago, and we heard the term, and then we realized this is exactly what we've been doing for years. We just called it something else. Also, to your point, we didn't make DevOps go away, didn't kill it. And it's just like we're all talking about similar principles.

We are talking about reducing toil. We are talking about removing boundaries where boundaries should be removed. However, and I think this was an interesting takeaway I had. Steve, I had the pleasure of interviewing Kelsey Hightower on stage at our conference. And he actually made one point where he said, you know, in certain aspects, removing boundaries and removing walls doesn't make sense. There's good reasons why you want to have solid and good boundaries, which means interfaces between obviously your different services and interface between a platform that you may build

and then the people that use the platform, clear, defined boundaries. And so I thought that was also interesting, right? Because with DevOps, we would say, let's break all the boundaries. Let's break down all the walls. But then he said, well, for certain things, you need to have clear boundaries with a well-defined contract so that every side of the contract knows exactly how to interact with each other, what the responsibilities are

on each side, and what to expect from each other. I thought that was really interesting too. And I think exactly what you've just done, to me, strikes to the heart of what I think DevOps has brought to the table over the last 10 years. You're describing boundaries between teams. You're describing boundaries between organizational silos, but you're using software engineering language to do it. You're talking about bounded context. You're talking about contracts. You're talking about APIs. And I think, you know, we talk a lot, and if you've read Matt and Manwell's book, Teams Apologies, you know,

they talk a lot about reverse Conway's law. You know, Conway's law was this idea that, you know, your application architecture will reflect the organizational structure of the teams and that built it and into the team topologies is trying to almost reverse that and say well we know we want loosely coupled architectures we want them to be able to move at their own pace you know deploy at their own frequency we want them to be able to be scalable. Okay, so if that's the architecture we want, we've got a reverse engineering organizational structure off the back of that. So we've got to have, you know, teams that have a well-defined bounded context

that are loosely coupled, you know, that can move at their own pace and that can, you know, deploy and change and stuff with an understanding that we still need it to be cost effective, we still need it to be secure, you know, all of those kind of things didn't go away. And I think that this is where that, you know, you said, you know, the previous, you know, podcast, you know, that DevOps doesn't scale. Yes and no. And, you know, we always that devops doesn't scale yes and no and you know we always i've got slides in my deck that has you know a picture of sort of you know

werner at one end and kind of you know aws at one end and google at the other end with a sort of you build it you run it through to a sort of more sRE model at the other, you know, the more Google approach. You still have a more what would be a centralised ops team in some ways, but you've very much changed the way that ops team interacts with the dev team. They're responsible, but they're not accountable. Do you know what I mean? The accountability still stays with the product team. And I think that this is where Werner, when he said you build it, you run it,

you know, you had that very famous, you know, memo that came out from, you know, the famous API memo at AWS, everything must be, you know, an API. There's no, you know, database coupling. There's no memory coupling, you know, and anybody who doesn't follow these rules will be fired. So they had the benefit of having, building a loosely coupled application architecture, therefore they could have a loosely coupled team architecture, you know,

because they built a system that supported that. For most people, their applications, you know, you're trying to run SAP or Oracle Financial or whatever. You know, these systems don't support that model. You know, they're trying to and they're getting better. Okay, I don't want to slag them off too much. But, you know, everybody has these big, clunky, enterprise monolith applications that have been around for 20 years, and they're a long way from loosely coupled.

They're not particularly modular. You know, people are trying to pick them apart to pull the monolith apart. And so, like, to say that DevOps doesn't scale isn't right, but it's not wrong. It's not right because if you've got a modern application architecture, then you build it, you run it, it can scale. If you're in this legacy enterprise world where most of us have spent our careers, no, it doesn't work because you've got a million other things about, you know, because the application just doesn't support it for staff,

and then you've got a whole bunch of other factors. Make sense? Yeah, it does. And I really encourage folks that listen to this and wonder what episode we're talking about. So check out the previous one with Luca. I think what he said, he didn't say it doesn't, he said, if you think about it,

if you're a small organization, and back then, you know, AWS was much smaller, it's possible that everybody, the people that you hire, you know, you know the tools, you know how everything works end-to-end. You can build it, you can run it. However, if you all of a sudden go into an exponential growth phase and you hire new engineers, 10, 50, 100 a month or a quarter, you cannot assume that they will all of a sudden know all of the tools that they need to, you build it, you run it, right? And that's where he said at some point, and I asked him the question,

so at which size do you see that organizations need to start thinking, pivot towards something like a platform engineering approach? And he said typically between 50 and 100 engineers, this is when you either see two things happening. Either the organization from top down says, okay, we've outgrown, we're no longer a small startup, we're no longer 50 people where everybody knows everything. We need to either now start from top down to say we started investing into our internal platform as a product and basically come up with our own opinionated platform that allows us to do the stuff we want

to do it. And if you don't do this he said the second option is that eventually it will happen from the ground up because people will be just you know not happy with that their code changes don't go don't go out the tools that they are currently using don't work and so on and i thought that was that was really interesting um uh his his explanation of this right um and he talked about the golden paths. We also talked, Brian, you brought it up, right? We talked about opinionated platforms versus other opinion. You brought up your old time favorite. Well, not quite favorite, but yeah, the approach,

Yeah, they were trying to push this idea of the opinionated platform and might've been a little too rigid at the time, but it was also, I think, a little ahead of its time because everyone still wanted to play and all. But the idea being, hey, if we have a team that takes care of all the other stuff, you as a developer just have to worry about getting your code and pushing it out there. We'll take care of the rest of it, right? Yeah. there. We'll take care of the rest of it, right? And that's where it seems to be going with all these changes that people are doing, all the customizations they're doing to their Kubernetes platforms. It seems like we're trying to get back to somewhat of that model where we don't have to think where we're running it so much anymore. We just have to worry about developing it and someone else takes care of running it. Yeah.

If we go back to sort of where, you know, DevOps started and this idea of breaking down silos and stuff, I don't think that that ever meant you build it, you run it, was the be all and end all, you know, that that was the only way of solving the problem. But what it did mean is somebody from operations has to be in the room when you're designing the application and not just thrown to it at the end. And if you look at, you know, let's be brutally honest, there's nothing new in DevOps. Everything that is DevOps was taken from, you know, dozens of other sources

like Lean Manufacturing. And, you know, Lean and Manufacturing has this idea of sort of design for manufacture. What changes can I make to the product that makes it easier for me to manufacture that thing, you know, and this constant, if I change this, I can get rid of one screw, and getting rid of one screw will save me so many seconds and save me, you know, in some cases, you know, hundreds of thousands or millions of dollars, you know. And then you sort of have, you then have design for operations, which is once it's out there, and, you know, I mean,

I drive a Tesla, you know, and I love my Tesla. But there are some things in the Tesla which are not very good that when somebody needs to do something, change something relatively simple. I've got to take these five other things out in order to get to the one thing I need to change. That's not good design for operations. How do you make the things that are most likely to break also easily accessible? So if you think about that, I mean, my background is infrastructure operations. I've run large-scale websites, large-scale job boards here in the UK.

And, you know, it's like there are some times you go, could you have not? But you have made this so difficult for us to run, you know what I mean? The bits that need to be scalable or the bits that need to be shardable in particular you're horizontally scalable they're not very horizontally scalable because you didn't think about state properly or you know you didn't think about splitting reads from rights so we can have you know read replicas you know even if all rights

have to go back to the same place you didn't think about putting all of the logs that are being emitted by this system into one place. I'm talking, you know, back in the days when you had to go and manually grab through the logs yourself before we had, you know, tools like Dynatrace. So, you know, this idea that DevOps, you know, we need to have operations in the room to bring those operational concerns in the design phase. And conversely, we needed to have people in development

to understand that just because you've shipped it does not mean your responsibility ends. You can't ship SHIT and expect us to be getting out of bed at 3 a.m. in the morning and run it, you know, you're going to be on call as well. You know, you're going to have responsibility. And this is the thing I mentioned before about SRE, where SREs are responsible for keeping that system up and line, but they're not accountable. You know, you can't delegate accountability. Ultimately, the product team and the product donor own their product across,

you know, as some people say, from inception to retirement. And again, these are other concepts that have been brought in from a DevOps perspective. Just shipping code isn't enough. And if that's your mindset, but I come back to, you know, to Brian's point, absolutely, we should be making it as easy for you to ship that code as possible. And if that's a paved path that ends up running in Kubernetes, you know, and it's super easy to deploy and we're taking all of that, and again, coming back to team topologies, we're taking all of that cognitive load off the developer, well, that's more brainpower he can spend writing

and building the application because he's not worried about, I don't know TCP IP. I don't know HTTP. I don't know, you know, SQL database technologies. I don't know Kubernetes. I don't know. I've got to learn all these things. And this idea that everybody was suddenly going to become a super person and

know everything about everything it was very disrespectful to operations people this idea that developers were going to take over operations was very disrespectful to the idea that oh well operations people clearly know nothing and any decent developer can learn what an operations person learns in a couple of days and then we can fire all the ops people it was immensely disrespectful sorry i always thought that about the the disrespect and you can also look at that as disrespectful to developers too as if they're going to have time and the ability to take on all that stuff it's like oh yeah sure you're a developer you don't you do nothing you can take over the operation side it's like how how are they supposed to do that? But I think a lot of what this boils down to is just terminology, right? I think you said, I don't think you used the word instantiate, but you said it's like, it's loading the class

of DevOps, like for SRE or something like that, right? This is just the maturity of the paths these are going down. And it's a terminology change. Two other anecdotes I put to it is in our own space of observability right I remember when people started throwing this term observability around a few years ago I was like what's this new buzzword because we already you know there was three three main pillars of observability which was traces logs and metrics I'm like yeah we've all been doing that for like decade and a half or two decades now so what's the difference really it's just a new word that people are suddenly

excited about like we've been excited about this forever but then you start looking at it and observability really is a bit more advanced a bit more mature of a model goes a little bit more in depth but at its core it's still the same as what we've been doing right but now there's a new word because it's changed it's evolved it's become it's expanded from the original idea and you could i mean we see this all the time just in regular society when you have changes from like words like from like disabled to differently abled right it's new awarenesses new concepts come into it so if we're talking platform engineering versus SRE versus DevOps you know I do agree to say DevOps is dead is somewhat naive in that way it's just it's expanded it's morphed it's evolved

at its core all those principles are still in there but now there's new layers new concepts added to that that are expanding and expanding it so it's it's it's just a matter of changing um and it's a lot of it's just semantics but it's uh i think if you were to take a look at something like sre and platform ops define that completely and then define devops completely those other two will have more to them than devops does because devops at its core was initially defined as x right and then people started adding to i'm just you know going back to the basics of what it was because DevOps at its core was initially defined as X, right? And then people started adding to it.

I'm just going back to the basics of what it was when it came out. And yes, you can say, because we obviously saw DevSecOps, DevSecBizOps, all these things started expanding. But then it's like, okay, well, this is an easier term to say now, right? So now let's change it to the next iteration or incarnation. It really just comes down to a different word. At least I think that's just, I don't have as much exposure to this stuff, but as I'm learning, as we're doing these podcasts, these are just some of the ideas and thoughts that go on in my head about it. But I could be

completely wrong. And I feel like you're about to smack me down, which I will. No, no, no, no, no, no. It's a complete, I thought the exact same thing, you know, I mean, I met Andy, how many years ago? 10, probably. Yeah, at least. It was back in the age exhibition times, web performance optimization, 2010. Yeah. You know, so we were doing, I was doing a lot of load testing and web performance. I was working for a company that did load testing, you know, website monitoring, stuff like that.

And, you know, when observability came about, I was like, you know, it's just new wine in old bottles. But the thing is when a new concept comes around, even if it is, you know, new wine in old bottles, it speaks to a different audience. It brings different people into the field. You know, I think one of the problems that monitoring had for a long time and used to annoy the hell out of me was the the performance tools you know back going back to you know don tracing the

core apm days were you know the ops people weren't allowed we didn't have enough licenses or you weren't allowed to use it because there was a performance engineering team or only the devs have had access to that performance data and again you know what we're just constantly seeing everything is systems thinking everything is more holistic everything is trying to bring more people in with different perspectives and i'd say that is probably what observability has done for classic monitoring. I would say though that I would always say that DevOps is the overarching concept and everything else is the subset rather than the other way around. I mean, if you go back to the original model of, you know, culture, automation, lean, measurement, sharing, the CALMS model of DevOps

that you don't really hear much about anymore but was talked about very early. I don't think platform engineering talks very much about culture. I don't think it talks very much about lean. I don't think it talks very much, you know, it talks about metrics but it talks about sharing. So it's only covering two of the four, you know, of the five pillars of DevOps if you go with the CALMS model.

Okay, yeah. But, yeah, I do take your point that sometimes we need new language to bring new people with new perspectives into the field. Yeah, I think this was also one of the agreements we had when I did the Is DevOps Dead? webinar where I was on the DevOps is not dead and then two others were on the other side.

I think in the end we all agreed that after a couple of years, you may just need to come up with a new term, even though if you are, again, preaching the same things, but A, there's a certain history and maybe also confusion around the term. If too many people have talked about, let's say, DevOps in different ways, then there's a lot of confusion everybody has a different opinion so that gives you a chance after 5 10 15 years now to say okay it's all good but we have new people that we want to educate on this

and things have moved on let's find a new term and adapt everything we learned under that new term so that people that are just starting with this have an easier way of grasping it instead of going back 10 years in history and learn everything that has been talked about DevOps. So maybe that's also a way of looking at it, right? Yeah, it's over time. What does Agile mean to you?

I mean, we're like 23, 24 years now since the Agile Manifesto was first published. And, you know, like agile has become such an overloaded term. And, you know, a little slight digression, and I apologise to the people that we know who invented the observability term. Hello, not going to name any names. But, well, a little tip for anybody out there who's building a product.

If you can get Gartner or Forrester to invent a new magic quadrant for this new term, which you've defined as a superset, and you've defined that it has these essential characteristics, which just happen to match the essential characteristics of the product that you've defined that it has these essential characteristics which just happen to match the essential characteristics of the product that you've just bought to market that is a very very good marketing strategy you know you you know it is very very good you know i mean even you know even arguably when the the the net original generation of apM tools came out, well, not the original, that's, you know, CAY, but that next gen of APM tools came out 15, 20 years ago now,

you know, they redefined a new quadrant and then over time what that thing got expanded and expanded and they had to add new features because you wanted to stay on the magic quadrant. But, you know, I mean, I was talking to somebody the other day, I wanted to invent a new term. I wanted to reinvent the CMDB, the Configuration Management Database, and I wanted to talk about cloud metadata management

because I think there is a massive gap in the market around the management of cloud metadata in a way that is easier, better, faster than just tags because I don't think tags are good enough. And I think there's a lot of metadata which is still not being captured. And I think for the very reasons you just mentioned, the CMDB term has got so much baggage that if you wanted to bring out a new product in that space, you have to define a new term and then you get the analysts excited about this new term and they can publish blog

posts about the new term papers about new, new term. And then you can have a conference about the new term, you know, and, and, you know, we went through this, you know, 13, 14 years ago with, with performance, with performance, you know, when Steve Souders books came out and then suddenly you started to have, you know, back in the days when there was only, you know, not very many people coming to have, you know, back in the days when there was only, you know, not very many people coming to Velocity, you know, and then it became massive. And then kind of web performance kind of tailed off about five to ten minutes on what you said earlier.

Because you said, you know, DevOps, make sure you design it for operations. So for you, one of the key things, one of the arguments you made earlier, if you do it right, and if you design a product, bring in operations early on. But let me ask you a question. If you think about product development, software product development, if a product manager, product owner, they kind of try to build and define the features, the user journeys, right? Of, you know, this is what the product should do.

Let's take a simple product, ordering food. If you build, and we know what the use cases are. Do you think with the people that you have seen that are building new products new software products do they or who should be actually that maybe that's the better question who which role needs to factor in the operational aspect of a product because right now when i think about designing and building a new product i just think about features features features i want to build something that actually makes my end user happy.

You've got featureitis. You can get a cream for that. Yeah. But who is responsible for that in a modern development team? Is it the product manager? Is it the product owner? Is it the architect? Who needs to connect the trial basically not only

the the feature and the performance but also the the operational aspect the designing for operations so if you've ever gone to um mind of the product.org the mind the product conference based the conference for product managers I think it's still running. Product Tank, their model of what a good product manager is, so let's just define a few terms. Product donor is a term for Scrum for a person who does a particular role within a Scrum team. I prefer the term product manager for the person who is defining

and setting the product for the strategy. And they define a product manager as sitting at the intersection of three circles in a Venn diagram. It's the business, what does the business need, the technical need, and what does the customer or the user need? And the product manager's job is to balance out those three things because the customer might want something, but the business might go, we can't afford that.

We don't have the capital to build that. It's not profitable. You know, conversely, the business might want to do something that's not really going to be very good for the customer, so you've got to balance it out the other way. Then you also got, well, what's feasible technically? You know, do we have the right people to, you know, to build that? So from an operations perspective, yes,

I would say the product manager has to be the person who is bringing in those what used to be called non-functional requirements. I prefer the term operational requirements. You should have operational requirements and certainly operational acceptance criteria into the system. you should have operational requirements and certainly operational acceptance criteria into the system and that is definitely the product manager's job now most product managers come from one or through one of those three areas they're either ex-techie people ex-developers who sort of went up through architecture and then became product managers. They're either business people who are real subject matter experts in the business and what the product needs to do from a business perspective, or you tend to see they've come from the

user experience, user research side of things. And depending upon where they've come from, they get pooled in one or more directions. if you're somebody who has come from the user manager you know the user research user experience side of things you're probably going to be really focused on building the best ui getting your customer voice feedback and building all these new customer features and you might not be as worried as you should be about you know profitability, profitability, you know, and building features that are actually sustainable and unique. And you might not be as clued into the technology. And then you can run through all the various iterations.

If you're a techie person, they tend not to worry about doing focus groups and, you know, usability analysis and all of that kind of stuff because I know what the customer needs and I'm going to build the best technical platform and it's going to be amazing and it's going to be fast and it's going to be unusable. And, you know, so, you know, and I think this is where we ask a lot, you know, a good product manager is worth whatever you're paying them if they can balance all three of those things out. Cool.

And then in your triangle, obviously, and maybe this is what I tried to get to, the business, the end user, and IT. For you, IT is really including development and operations, right? I mean, I think that's the clear point. Because what I have seen in the past, right, and this is typically also how you're trying new product ideas. You build something, but you're really focusing first on building something that the business thinks makes sense and also that the end user can use. But in the beginning, you don't really know if it's catching on. And so sometimes you're neglecting certain architectural decisions and operational decisions because you want to just get things fast out to the market and validate it and then the problem is if it catches up well

it's on the one side not a problem because you build something that actually the market needs and you can sell but then if it catches up then you have to be really fast and sometimes you don't have the time anymore to then go back and think about and put in all of these as you call them operational requirements because then you know sometimes the train is moving too fast and then the question is do you actually get the time or to maybe sometimes even rebuild the whole thing now for with with all of the three dimensions kind of nicely aligned so it's gone steven yeah yeah i was i was gonna i was gonna quickly interject and say it to say to andy they're talking about that being a semi-good problem whatever though i equate that

to the super bowl commercial issue where um if you if it is successful but you're not prepared for it's actually a failure because you you didn't uh uh anticipate the needs and that's what you should be doing from from the needs and that's what you should be doing from from the start but anyway stephen that was just a quick aside i wanted to throw in there but yeah yeah funnily enough um shout out to my to my mate perry who used to work for one of the the large chicken companies um their marketing people decided to um uh you know to run an advert announcing the ticket sales of a very large band in here in the UK during the middle of the finale of X Factor or something like that.

And within about 30 seconds of the start of this advert, their website had spiked to like 10x the traffic. And unsurprisinglyprisingly nobody had told ops and nobody was ready for it and just this expectation that it was instantly going to be able to dynamically scale in 30 seconds to 10x the kind of baseline traffic that you would expect. What you're talking about here is the old lean startup you

know so there's the book lean startup this build measure learn cycle don't put in features that you don't need at the start because you don't know whether your product's going to be successful you know get that minimum viable product out the door and then, you know, think about, you know, rebuilding it later on. And I do believe that that is right. I've seen too many startups, you know, I'm a mentor with the Microsoft Startups program. I've seen too many startups spend, you know, 18 months building this amazing product that they think that the market wants and they've never actually put it in the hands of a customer. And you can put it in the hands of a customer with HTML mock-up.

You can put it in the hands of a customer with some bits of paper on the wall and still get a lot of useful feedback. But I think there's a baseline of sound architectural decisions that i would you know that i would i would expect anybody to build a system even if it's a lean mvp stuff like is it horizontally skate you know it stateless, you know, or at least the state is persisted in some external store? You know, is it, you know, is there some element of monitoring and observability built in?

Because let's be perfectly honest, it doesn't cost you much. You can do it open source if you want to to get started using sort of one of these increasingly we're seeing these open telemetry frameworks coming out you know you can do it open source if you want to and then move to a commercial project you know commercial product later again so i don't want to have to worry about running this massive elk stack anymore you know and i saw one of my big retail customers did that you know they were spending 150 000 pounds a month or something on running this elk stack that they could have just stuck in something like dining trays for a fraction of the cost but they just got they got so bogged down in it um so i think i think you there are sound architectural principles that i

wouldn't compromise on from day one but yeah don't put in all the bells and whistles. Coming back to Werner Vogels that we mentioned at the start of this podcast, back in the day, this is a long time ago, you know, he went through a presentation that was talking about the sort of iterations. I think it was actually the Salesforce platform at the time. But, you know, when you look at these systems, you realise that they're on version 7 or version 8.

You know, they have gone through major rewrites of the platform. And this, again, comes back to this product, the product management and product thinking and a certain degree of awareness by the senior management that, again, comes back to this product, the product management and product thinking and a certain degree of awareness by the senior management that, yeah, yeah, this has gotten so far now, we can't get to where we need to go from here, so now we're going to spend six, 12 months pretty much doing a core rewrite that is now going to optimise for a different layer of scalability

or a different set of factors that are now going to optimise for a different layer of scalability or, you know, a different set of factors that are now relevant now that weren't relevant or will be relevant to us moving forward. We have to do this now. It's become an existential thing because, you know, I think you've just got to look at, you know, Ticketmaster's ticketing platform in the US and, you know, I know for a fact that they had seven different ticket platforms globally at one point, you know, the, you know, you know, I know for a fact that they had seven different ticket platforms globally at one point, you know, and, you know, a lot of people are trying to, you know, solve that

problem. But the problem is it's very hard to sell that kind of scalability performance rewrite. Like you go, you go up to the boss and says, right, you know, I want to spend $3 million with a team of, with five scrum teams for the next year. And I'm going to do a ground up rewrite, you know, of the database of, I'm going to, you know, make it more microservices. I'm going to bring in Kubernetes. And in the future, you know, it's going to be way cheaper to run. It's going to be way faster. It's going to be, you know, just easier to manage and blah, blah, blah. And they're going to go, yeah, but what have I got? Once you've finished, what have I got? Well, you've got exactly the same as what you started with, a retail platform or a ticketing platform

or whatever platform. It's just going to be faster and better and then somebody else comes along let's add you know uh you know 3d cdm stating previews for where your ticket is the state you know in a new feature that's going to take you know three scrum teams six months to build that feature well yeah let's build that let's build that and just you know right up to the point where the thing falls over and then they complain that why didn't you tell me that the thing was going to fall over and then everybody just throws their hands up in the air and walks out at that point.

But do you know what I mean? So what am I trying to say is it can be very you must understand that you will need to rebuild and re-architect your platform on the journey and you've got to build that into your financial model and build that into the understanding of your management that this will happen eventually and it's going to cost money but you've got to spend it does that make sense it makes a lot of sense yeah yeah that was a hot topic in the beginning of devops was that these initiatives had to come from the top down. I mean, didn't have to, but the most successful ones were where you had the C-level suite or the high-level suite saying,

we need to do this project, we need to modernize, we need to get our own journey of, what was it, 10 minutes to get the code out or an hour, whatever it was. But that has to be coming in supportive from the top, which means they have to have that understanding you're talking about of, yes, we know this isn't going to be a shiny new bell on the site. This is just some underlying architecture, which is going to pay off in the long term. But it's that long term thinking that you have to get that support in for. But that kind of really kicked in once DevOps started coming in several, you know, 100 percent. I mean, if you if you go to the IT revolution website,

the people who do the DevOps Enterprise Summit, lots of case studies and case study compilations there, and almost every single one will talk about, well, we started, you talked a bit about bottom up. We started doing some stuff bottom up, and we got everybody excited, and we got so far, and then at the point at which we had to bust out of our silo the manager of the end of the next silo along said sod off you know you're not you're not interrupting whatever my plan is and and then people go oh now i'm stuffed so the the stuff that was successful was top down and bottom up

simultaneously you know you had this excitement of the engineering team that wanted to try these new ways of working these new technologies, and you had almost certainly a new CIO or a new CTO. I very rarely see it when it's been the person who's been there for 10 years who has been running IT for the lowest possible cost for 10 years, suddenly comes back from a conference, you know, like Moses coming down from the mountain, having seen the light and suddenly decides to rip up everything he's been doing for the last 10 years.

You know, generally it's a new person come in and the new broom wants to make a mark and they're going to do something different. it has to be both top down and bottom up hey steve i i want to do one more quick topic i know because we've been we've been recording this for a while now um in you had a blog post or i think it was a linkedin posting earlier this year kind of like your predictions of of 2023. And a lot of things were in there. And I don't want to go into some of the, it was really interesting to the politics and the geopolitical and what's happening. But I'm going to go into this, but you obviously brought up the chat GPT and AI. Do you think,

what's the benefit of all of this based on your thoughts on the DevOps movement or anybody that is building software? How can we benefit from JetGPT? Will it be able to create our pipelines for us? Will it be able to show us a better way to deploy? Will it be able to give us better recommendations on what product to build and not to build? Any thoughts on that? Yeah, it's interesting. I was talking to a guy, he was a startup founder, ex-Googler, had his fingers in a few startups and he was saying he, all of his developers use Copilot

with GitHub and he just says, you know, the productivity gains that they're seeing with having this sort of AI-enabled Copilot that is suggesting, oh, this might be a useful bit of code for you, you know, are insane. So, and I don't know if any of you have seen the Microsoft in the Office 365 co-pilot demos that they've got, you know, build me a 10-slide slide deck based upon this press release for our new product. Slide deck. And you're going, like, what?

Do you know what I mean? Or, you know, like the productivity gains that are available for the – if the use case matches what the tool can do. And I haven't really even pushed or explored too far. But, you know, come back to – we were talking about some, you know, Dynatrace earlier, you know, you said you've got your customized query language, you know, the ability to make that a more natural language query in a way that a lay person can write. I mean, I sort of more know Azure, you know, Kusto, you know, KQL, Kusto

query language, you know, and it's not easy to necessarily get your head around that. You know, it's still got sort of elements of joins and, you know, this idea, you know, and tables and these concepts from SQL and where clauses and that kind of stuff. But if, you know, if, if you can just ask, you know, a very simple thing, you know, what is the, you know, what are the, what are the slowest running things, you know, in, in this that contributes to the performance of this product X and it comes you back and here's a nice graph and a table and a, and a whatever. I just think that the productivity potential is insane. And, like, for people who have been around as long as I have, you know,

we wrote every single line of code from scratch because this idea of open source and code sharing just wasn't a thing. But now open source is used in like 90% of every enterprise product or arguably like 90% of every software product that somebody's building is open source. And, I mean, I wrote a blog post about three or four years ago talking about the value proposition of GitHub is not that it's just a repository where you put your stuff.

It's the trusted repository where you get this open source code from. And you're seeing this now with the way, you know, it's starting to be monetized through Copilot. I mean, yes, there are some, you know, copyright and open source license issues and various other things that still need to be addressed around that. But making it easy is you find, like I'd always argue that somewhere in GitHub there is 80% to 90% of whatever it is that you want to build, it's just really hard for you to find it, you know,

and really hard for you to judge and assess the quality of it. And GitHub's trying to do better, you know, with better security and all that stuff. So I just think that people, I don't believe that people really understand, particularly white-collar people, you know, lawyers, doctors, software professionals, you know, accountants. They don't really understand what's coming to them because we've been immune from this kind of technological-driven disruption of our industries.

It's affected, you know, manual labourers, blue-collar workers, you know, laborers blue collar workers you know stuff like that and then suddenly if you can have a an ai that can summarize a contract uh in two minutes or something tell you right all of this is boilerplate it's fine These are the five clauses in this contract that we think are problematic that, you know, you might want to, and that's what you're going to negotiate. What does that mean for the productivity of a lawyer? You know, what does it mean for the productivity of a radiographer if an AI has already analysed a CAT scan or an X-ray and shown you, I really don't like the look of this,

you know, drill down into this and here's five other X-rays that look the same as this, that were, you know, that this spot was metathelioma or whatever, that this might be a glioblastoma in a brain tumour or something. Like, it just, like, it's really hard for me to articulate what i see coming through the for the productivity it's just going to be insane it's going to be off the charts well especially if you think about you know github if you take that as an example they have they can train their ai on on as you said, like 80, 90% of the code in the world. I'm not sure how much code in the world lives on GitHub, but they can analyze it both, I

guess, public available. And I'm sure with even with their enterprise customers, they can analyze all the code. And if they then connect it with any quality data, then I can ask the AI, hey, write me a code that solves this problem, but I want to have a version, obviously, that doesn't have any bugs in there, or at least take it from there, from sources that we know has less bugs or has no security issues in there. I mean, it's fantastic. I mean, for me, it's just amazing when

you work with JetGPT and just ask it simple things, right? Like I did the other day, I said, you know, I have a CFP for a conference coming up and I gave it a couple of words and then it wrote me a CFP and then I asked it to just make it a little shorter and come up with a good title. And it's amazing. It just did an amazing job, especially for somebody like me, where English is not my first language. It definitely crafts something much better than I can ever come up with. And then think about expanding this from, you know, writing a piece of document to code,

and then having the full repository of code that lives in GitHub right now available as data model. And I think the thing that, you know, it's the general part of chat GPT. I mean, I was talking to my former sales director, and he was saying he was playing around with it. I mean, he's a sales guy. He's been in tech sales for a long time but he's not a techie and he had a um um an rfp you know a you know a proposal to submit back to a uh a tender and so like he fed the customer he fed the you

know he fed some of the questions from the tender into chat GPT and, you know, give me 200 words in response to the tender question, blah. And he said, yeah. Like what it spat back was, do you know what, this was pretty good. It was 80 or 90% of the there and then he just had to tailor it to be specific for our offerings and our context and stuff like that. And that's what's really struck me about the chat GPT sort of phenomenon is the wide range of people

who are using it. There's a YouTuber called Tom Scott and really interesting channel. But he had realised that he was sucking down his Gmail. He thought he was getting his backup, but there's a bug in Gmail backup. So he thought, oh, I'll go to chat GPT, you know, write me a script to, you know, find all of the messages that are tags with this tag and then download the message and all of the other messages

and then blah, blah, blah. And he wrote that in plain text and then the thing gave him the code and then he had to iterate to it like three or four times to refine it because he knew that this particular bug around the way labels are applied in Gmail was there. And then once he then sort of explained that and iterated it again, eventually he got code that worked, you know. And so if you think about that and then you take something like a low-code,

no-code platform like, you know, Microsoft's Power Platform, you bring something that works like that with a low-code platform, particularly like Power Platform that exposes certain data connectors and data models. So in an enterprise context, you can say, you know, you as this user, here are all the data connectors that you have access to, you know, build me a system, you know, I want to do this, this, and this, or I want this data, you know, go and find it for me and bring it together, or I want a form that enables me to input this data so that it's stored in the CRM system or the sales system or the finance, you know, whatever. And it's just going to be able to do it, or it's going to be able to do 90 of the heavy lifting that's

that's crazy it is crazy and fascinating and some people that listen to this now where this is the first time you thought about this scary yeah i think it is scary i think it is you. I think it is, you know, because technological revolutions predominantly have happened to everybody else, and now it's going to be happening to doctors and lawyers and accountants and, you know, and a million other marketing people, you know, the number of people who are generating press releases, you know, with ChatGPT and generating marketing content and generating blog posts and, you know, I think the areas, you know,

there aren't enough coders to go around. So anything that makes a coder 10 times more productive or enables end users to self-serve, you know, we're coming back to this whole key part about platform engineering is self-service that enables users to self-serve. You know, we're coming back to this whole key part about platform engineering is self-service that enables users to self-serve to create these little small applications and proof-of-concept stuff and line-of-business applications. You know, that's just going to be great because there's

so much pent-up demand that these systems are going to, you know, if developers are more productive, if end users can do a lot more stuff themselves with this AI co-pilot, I think we're going to see an explosion in productivity. We're going to see an explosion in creativity because people that have had an idea about some little application that they want to build are now going to be able to get a lot closer to having that application. And I only need, you know, a day of a dev's time to just tidy up the loose ends or something like that. Yeah.

Cool. Well, while I cannot predict the future, I think, though, when we use JetGPT to ask, show me the most common reason for a performance or scalability issue, I guarantee it's going to be the N plus one query issue. Yeah. And I also guarantee that once we start hitting the industries that have the highest pay salaries, that's when we'll start seeing the regulations come in. Oh, yeah. Anyway, I'm going to have to wrap up, guys. This has been great.

Same here. Yeah, same here. Steve, thank you so much. Thanks for having me. Yeah. And years of DevOps and a lot of, I mean, we went all off in different directions. It's been fascinating. Fantastic. Steve, we will add a lot of links that you gave us and names to the summary of the podcast. If there's anything else we should link to the communities that you're involved in or we're involved in, just let us know and we will edit.

Yeah, absolutely. And I would like to, go on, Stephen. I just mean, this is what I've always loved about DevOps and the DevOps community is like every time I sit down with people on a podcast or they talk about DevOps, the conversation goes everywhere. And I think that's the exciting part of it. You know, you learn so much. Sometimes you're talking, sometimes you're just sitting there going, you know,

I went to a conference and got to talk to a lady who was the Dr. Christina Maslach, you know, one of the world, you know, leaders in sort of burnout and what burnout really means for people and individuals and teams and stuff. It was just fascinating. I got up and sitting there, you know, eating my canapé, drinking my wine, just listening to this one. It was fantastic. And yeah, that's why I think this DevOps community is so diverse. It's great. Well, I'll give it the semi-humorous takeaway then. We talked about developing

your teams around what sort of architecture you want to see in there. And that kind of reminded me of how people generally evolve into looking like their dog. So what people should do is get a really good-looking dog so it might help improve you. So I'll take the Conways and reverse Conways and apply it to dog ownership. Anyhow, talking about going all different directions. Really appreciate you coming on today. I wish we had more time to chat, but this has been fantastic. Yeah, thank you so much.

Thank you. Thank you both for having me. It's been great. Awesome. See you next time. All right. Thanks, everybody. Bye.

Bye.