Platforms are all the rage.
But are your teams empowered to get the most out of them? Can they move fast, get things done and make decisions that matter? Or are you in their way?
Often, the point of platforms gets missed, and they become silos of operations and tools, missing the biggest point - the people who use them. In this WTFinar, Sam Newman explores the things that need to be taken into account to create happy and effective experiences for developers and other technical stakeholders who have to live in a working environment created for them.
Sam Newman is an independent consultant, author, and speaker. With over 20 years in the industry, he has worked across different technology stacks and in different domains with companies all over the world. His focus is in helping organisations get software into production more quickly and safely, and helping them navigate the complexities of microservices. He is the author of “Building Microservices” and “Monolith to Microservices”, both from O’Reilly.
(Skip the gossip and jump straight to Sam’s talk).
Jamie Dobson:
Hello and good... What is it? Good, good... What day is it? Thursday. Good Thursday and good afternoon. Of course. Good afternoon to people in the UK and Europe. Good evening to anybody down in from that part of Asia, or Australia. But of course, good morning to people in the US and Canada, because I did hear from a little birdie that we do have people from the US here today. So welcome. I've also got Sam Newman with me. Handsome man. Hello, Sam.
Sam Newman:
Thanks, mate. You're pretty handsome yourself as well.
Jamie Dobson:
How are you doing?
Sam Newman:
We're pretty good looking men, I think.
Jamie Dobson:
I think so. That's what we think. But we'd probably have to do some consumer tests to verify.
Sam Newman:
Yeah. We're not short of a bit of ego, but yeah, we get by.
Jamie Dobson:
How are things with you, Sam? It's been a while, but it's good to have you back.
Sam Newman:
Yeah, it's been good. I was just saying, I did my first sort of in-person conference last week that actually felt like it was a return to the before times. And just coincidentally, I've now got a horrible cold.
Jamie Dobson:
I was about to say, did you get sick?
Sam Newman:
Yeah, I got sick.
Jamie Dobson:
But you did, yeah.
Sam Newman:
It's not COVID, don't worry, and you can't be infected via this, but it's the delights of getting out and hanging out with people, the bumping into people in the hallways, learning loads of new ideas, and then having your head stuffed up with a cold.
Jamie Dobson:
Awesome. I avoided it all until last week when I had a vomiting bug and now I've got a cold this week and I can't cope. I can't cope with being ill. So, on that happy note, luckily you can't catch germs over this... What's this forum? What's it called again? The internet. You can't catch germs on the internet. Only ideas. Only ideas that will fester you in your mind. And they will take over you like a virus. Right. Welcome. If there's anybody new to WTF, very warm welcome to you. So, WTF is a... What are we, Carla? A publication. A publication that produces blogs, eBooks, webinars, and really cool conferences. It's ran by the company that where some of us work, Container Solutions, and it gives us a chance to answer the question, continually answer the question, what the fuck is Cloud Native? And the reason we do that is because nobody really knows, and based on that we often have different topics. Platform engineering, culture we talk about quite a bit, psychological safety. And actually Sam, your talk today is more about platform engineering than anything else. Am I right in saying that?
Sam Newman:
Yeah. And in a way it's partly going to be about my wish that we'd never called it platform engineering in the first place, but I'll get into that in the talk.
Jamie Dobson:
Very good. And this is pertinent to a lot of our customers and potential customers because often, the journey to the cloud, you start with some containers, that's kind of how it goes. You do something with Kubernetes, it goes completely wrong. And before you know it, you've got a platform that's a bit pants and then you've got to start doing it properly. So depending on where our customers are on that journey, platform is extremely important to them. Now before we bring Sam in, and he really is one of the best in the business when it comes to storytelling, there's no doubt about that... Oh, sorry. Oh, my slides have gone crazy. Oh, it's gone completely crazy.
Before we get to Sam, who really is one of the most intelligent and best educators in Cloud Native, in my opinion. I don't say that easy, I don't say that lightly, because it's a space I operate. So anyway, before we get to Sam, a few announcements. So we're starting off with some housekeeping, then some announcements, upcoming events, things you can download. Now, we always do a gossip section. Now, originally we did this gossip as an experiment but everybody really liked it, and that's because during the pandemic people wanted a sense of community, they wanted these webinars to be more chatty and not just some corporate robots sort of speaking at you, right? And so the gossip section was really popular and today I'm going to be joined by two of my colleagues... I think two. Teresa, who's coming?
Tereza Astrop:
Rodrigo is coming.
Jamie Dobson:
Rodrigo is coming to do the gossip with us. Now, Rodrigo's done this before. He was quite effective at delivering the gossip, actually. So I'm looking forward to that. And then of course we're jumping into Sam's talk. So let's start with the housekeeping. We do have a code of conduct that will be shared in the chat box immediately, I would imagine. And it covers the things that you know would expect to see in any good code of conference. The summary is be polite, be nice to each other. But the most important thing is that we do enforce the code of conduct.
So if you misbehave or break any of the rules, you will either be dealt a warning, or potentially if the offence is grave enough, you will be removed from this webinar and you will be banned. And that's because we're trying to create a safe space for everybody, not just that Container Solutions, but across the whole industry. If you should require a code of conduct, you can take ours and do with it what you will. It's pretty good. We've been developing it for a while, so that's that. Now what's the next piece? I always forget the second bit. Teresa, what's the next bit of housekeeping
Tereza Astrop:
Recording?
Jamie Dobson:
Yes, thank you. We're recording this. Yes. If you'd rather your face didn't appear, you can switch your camera off. Although we do like to keep the cameras on because we're trying to create a bit of a real world feel. If you've really got an objection to being recorded, I'm afraid you'll have to leave the webinar now. But don't worry because you can watch it on replay which we will distribute on Twitter, LinkedIn and all the other channels that we use. Teresa, was that it on the housekeeping?
Tereza Astrop:
Mm-hmm. Yeah.
Jamie Dobson:
I'm getting old. Does anybody want to see my new glasses? This is what happens when you go mid-forties. I've taken them off because nobody's used to me wearing them, but actually I can't see anything right now, so I need to put them back on. Oh yeah, announcements right, here we go. You can subscribe to WTF, you can use that QR code or go to the website. We don't spam people. You can opt in. If you're looking for a job, click that thing. If you want some more marketing collateral, click that. If you only want to be updated about free events and free content, click that box. We are not a spammy company. On the very rare occasion, we get it wrong. Let us know and it will be fixed ASAP. WTF is about knowledge transfer and community building. Speaking of which, we have a real life conference coming up. Sam, are you coming to this?
Sam Newman:
I'm checking my calendar now.
Jamie Dobson:
I'll try to get you a free ticket. I know the organisers.
Sam Newman:
Oh right, gratitude, that's quite handy!
Jamie Dobson:
Yeah, right.
Sam Newman:
I'd love this, May 4-5, looks good.
Jamie Dobson:
Yeah. So what the F is SRE? Nobody really knows what the answer that question either, although it's a lot easier to answer than what the F is Cloud Native. This is going to be a great conference. The tickets are reasonably cheap, I believe. So if you've got a job in a big corporation, get them to pay. There are probably some sponsorships remaining. If you want to sponsor what's frankly one of the coolest things we've ever done, go ahead and reach out to Carla, Teresa or myself. And if you want to sign up, follow the links either through this deck or in the chat box which Carla or Teresa will be sharing any second. There is going to be lots of stuff that you could imagine; SRE, bit of culture, et cetera. But there will be a focus on developer experience. Is that correct, Carla? Now, the reason that-
Carla Gaggini:
Yeah, that's very correct. It's one of the new tracks, actually.
Jamie Dobson:
So DevX is one of those thingamabobs that happens to everybody on the transformation. We do a bit of automation, we get our built times down and we do it more regularly and then at some point it's like, hey, how do we create a cool developer experience? That is very, very important to all of us, but it's also very important to many of the people who are moving to the cloud. So DevX will be a massive theme of this. Apparently I'm doing the keynote and I've been dining out on the same ship for about three years, so I promise I'm going to write something new and it's going to be awesome.
Carla Gaggini:
You're being recorded now, Jamie. You said it on the camera.
Sam Newman:
That's a commitment, mate. You've now committed to that.
Jamie Dobson:
It's a commitment to myself. Right, I'm going to do it. I'm definitely going to do something new. We are hiring, of course we're hiring, lots and lots of roles, but we're getting really serious about delivery management. So it's probably something we should have done a while ago. And delivery management is kind of taken care of in a number of different places that consider solutions. We started getting serious about that last year, but now we're building a really serious delivery management capability up. So you can imagine some of that will turn into content later as that team grows. That's going to be an excellent role. So take a look at that if you're interested. And you can get our book, some people said it was good, a fantastic book about Cloud Native DevOps and modern software.
Not bad. I don't know who wrote that, it's probably my mom. But our book is currently free to download. It's really cool. Nearly everybody who is sensible and on a Cloud Native journey reads the book. It's not really a page-turner, it's a textbook. You're supposed to find what problem you've got, look in the book and find the solution. That's how patterns books works. Too many Ss in that sentence, Sam, too many Ss. So that's that. Now without any further ado, then I am now going to bring in Rodrigo and he's going to tell us the gossip and then we're going to get over to Sam and this wonderful talk. Rodrigo, where are you?
Rodrigo Rios:
Okay, can you hear me?
Jamie Dobson:
We can hear you. We can hear you loud and clear.
Rodrigo Rios:
Awesome. So hello there. I'm Rodrigo. I'm a cloud engineer for Container Solutions. Today we have two fresh news. First one is a report, a fresh report from companies Big Enterprise, which is being what is the biggest blocker to DevSecOps. Turns out that security teams and DevOps are not getting on. So this survey reviews that-
Jamie Dobson:
I never did like the security people. I can understand that.
Rodrigo Rios:
Yeah. So 28% of CSOs are not confident that production apps are fully tested. And the reason it's really because security teams do not trust developers. They are always wanting to change in committing features. I identified as 55% of organisations as a top issue. So this data was gathered from Dynatrace who commission a survey to 3,000 DevOps and security professionals in large enterprises. The good nails though is that enterprises are very successful committing frequent deployments, which is really the benefit of DevOps, with 78% updates every 12 hours in average. So, CIOs and CSOs, they're not in general confident that these de deployments are fairly secure, with 55% saying that they're making tradeoffs between quality, security and user experience. And under one third CSOs feels that applications needs to be fully tested for root net abilities before going live.
Jamie Dobson:
So Rodrigo, this was curated by Dynatrace, is that correct?
Rodrigo Rios:
Yes.
Jamie Dobson:
Did they sell something to do with security?
Rodrigo Rios:
I think so.
Sam Newman:
Of course they do, they're Dynatrace. They'll sell anything.
Jamie Dobson:
Do you know what? It's funny, there's nothing new under the sun. My very first big project 20 years ago, 20 years ago, the biggest problem was that the security people and the infrastructure people deployed our software thought we were crap and everything didn't work. And the first thing we did was try to build a bridge which required, can you believe this, going to speak to other people. It was so innovative. We went to speak to them and it was one of my first jobs. So I had a suit on, could you imagine me in a suit? Anyway, after I met the infrastructure people, the suit came off and that was actually one of the first conflicts I resolved in my career and da-da, everything went a bit smooth after that. I don't blame the security people for not quite trusting what comes out of development. It's two very different worlds, isn't it?
Rodrigo Rios:
Yes. That's the good old cultural problem, right? People needs to collaborate more. They just want to conclude. So one of our topics in the role is the AIOps, which is artificial intelligence for IT operations defined by Gartner as combining big data in machine learning to automate IT operations processes. In the same survey, 90% of respondents believe that increase of use of AIOps will be key to improve security, but other 70% do not believe in AIOps. So the human factory remains more important though 94% agree that extending the DevOps SecOps future to more chains and applications is the key to a better software quality without loss of velocity. That can not happen unless those silos between DevOps and security teams are broken down. That's a good old silos and more of confusion problems from DevOps. Yeah, it's still happening in security teams.
Jamie Dobson:
Awesome, Rodrigo. And you've shared the link in the chat box if people want to learn more about that. Now, let's come to the biggest shock of the webinar. People will spend more on cloud in 2023. What's this one all about?
Sam Newman:
Is it sort of like, yeah, every year this is the same case.
Jamie Dobson:
Every year.
Sam Newman:
How is it a shock? It's not a shock, is it?
Jamie Dobson:
This can't be gossip. There has to be more to this gossip. Rodrigo, can you explain this second one?
Rodrigo Rios:
Yeah, sure. I think it's a positive one for cloud, that is cloud adoption is still kicking in. In 2023, companies expect to increase the spending in public cloud application and infrastructure and hyperscalers that have dominated the market, we face new competition. They are now facing new services from different providers. So this multi-cloud approach is more a thing now. IT buyers will continue investing heavily in cloud products and services, but ongoing increase in multi-cloud adoption means vendors must compete on a price in a market with no branding loyalty. Many enterprises consider cloud spending a forego conclusion for a day-to-day operations, but organization should continue seeking better value from cloud purchases according to analysts. Cloud runs the business and the bulk of people are looking to spend more.
Jamie Dobson:
Did you say that the analysis revealed that there isn't brand loyalty, because that's not what we see in our day-to-day. Our customers love one of the clouds and they never want to move.
Rodrigo Rios:
Yeah, it's like if you have this different provider with a better price, people might be turning out to multi-cloud for certain services. That's what I understand.
Jamie Dobson:
I don't know-
Sam Newman:
If you're stuck in a bear trap, do you think fondly towards the bear trap or are you just stuck in a bear trap? So I don't know, it's always loyalty versus I'm kind of stuck.
Jamie Dobson:
Yeah. I'm stuck in a bear trap, it's called being the chief executive of. Right. Very good. Okay, so cloud spending's growing up, that's fantastic. I read something very funny on Twitter yesterday, I love being on Twitter. That's a good thing about working in sales and marketing. You get to do a lot on Twitter. It said, the cloud is the only thing that will change technical debt into actual debt. I thought that was quite funny. Okay Rodrigo, any more on that story?
Rodrigo Rios:
Awesome. Yes, so just to conclude, so also in a risk survey from ESG, about 71% of IT decision-makers to enterprise community market spec to develop and deploy Cloud Native applications in 2023, increase about 11% from 2022. More than half of survey respondents, 59% indicated spending on public cloud applications would increase in 2023. While 56% reported cloud infrastructure services spending would go up this year. And only is now of 3% respectively won't be sticking to one public cloud or either.
Jamie Dobson:
And of course, a lot of this is of course because as people try to cut costs or optimise in difficult financial conditions, cloud is one way to alter the way you pay for things. And when it's done properly, when you have our help, when you have contained solutions help your cloud bills will go down, of course. Okay Rodrigo, thank you very much for that gossip. I thought you did very well today.
Sam Newman:
I'm just going to add one coder to that. If I've been looking at those stats of spend from IDC over year, you see public cloud spend increasing year on year. What you are also seeing increasing year on year is the spend on private cloud. Yes, people are spending more on public cloud, people are still buying their own servers and I really wish they wouldn't, because they don't know what to do with them properly. But that's a different conversation for another day. So yeah, people still think they can do a good as job as AWS and Azure and everyone else does, and they probably can't.
Jamie Dobson:
They probably can't, yes. So that's a message we try to help our customers to digest. Right. On that happy note. Thank you, Rodrigo. If anybody would like to have Rodrigo's job, you can apply for a job at Container Solutions where we 99% of the time mess around with cloud stuff, and between one and 10% of our time, we write, we talk, we go to our own conferences. It's a very happy place to work. So if you're interested in doing one day appearing on What the F is The Gossip, you need to work at Container Solutions, so you better apply for a job now. Right. That's my final plug of the day. It was a bit shameless, that last one actually. I regret saying that.
Sam Newman:
Well, it's also you've advertised specifically not jobs in general, you specifically said if you want Rodriguez's job, the implication being it's a one-in-one-out mechanism.
Jamie Dobson:
No, no, no, no. If you apply for the job, we won't let the... No, no, no, none of that. No, not Rodrigo, the same job that Rodrigo does. Don't worry, Rodrigo, you're fine. Okay, good. On that happy note, then, I am going to now hand over to Sam, so I'm going to stop sharing my screen. I'm going to adjust my chair to the laid back position and get ready for some high-quality cloud entertainment. Are you ready, Sam?
Sam Newman:
Yeah, no pressure, mate. Thanks. Yeah, it's going to be fun, I think.
Jamie Dobson:
No pressure.
Sam Newman:
No pressure. All right, I'll make sure there's a copy of these slides if people want to download them as well. I'm sure you guys can send them around later on via some kind of email or something else. Yeah, so big thank you for having me along. Thank you for Jamie for inviting me along. And I've worked alongside, I mean I work as an independent, but I've worked alongside Container Solutions for years in many different guises, and I can thoroughly recommend them, and I'm not just saying that because they're paying me because they're not actually paying me.
Jamie Dobson:
Oh, that's right.
Sam Newman:
So there's nothing in it for me to say this, other than I might get a pint out of Jamie at some point in the future. But look, this is the year of platform engineering, I think. This is going to be one of the big trends we hear this year, as people realise that Kubernetes is horrific for anyone, any human beings have to interface with directly. We are covering it with layers and layers of stuff and calling it a platform, and it's a big thing. So I thought it'd be nice to talk about at least my view around how we think about platforms, what we use them for. But to come at it from a different angle and to come at it maybe from an angle that was more inspired about different types of thinking and thinking about how nice code bases are to work with. And this has kind of led me towards really trying to bring this property of habitability back to the fore and place it in the context of platform engineering. So if you don't know me, you might know me from some things as microservices.
I do books on the internet, but you can find that out later. Over at my website, there's information about the things that I do. My books are not available for free because I've got a mortgage to pay for. But we are going to be talking today about pitfalls and tips like concrete things. You're thinking about platforms, you're thinking about cloud, you're thinking about microservices. How do we bring all this stuff together and not have it just be expensive but actually have it be useful. And some of you probably know aware of microservices, these lovely architectures, which due to their independently deployable nature enabled increased degrees of organisational autonomy. We can have teams working independently, building software and innovating at scale, reducing the need for release coordination. This is the main reason the enterprise organisations go nuts for microservices. They realize they've got all of these people and they just can't work efficiently and they think microservices are going to solve all of our problems.
We don't have to have meetings anymore. We can kind of just vibe it and get stuff done because let's be real, enterprise companies don't actually have scale problems. They have numbers of people problems and microservices can really help in this world. This is fantastic, we can release our software more frequently, but we all can high five and hang out together. It's going to be a lovely, lovely time. And also this world of microservices makes this possibility for us to own the full lifecycle of our software. You build it, you run it, you ship it. We can do this. Obviously not everyone can do this nor should everybody do this, but it's a possibility. And so then we take cloud and we think, well we've got microservices, we've got cloud. What does that mean? Yes, that's right. We've now got Cloud Native microservices, which should theoretically be the best of both worlds right now talking about what Cloud Native means, we should remember the term Cloud Native predates the Cloud Native computing foundation by some time.
It was just the CNCF as a spinoff of the UX Foundation thought, oh, let's co-opt an existing industry term and devalue it, which is what we've done. People now think Cloud Native equals Kubernetes. No, Cloud Native just means you're building applications for a cloud platform, just means you have to pick a cloud platform. But anyway, I digress. The combination of microservices and Cloud Native to coming together, it should have been wonderful. It should have been this amazing cultural coming together that just delivers way more than the sum of its parts like that, like Ant and Dec or Laurel and Hardy. Unfortunately, it's ended up a bit more for some people this coming together of Cloud Native and microservices business is that is really... It's a bit more sort of Bitcoin and bros, or Musk and Twitter, or Boris and Brexit, something which on the face of it seems like it might be a bad idea, and then turns out to be a really bad idea for a lot of people.
In the case of Boris and Brexit, something that was definitely over marketed and under-delivered to say the least. I won't swear because this is being recorded, but we'll move on. I got in trouble. I was a presentation recently just around the corners from the houses of Parliament and I may have said something with regarding the current Tory party that got me into a bit of trouble. So, oh, I'll move on from this. So why has this ended up becoming such a mess for so many people? Cloud Native, microservices, microservices, Cloud Native, what could possibly go wrong? Well, where to start? So this is the initial problem a lot of us face which trying to make sense of this world and when we think Cloud Native, I'll type Cloud Native into Google. I end up at the CNCF and then I see this. This is the Cloud Native computing foundation landscape.
Now, to be fair, this is a sign of success, of how successful the CNCF has been at bringing together different providers, different vendors to create things which are at least theoretically compatible with one another. But we see this and we are immediately overwhelmed. How do we know? How do they know we're overwhelmed? There's a little helpful comment at the top of this. It says, are you overwhelmed? Well, if you're overwhelmed, you can go and look at this interactive website that tries to help you navigate this crazy and chaotic landscape. And when of course whenever we see this, whenever we see this little comment, what's actually going on in the back of our minds is, well, what are they actually saying is maybe I need to hire some really, really expensive consultants or just get on with my life. They're also quite proud though of how successful this Cloud Native space has been.
There's a new thing that's appeared on the Cloud Native computing foundation's landscape page where they talk about how many different cards there are on that screen. There's over a thousand, I think there's 1024. And they say that they have a... They're very proud. They've got over 3.5 million stars, because we all know what that means. They've got a market, but these companies that are building stuff in the space of Cloud Native have a market cap of over 20 billion... Sorry, $20 trillion. Now obviously there were some big players in here, Cisco's in there, Google, Microsoft, but there's a long tail and those companies are taken on funding of $53 billion. So that's funding that's taken on and that's not going to companies like Microsoft. This is your startups, this is your scale up. This is one of the 27 different service measures that came out last year or the 58 different API gateways that you could use.
And this makes our world quite confusing. Because here we are trying to make sense of this world, and what we are trying to often do is create a sort of curated platform for our people out of this mess. We're trying to... We've got all this stuff going on. We're asking developers to potentially own their full software, build the software, ship the software, deploy it, run it in production, write the theme tune, sing the theme tune. It's a lot of stuff for people to deal with. We've constantly got this mantra of what we've got to shift left. DevSecOps, developers need to do security stuff. It's not necessarily what it means, but that's what we're being told. Shift left, shift left. And then we get books like Team Topologies, which again seems to, on the face of it, expect us as developers to take on more and more burden.
We've got to increase the amount of stuff we are doing. To be fair to Team Topologies, they're at least trying in this book to find a sensible balance in this process in the book. It's an excellent read by the way. You should definitely read it, and I'm sure Matthew or Manuel have been on previous WTFS and if not, I'm sure they will be in the future. In the book they outline the vision for organisations which are optimising themselves around fast flow. So if you are an organisation who is a technology organisation, which wants to organise themselves in such a way that you can shift software quickly and quality software quickly, this is the book for you. They outline a vision for this thing called the stream aligned team, moving away from short lift project-oriented teams towards much more product oriented teams.
Teams that are focused around long-lived delivery of pieces of functionality, owning different parts of your domain. So we've got here different teams that might be associated with different parts of a company. One team focused on stock management, another on the purchase flow, another for promotions. And they own all the software, they own all the assets that are associated with their part of the world, the idea being that they have full ownership. But this means that often we... And the goal of this is actually to remove siloing, to remove handoffs. Rather than having separate dev and tested ops and security teams, we're trying to have these teams do more things for themselves. Because if they're more self-sufficient, if they operate with higher autonomy, they can get more things done and you can get more things done at scale, but then this becomes a problem. There's too much stuff to me for me to deal with and then we say, it's okay, I've got a platform.
And of course as we know, platforms will deliver all promises to everybody, and they never ever go wrong. We want our developers to do more, and the way we deal with this is by throwing more tools at them. Now in the book they talk a lot about this idea of cognitive load, that as individuals there's only so much stuff we can deal with. And look, let's be real, if you were to have a load of stuff to deal with, take microservices and times it by Cloud Native, and then you end up with too much stuff, way too much cognitive load. And sort of both Matthew and Manuel in that book positioned the platform as something whose core job is to reduce cognitive load. Now, many years ago I made the case for not calling it a platform. And the reason for this is, when we talk about a platform we inevitably end up thinking about creating a concrete tool.
We think about delivering software. That's not the job of a platform team. In one of my organisations I've worked previously, we called it developer experience. You're the developer experience team. Your job is to improve the developer experience. That might be through delivering tools, it might be through training, it might be through education. Unfortunately, we've now kind of zeroed in on talking about platform and platform engineering and there's a danger that we see that role purely in terms of my job is to put a layer on Kubernetes when it's about a lot more than that. And that's what we're going to be exploring more in detail later. Matthew puts it quite nicely. He talks about this idea of the platform as the job of the platform is about reducing the cognitive load of the developer, pushing stuff away from them so they can focus on the job at hand.
So if you are in an organisation right now and you've got a platform, this is their job. Their job is not to deliver a Kubernetes cluster. That is a means to an end. And so I started trying to explore other concepts to explain the challenges I felt we were having with the platform. And I came back to a term I'd first heard in the context of sort of code and code basis. And this is concept called habitability. And habitability is actually something that comes from the built environment, but it's a concept I first encounter in talking about source code. And as far as I can work out, the first person that coined this term was Richard Gabriel talking about how nice it was to work with code. And the issue was often that the architects would make design decisions that developers would then have to live with.
And so what Richard was trying to do was to say, look, if you are a decision-maker and you are making decisions about the design or the direction of your system, in turn that has a direct impact into the lived experience of the people working inside that system. Habitability is the characteristic of source code that enables programmers coming to the code late in its life to understand its construction, its intentions and to change it comfortably and confidently. So other people have spoken about it should be a nice place to be. Habitability comes from the built environment. An architect building a building has a duty of care to the people that are going to live and operate into it. If you are making design decisions about a piece of code, you have a duty of care to the people that live inside it. And if you are delivering a platform, you have a duty of care to the people that are going to use it.
Fundamentally, getting this stuff right is about having a very strong and direct connection between the decisions you are making and the people that will have to live with those decisions. And this is it, it starts here, we have a responsibility to create working environments that make our colleagues' lives easier. Now, this term habitability comes from the built environment. It comes from the world of buildings and it comes from the world of architecture. And good architects will think about how a space is going to get used and design buildings accordingly, but they also will make decisions about what to not enforce, if that makes sense. The architect, Mies van der Rohe is brief most famous for popularising what we now think of as the modern skyscraper. He's got an architectural genius that it doesn't necessarily deliver aesthetically pleasing buildings because we tend to just see things in terms of the buildings he create in terms of just giant slabs.
But they were often executed beautifully, but pioneered some really important concepts. Mies van der Rohe realised that by laying down the architecture or something, you were laying down a skeleton that was going to be hard to change later on, but that you have to accept that the people that were going to live and operate in that building may need to change that space. You couldn't necessarily predict the future. The buildings, the modern skyscraper was based around the concept of basically a core of services, a shell... A core of services where you'd have your lift shafts, your water, your plumbing, your electrics with a wall, which was structural but nothing structural in between. This idea of the universal space being that people that could come into that space and reconfigure it based on their needs. The basic building was habitable, but you also recognized that habitability, coming back to Richard Gabriel's definition, was also about our ability to change how we used it.
We couldn't change the core, we couldn't change the lift charts easily. We had to accept that as a constraint in our system, but around that space we could use it as we wanted to. So providing those core services and recognizing that we can not predict how this space can be used. And put it a different way, you can't un-pour concrete. This is a conversation I literally had with the CIO once. It's like, yeah, well we pulled the concrete and now people have to leave the building to get into the bottom floor. This stuff happens, and it happens in our system architecture too. And I see too many people when building platforms that don't have that connection, are all about providing constraints upon what their developers are able to do, often for good intentions, but they have no real skin in the game when it comes to making that experience nice, to making that experience flexible.
They're not thinking about the lived experience of the developer, because ultimately they're hiding behind their Kubernetes cluster. So I want you to have that idea of the back of your mind as we go through a few pitfalls and tips that I see around the use of platforms. And lots of these are built based on my real world experiences, but things to think about when you are developing your own platform and look, ideally, don't call it a platform team, call it developer experience, but if you can't do that, at least pay attention to some of these thoughts that come up next. So many years ago I was visiting a company in the north of England and I sometimes do research visits. It's often how I get information from my books. I went to, this is north of England and they were kind of an interesting company, nice people.
And so I checked to the developers understanding what it was like to work there, what things were working well, what were things that weren't working well. And when speaking to the devs and the dev said, what would you make your lives better? And the developer said to me, well we'd love to actually have access to the public cloud because right now, if you want to provision a test environment or a dev environment, it's quite painful. So it'd be great if we could have access to the public cloud so that we could spin things up as we needed. And so I spoke to the boss and said, hi boss, your developers say they'd love to have the public cloud. Is that something you're interested in using? And the boss said, well actually Sam, we've already got the cloud, we're already using AWS. I'm like, you're already using AWS.
I've heard some developers... You already got AWS. And the developers were confused by this. And so I dove a bit deeper as to what was going on here and I found an interesting workflow, if you can put it this way. So yes indeed, this company was using AWS, and the developers were sort of unaware of this. And the reason was, if the developers wanted to do anything, wanted to provision some infrastructure or whatever it is, they would raise a ticket with a system called Jira. Now, I think the reason people hate Jira has got nothing to do with Jira itself. It's more that people often use Jira to do stupid things. And I think this is a great example. I want to spin up a machine. What's the most effective way for me to do that? To write a ticket. Those tickets would then get picked up by somebody in the operations team.
The person in the operations team would then log into the AWS console, click a few buttons, then copy the details of the machine, put it back in the Jira ticket and send it back to the developer. So this is something you could do, I guess. Although this is obviously kind of missing the point of things like the public cloud, and especially missing the whole kind of reason for AWS existing in the first place. To an extent, it's like having a very expensive sports car and then sticking a wheel clamp on it. Yes, it's cost you a lot of money. No, you're not getting much value out of it at the end. And this is one of the first pitfalls we hit, not really embracing a full culture of self-service, right? The point of a platform should be to empower teams to get things done.
Your job as delivering a platform is to empower people, not constrain people. You want to make your platform self-service by default. And by self-service, I don't mean clicky buttons. By all means have some clicky buttons, but you need an API. When you think about why AWS has being so successful, it was all about supporting self-service. It was that API that they came with. Sure, we can rent machines by the hour, but that API was king. Why don't we allow this? When you really scratch it through why that Jira ticket blocking process was in place at that particular organisation, it was down to one real issue. Do you trust your people? If you don't trust your people, you might start doing things like not allowing for self self-service, not allowing people to provision things on demand. I would say if you don't trust your people, you've got a much bigger problem.
So this is the top tip, maybe start with trusting your people. You might be surprised with what happens. Having conversations back in 2009... Coming back to the story of AWS. So I'll be working with AWS, from the very early days, in a way I say early, I mean I wasn't there on 2006, but 2008, 2009, the company I was working with were doing work actually in conjunction with AWS. And we actually helped develop the first ever training courses with AWS. And part of the reason we did this is because there's some challenges that AWS were having at that time in terms of getting traction. And at the time we spoke to the product owner, me and my colleague Nick Hines, who was the CTO at the time. And the AWS sort of product owner says, we view what we offer as like we're selling electricity.
We are a utility, we just sell electricity. We're not going to tell people how to use it, we just want to provide them the stuff and they work it out. And I think, I'm pretty sure it was Nick who said this at the time, so that's great, that's great. But you know might be selling electricity, but your customers are constantly electrocuting themselves with your stuff. They're using your product and getting it wrong a lot. And you can say, oh, it's up to you how you use it. But at a certain point, they're going to start blaming you. And this is another issue. Having the best technology and cool tools is not enough. You have to make sure people know how to use them. And this is another issue. The people that build the platform, they build the tools and they have a, if they build it, they will come, idea.
And it's like why would they come again? Do they know what it is you've done for them? Do they know how to use it? If you are a person in charge or in part of building that platform team, it's not just about building platform, it's got to be about enablement. Is your team going out and spending time doing outreach? Are you visiting teams and saying, by the way, we've rolled out this cool new feature. Do you want to come and use it? Are you providing training to them so they can come up to speed with some of this new technology you're offering to them? Are you spending any time embedded with the teams that are going to use your platform? So you're getting feedback on all of this. If you're not doing this, you're just another silo, and probably quite an expensive silo. And this leads into my next tip.
You need to view the development of your product, of your platform, like your developing a product. When you think about product development, when you're trying to find market fit for your product, you have an idea, I think this is going to solve some problems. What do you, you go and talk to people, you see the problems they're facing, you pitch the idea, you try it out with some people, you iterate. You have beta test customers and you refine that product based on real world use. You don't come out, spend two years in a cave, you've come up with a big new end-to-end product and go ta-da, and then you don't get to do that and then be surprised where people struggle to use your thing. Develop your internal platform in exactly the same way you would develop a customer-facing product. Talk to people, understand what they want, sell to them, help them understand why you might be able to help them.
And if you can't help them understand why you can help them, maybe you are not helping them, and change what you're doing. This is not a platform, this is confusion, this is chaos. And this is the other problem I sometimes see people making the mistake of is, I want to let people do what they want but I also want to help them do things. And they sometimes fall between pillar and posts and can leave people in a mess where they don't know what to do. You've given me all of AWS, is that right? Is that a good thing to do? Well, it's okay to deliver a curated experience. And I think this is something that a lot of platforms fall into. They think they can be all things to all people. They think we've got to potentially cover all bases.
We need to offer everything. Actually, you don't. Probably 70% of your organisation works in a similar way. Deliver a really nice curated experience for that 70%, their lives become easier. Don't try and solve every problem and don't overwhelm people with a variety of different ways of doing things. We'll come back to this idea of optionality a bit later on, but this is fine. There's a difference between curating and restricting. And what is it? If you decide to curate, but then you say people have to use a platform, now you're restricting people. So we also need to make the platform optional, which is a kind of a controversial point which will cover in the moment. Governance. This is another dangerous word in the space of platform engineering. Now the concept of governance is not a problem. I have no issue with the need to do governance.
It's a bit of a dirty word, but it's a very simple idea. All governance is deciding on how things should be done and making sure they're being done that way. That's a perfectly sensible approach. The challenge is often in terms of how we decide to implement this. And again, when some people, especially enterprise organisations, start seeing the platform being developed, their eyes light up and think, aha, we can implement our entire governance regime through tooling. So this is how things should be done. We make the platform work in that way. But then how does that follow that that's how we implement governance? Well, if the platform only allows you to do the right thing, let's make everybody use a platform. So now you have to use the platform because the platform does the right thing and you have to use the platform because then we know you're doing the right thing... Stop.
Forcing people to use a platform is not about helping, it's not about enabling, it's not about making their lives easier. It's about control. The moment you say you must use the platform, you have to accept your reducing choices and you're restricting people and you're locking people in. And there are other issues when you start saying, you have to use the platform. Gone is any incentive to make the platform nice. If you say you have to use the platform, everybody has to use it. You stop spending time or energy tracking, is it nice, do people like using it? They don't have a choice, they use it or they leave. And that's also a bit of a lie, isn't it? Because even if you say that you have to use the platform, there is this little thing called shadow IT. We've all heard of shadow IT. Oh, spooky. Ooh. Shadow IT, right?
Shadow IT, broadly speaking, is any IT solution not directly provisioned by internal IT, right? We hit constraints. You must use the platform. You make people's lives miserable. What do they do? Well look, let's be clear. When you make people's lives miserable, they're either going to try and find ways to bypass your control to get the job done or they're going to leave. And actually the people that are so committed to getting their job done that they find ways to solve problems despite the controls you put in place, I often think those people should be rewarded. Instead, we tend to demonize them. A lot of problems around governance is it? It's one way. Again, like the platform, we're saying you have to do this, but we're not explaining why. And without explaining why we want things done in a certain way, we make it very difficult for teams to interpret this effectively.
I find it very odd that some enterprise organisations talk about wanting these lovely autonomous self-organising teams and also want to strictly enforce governance through a mandatory platform. Those goals do not align. Now, what we should do when we are creating that curated experience is making it as easy as possible to do the right thing for the people that want to use that nice curated platform experience. Out of the box, it should deliver that paved road you want to get somewhere. Well look, we've delivered this lovely road for you. It's paved road for you. You can get where you're going and while following that road, you'll be okay by us. You'll be doing all the right things and it's going to be... And you know what, we are going to make sure it's a nice experience. It's going to be a beautifully curated path.
They're going to be park benches where you can sit back and relax. You can feed the ducks on your way. But we also accept that sometimes your destination might be a bit different to the one we had in mind and you might need to go off the beaten path and you might need to go through the woods to get your destination and that's okay. But in that situation, you're going to be on your own and we allow that to happen. But then the onus is on you to do the right things. But if you stick to our paved path, we'll do the right things for you. And this seems that this is the model that people don't seem to quite get right. They say it's not a choice, it's a requirement. That's not a paved path, that's a railway. You get on the tracks, you go in that direction. That's all you can do. So providing that paved path metaphor is really your useful.
We're not trying to solve all problems for everybody, necessarily. We're trying to solve the majority of the problems. We're going to give you a nice, really easy to use, curated experience that you can opt into and when you do the right things just happen. But you can also have tools around you which can help around governance and educate people at the same time. A great example of this would be the Bizz Up system that the Financial Times developed. So for any service running inside that organization, there'll be a certain things that your service had to do. It would say, okay, we need health check end points. We need to know what SLAs are and everything else. And as a service owner, you're like, well some of this stuff is done for me by the frameworks or the platform that I'm opting into. But there would also be guidance.
Why is this important? Oh, this is an issue. Click here to find out more. They were using the tools not just to help check what's being done, but also to educate their staff about how to do more. Nowadays, the FT had to build this thing from scratch. Nowadays, of course you can start building your own plugins on top of backstage or something similar. You can explain to people how you want things to work, but educate them at the same time. And that does mean that when they can't use your platform, they can't use that paved road you've laid down. They're going to be able to maybe do the right thing in their own time and in their own spaces. But this idea of making the platform optional is so important. And the problem with this is it's so often so hard to convince people because they've put a massive capital out and operational outlay to building a platform in the first place.
So they want return on that investment and they think the way they get that is by making people use it. And of course the big problem is you spent a huge amount of money upfront. Don't do that. Build a little bit of a platform, find some people that want to use it and if no one wants to use it, you can stop building a bloody platform because it was rubbish, right? Treat it like a product, make it optional. That will encourage you to make sure that you are focused on ease of use. It will also allow for alternative solutions where warranted. In any enterprise organisation, there may be a thousand different ways of deploying software. There might need to be about four or five different ways of doing it when we actually distil it down. There will not be one platform that can solve all problems. And accept that, treat it like a paved road, not a railway track. I want to summarise these things quickly so we can have some fun with some Q&A.
But so just to summarise, here's the pitfalls; not enabling self-service, right? You've got to do this, right? If we come back to the concept of habitability in the built environment, your platform is not a jail. Your platform is a place of work. I come in, I get what I need when I need it. The second issue is not helping people use these tools well. Some of these systems can be complicated by building the platform. Yes, we're trying to offload that cognitive load, but there will also be an education piece. What are you doing to help people use these platforms and experience them and use them properly? And the third pitfall is trying to implement governor's entirely through tool chains. This really leads to ideas like everyone's got to use the platform, not explaining, constraining. Trust your people, treat your platform like a product. Remember it's okay to deliver a curated experience. Provide that paved road that makes the 70% use case as easy as possible to do, but allow people alternatives and make that platform optional.
But if I had to distil it all down into just one piece of knowledge, it would be to really start by trusting your people. So, many of the dysfunctions I see around the platform come from this. And ultimately, not really considering the lived experience of the people that are going to end up using this platform. If you don't care about what their day-to-day lives are like, it's very easy to build awful platforms for them. Remember, when you're making a decision about developing a platform, you are making a huge amount of... This is so much going to be about what they live. They come up, they work eight hours a day for you, five days a week. And they're going to spend so much that time working with this thing. You have the power to make their lives nicer, or not. And I think it starts with trusting your people that they're going to want to do the right thing, but also caring even one iota about the impact you have on them. Anyway, thanks for your time. I think we can leave it there. Have some questions.
Jamie Dobson:
Yay.
Sam Newman:
Thank you, Jamie. Some of that stuff's a bit controversial, but you know.
Jamie Dobson:
I've got the questions, Sam, and I will monitor the chat and I'll just filter out anybody I don't like.
Sam Newman:
No, fair enough.
Jamie Dobson:
Yeah, I won't let them ask. Firstly. So we do a lot of this. I mentioned earlier, we do a lot of platform engineering and often when we are working with new teams, we'll say you have to have a platform, treat it like a product. And then they start to think and then they're like, well, what do you mean? Do we have to go and speak to application teams and do market research on them and find out what their needs are? And I'm like, yes, that's exactly what you need to do. That's a bit... It's easy to say. And most people have read Team Topologies, they've glanced through it, but companies don't really realise what this means. So all the things that matter in product development prioritise backlogs, big epics, saying no. The iPhone, you don't get every feature you want. They design the iPhone, your teams will design your platform. It's a real difficult thing for many customers to get their heads around.
Sam Newman:
That saying no thing is also important. So a big part development is saying no. However, if you're saying everybody has to use the platform, then you have another problem, which is a platform now has to solve all problems, which now means you can't say no. Because you've got to do something because you've got to get everyone on board.
Jamie Dobson:
And the thing about becoming Cloud Native is you become more collaborative. But that in itself is a process. So you build the platform, you say you're going to do it as a product, you say no to a very key stakeholder, who goes absolutely mental, escalates it to the board, and then you get told you will implement that feature. So the world of hierarchy and collaboration, it's not an easy thing to do, this.
Sam Newman:
No, agreed.
Jamie Dobson:
Question, Sam. Here's a good question from... I don't like Gustavo. I'm going to skip that one. Oh no, I better ask it. It's the only sensible one. Okay Gus, are you on the line? You can just read that question out yourself.
Gustavo:
For sure, for sure. Hello everybody.
Jamie Dobson:
What are you doing hiding behind the chat box? Come on in.
Gustavo:
Okay. So I have a question for you, Sam. You did mention that governance shouldn't really be a driver for the platform engineering work, but how can that be actually taken into account then, especially when we're talking about regulated environments?
Sam Newman:
Well, I didn't say it shouldn't be a driver. I think what you shouldn't see is the platform as the only way to implement governance. So I think that, to simplify it down, your platform should make it as easy as possible to do the right thing. What the right thing is going to be determined in part based on your technical strategy, your corporate strategy, but it's also going to depend on the constraints that are placed upon you because of the legislative environment you operate in or the regulated environment you operate in. So it absolutely should be an input into that. So I think that, to distil it down, the platform should make it easy to do the right thing, and governance has a big part in telling you what the right thing is. I think what I was trying to say here though is that you don't want to see the platform as the whole way you are going to achieve that governance regime.
Gustavo:
So basically the platform complies, not really enforces, right?
Sam Newman:
Well, complies in as much as you could do things in the platform to not stop you... You could do things in the platform that would hopefully stop you doing bad things, but yeah, that's kind of see how I see it. And there is this flexibility, you are always going to have bad actors in a system. But ultimately yes, it should make it as easy as possible to do the right thing. That's how I view it.
Gustavo:
Thanks.
Jamie Dobson:
Okay Gus, now before we come to you, Robel, I'm going to come to Richard. Richard, you don't look like a shy man. You can ask your question.
Richard:
Thanks, Jamie. Thanks Sam, for the talk, that's really helpful. You mentioned the constraints of the platform and having a platform will often constrain a team, and that kind of implies that a constraint is always a bad thing. But I've often seen constraints as actually being a way to help a team focus on a particular problem. Can you talk around that a little bit more?
Sam Newman:
Yeah, absolutely. So I've been a consultant many, many years, worked at a big consultancy and you'd always chat to the devs, and I'd be one of them and we'd say, oh, we went to his client and we had to use Java6, and I might as well just kill myself now. Why couldn't I use Scala? Well, because it's terrible, but you know what I mean. We'd want to have no constraints. And some of the worst disasters of projects I saw were a dev team rocked up and there were no technical constraints. And then what did they do? They spent about six months spinning their wheels, arguing over which programming language to use. I absolutely have no problem with constraints. I think the question is where do the constraints come from? So I think if the constraint comes from a technical vision, we are going to build a system in a certain way for these reasons. And we are applying constraints upon that. A constraint can be something like we will be deploying on AWS.
That's a completely legitimate constraint. Another constraint might be, we are on the cloud but we are operating in an environment where we might not be able to operate in the public cloud anymore. So we've made a decision to only work on Kubernetes as a platform. I think having constraints like that which are tied into part of your technical and business strategy absolutely makes perfect sense. I think it also makes perfect sense, obviously if you are operating in a regulated environment, you are dealing with healthcare data, you're dealing with personally identifiable information. Being very clear though, I think when you communicate a constraint, you need to kind of explain what it is and why it's there. And there are sometimes those constraints that have been placed upon you because of previous decisions that no longer are valid, so I think it's okay to challenge them. But absolutely you do need some constraints placed upon you. But again, it's down to do you explain what they are and why they're there. But as developers, we need those.
Richard:
So to be clear in them, communicate them, explain them.
Sam Newman:
Yes.
Richard:
Try and keep lean on your constraints.
Sam Newman:
And to keep you a classic example of another type of constraint that some people find sort of odd is a way, so one of the proposed benefits of microservices, for example, is that anybody can use any programming language they want. James Lewis has a great line. He says, "Microservices buy you options." A microservice architecture gives us loads of options in how we solve problems. The important word is buy, right? Yes. If you want to, you could give people free rein over what programming language they pick. Is that something you actually want to do? You see organisations like say Netflix or One Level, or Monzo here in the UK, who have said, we are going to standardise on using the go programming language everywhere. And the reason we do this is because we want to make it easy for people to rotate between Teams and we want to be able to use shared code and shared tooling, and it allows them to operate at scale. So they've placed a sort of technical constraint on their developers, but they've explained why. And I think that's absolutely fine as well.
Jamie Dobson:
It's funny, Sam, because I never thought... I once read an interview with the boxer, Joe Calzaghe, I think it was. And he said, "I never thought I'd become an amateur runner," but to be a good boxer you need to be very fit, so you end up running. My whole life is now designing constraints. Because everybody says they want autonomous, but it's a joke. They don't really, because when you give it to them, they're like, ah, panic, what the fuck? Constraints, that's all you do. That's all you do as managers and that's all you do in Cloud Native transformations. You're designing work and constraining so that people follow a sensible path.
Sam Newman:
I'll give you one other classic example of this, which works at a different level, would be Jeff Bezos. So very early days at Amazon, the way he wanted the company to grow was basically through these sort of fairly autonomous product oriented teams, because he recognized that that was the way that he was going to out-compete. And so he actually applied some technical constraints. He said all communication between service interfaces, you can't talk to people's databases directly, because he realised he wanted those teams to not be too tightly coupled to each other because he wanted the organisation to grow in a certain way. And there are some downsides to that model. Why there's nine different ways to run a container on AWS, I'm not entirely sure, but that's sort of an outcome of having that degree of independence. But it's at least rooted in a vision for the company and a vision for how the leadership of that company thinks that company should grow. And I think that's totally fine.
Jamie Dobson:
Now Sam, we've got another question. So Robel, I'm going to bring you in now. Please, shoot.
Robel:
Yeah, thanks Sam. That was a really good presentation. I just wanted to ask about, when you say that about your client, I remember how the developers have difficulty in adopting the cloud or didn't even know about the cloud because of the whole provisioning system through Jira. Nexus said that it should be self-service, which a hundred percent I agree, API-driven self-service. But you talked about trust. Now, absolutely there should be a culture of trust, but is that really a blocker? Because you could still have policies, guardrails in the system, automation in the system so that, let's say, you don't have to trust your developers, but your system will enable that they would be doing the right way. I guess similarly when they get into the final destination, sure, they don't need to use your platform. As soon as they can tick all your policies, they can meet the criteria then they can get there. So, what do you think about policies and automation?
Sam Newman:
Well, so I think... There's a couple things that I say. Firstly, the trust thing, there's always the other bit that when you trust people, when you give people autonomy, there should be trust and verify. So there should be some verification going on. So there's that to say. There's also to say that even as you've mentioned within, say, giving people API access to the cloud, there's things you can do to limit the impact of mistakes that are made. And a lot of those are just sensible things you do from a security standpoint anyway, placing limits on how many resources you can spin up, limiting what data you have access to, these are just common sense things you do, which often are not about the individual.
They're often just sensible principle of least privileged type security measures that you are going to put into place. Coming back to the idea of being on the platform or off the platform, if you clearly articulate what you want to do and why you want it done that way, and then you say this platform or this set of tools does this for you. And then you say, but if you don't want to use it, you still need to do these things, then the ownership falls back onto the person making a decision not to use the platform. So I saw this both at Google and at SoundCloud, right? So Google, if you use one of the blessed languages time there like four different languages, right? If you used JavaScript, Java C++ or Python, those languages were really well supported. The run times would work as expected.
There would not be a single question or quibble and an awful lot of boxes would automatically get ticked. The moment you decided to go and say, I'm going to write something in Haskell, well there's now a lot more hoops you've got to jump through and then you would have to justify going off piece. But if it was justifiable, they had no problem with it. So I think it's, it just shifts the onus. I saw the same thing happened at SoundCloud. They have early on had a large number of different programming languages and started to see a lot of duplication of effort. And so they then said, well look, if you build your services on the JVM, predominantly that organisation, it meant Closure or Scala. Obviously the Closure program are better. If you use one of those two programming languages out of the box, all of these boxes would get ticked.
Now, if you wanted to write a service in Linda, you could, but you were going to have to as boxes and in SoundCloud you would have to justify that decision to your product owner. In practice, what happened is very quickly those weird esoteric languages fell away because people realised they had to ship features and they could ship features much more effectively on the platform. But there were places where you had a choice where you could do other things. But again, it starts with that, here's what we want you to do, here's why. By the way, here's lovely paved path. If you want to go bush bashing, as we'd say in Australia, hack your way through the jungle, that's absolutely fine. But are the one that's going to be hacking through the bush. I think that's absolutely fine. Who's next, Jamie?
Jamie Dobson:
There is nobody with their hand up. Does anybody have any more questions? We did get a couple of questions on the... We ask in advance, Sam, if anybody wants to ask questions. Here's a good one. How do we move government IT away from trying to solve a problem from buying more tools?
Sam Newman:
Which government? I mean that semi-seriously because some governments are better than others, having worked with some of them. I think the... Look, I'll [inaudible 01:05:50] to you, so if I'm going and doing... I've done lots of work with Norwegian government agencies, right? They're really easy to work with. They seem pretty common sense... They're very sensible, they have a degree of flexibility. Some governments are still mired in so much bureaucracy that the only people that can ever do work with them are massive companies and all they've got to sell are huge numbers of professional services and tools, unfortunately. I'm deeply depressed that a lot of the stuff that GDS was doing here in the UK has been dismantled and watered down. It's one of the only things that the Tories sort of did right was the work done at the GDS.
So I think it depends an awful lot on what government you're talking about. The Estonian government do some amazing stuff in this space, right? Norwegian government's doing pretty well as well. But I mean we're still better than the US, but that ain't saying a lot here in the UK. I think the problem is often, historically with the government sector, has been the idea of buying tools and outsourcing is because the government hasn't traditionally felt that they were in the software business. They didn't have their own techies internally. They didn't have their own expertise in-house. And the UK government, for example, the people that made decisions about whether or not about whether work should be outsourced and who the work should be outsourced to, were in turn people that worked at outsourcing companies. So, that has changed a bit in the UK, but it's a long, long road.
Jamie Dobson:
Yeah, I think the UK government's doing some decent stuff, but it will be a long road. Now, I think we're going to take one more question, Sam, and then we're going to let everybody disperse and go forth and be happy. Richard, back to you.
Richard:
Yeah, sorry for hogging the questions. Sam, when you put this together, when you compose the talks, what kind of size company do you have in mind? Does the advice shift for different sizes? You talked a lot about big companies and government and so on. So, what's it like at the other end of the scale? Does it change?
Sam Newman:
Well, with the smallest company, I normally just say, just you probably want to be a little bit more constraint-oriented. So if I'm working with a two or three person startup, I say don't use microservices. You can't afford me anyway. So give me equity. I mean I'm not... I have a mortgage to pay for. But I'm not going to worry about, you're not doing a platform for three people. I'm just going to say go into a public cloud platform and just use LaMDA and you'll be fine. I think you can be a lot more... And also with the smaller companies, an awful lot of these collaboration problems and the silos, it's very difficult for them to exist because you are small. Those barriers get broken down. So this is more, almost by definition, this particular talk is pitched to any organisation big enough to justify building a platform.
And that doesn't tend to be a small five or 10-person company. Look, if you're a five-person company, you don't want microservices. You almost certainly don't want Kubernetes. I mean god, can you imagine? You've got other things to get on with. It's only when we get to that level of scale. And I think as well that what I do is different versions is for different companies. I'll chat to them beforehand, some will have different governance policies. So the people who are building platforms, it's really the very medium to large sides at the end of the spectrum here. But I do see a lot of enterprises who are very top down-centric, who are sort of a bit scared of this idea of teams and developers with autonomy are sort of seeing the platform as their way of resting back control. And it's like that's not... You've really missed the point. You've totally missed the point.
Jamie Dobson:
On that wonderful note... Before we say thank you to Sam, I've got one more request. You probably remember Lord Kitchener or a very famous poster of Lord Kitchener saying, and what did he say?
Sam Newman:
It's about, say Jamie, are you that old, that you remember Kitchener?
Jamie Dobson:
I'm not that old. You remember that? What did he say? Your country needs you, I want you. What was that poster?
Sam Newman:
Yeah, something like that. Yeah.
Jamie Dobson:
Right. WTF needs you, its loyal regulars. I recognize a lot of faces today. It's great that people keep coming back. But we want to get our numbers continually climbing up, up, up. So my only request is, if you enjoy this stuff, please share it. Please bring your friends and bring your colleagues from the companies you work at. And please consider coming to the conference in London. Now obviously if you have to travel, don't do it. But you know, we're trying to keep the momentum going and we work really, really hard at it. So that's my request for you. I think we all love coming together, but communities require all of us to sort of chip it. And that's something we're trying to stimulate.
And, if anybody's got any talks they want to give or any information, anything whatsoever, please reach out. Everybody's a little bit done with webinars right now, which is understandable. So we're trying to get back to the pub, back to meeting in real life. So thank you for all your support so far, and thank you for your continuing support in 2023. I think I'm speaking for me, Carla and Teresa when I say that. And on that note, let's just, speaking of Carla and Teresa, let's first give it up for both of them for organising this webinar. Bravo. A big round of applause for Rodrigo for coming in and doing the gossip. Bravo. A huge round of applause for me, for facilitating.
Sam Newman:
Boo. Oh, sorry.
Jamie Dobson:
But the biggest round of applause for Sam for coming in and, once again, absolutely smashing that talk. Thank you, Sam, so very much.
Sam Newman:
And thank you for the lovely questions as well and the awesome facilitation. I'm happy... I love doing these things. They're always very enjoyable for me. I get asking these things a lot. So yeah, come to the other ones and tell your friends.
Jamie Dobson:
Awesome. Right. And on that note, happy Thursday everybody. It's nearly Friday. We're almost there. We'll see you next time. Bye.
Sam Newman:
Bye, everybody.
Carla Gaggini:
Bye.
Rodrigo Rios:
Bye.
Tereza Astrop:
Bye.