GOTO - The Brightest Minds in Tech

When To Use Microservices (And When Not!) • Sam Newman & Martin Fowler

• Sam Newman, Martin Fowler & GOTO • Season 1 • Episode 3

Share episode

This interview was recorded for the GOTO Book Club.
http://gotopia.tech/bookclub

Sam Newman - Author of "Monolith to Microservices"
Martin Fowler - Chief Scientist at ThoughtWorks

DESCRIPTION
Upgrade your microservices knowledge by listening to a spirited conversation between two living legends: Sam Newman and Martin Fowler. The two touch upon the main reasons for using or not using microservices, and, if you decide to do use microservices, what else you should change along the way to fully benefit from the switch, plus much more.
The interview is based on Sam Newman's new book "Monolith to Microservices": https://amzn.to/2Nml96E

Read the full transcription of the interview here:
https://gotopia.tech/bookclub/episodes/moving-to-microservices-with-sam-newman-and-martin-fowler

RECOMMENDED BOOK
Sam Newman • Monolith to Microservices • https://amzn.to/2Nml96E

https://twitter.com/GOTOcon
https://www.linkedin.com/company/goto-
https://www.facebook.com/GOTOConferences

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at https://gotopia.tech

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.
https://www.youtube.com/GotoConferences

Bluesky
Twitter
Instagram
LinkedIn
Facebook

CHANNEL MEMBERSHIP BONUS
Join this channel to get early access to videos & other perks:
https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/join

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket: gotopia.tech

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Why a new book about microservices?

Sam Newman: So, the reason I wrote that book was quite straightforward. I wrote a book called "Building Microservices" back in 2014, and it was released in 2015, and time's moved on so I thought I should review and update that book and write a second edition of this book to encompass all the new changes that have come about. I sat down to work on the second edition of "Building Microservices," and I thought I'd pick the hardest chapter to work on first. I picked the chapter that was all about how you break things apart, how you take a big monolithic application, and how you break it down into smaller individual services. I knew that chapter would be really tricky to write, so I'd start there, and that way, get a better estimate of how long my whole process for writing this second edition was going to take.

I started that process, and two months later, I was still working on that chapter. The chapter of that book had gone from being 5,000 words to being 25,000 words. So, a chapter about how you make big things smaller had itself gone very big. I was then stuck with this problem, which was, "What am I gonna do with this content?" I sort of realized that I was quite enjoying writing and exploring that deeper side of it, that monolithic decompositional side of things, and thought, "Well, actually this could work really well as a standalone book." That's when I went back to the publisher and said, "Look, I know I said I'd do the second edition and I will do the second edition, but I've gone off on a kind of a different trouser leg of possibility, and this could actually work really well as a standalone title."

I sort of stumbled into it (en- editor’s note- the subject of the book) accidentally. It's Sam’s way. When I wrote the first book, I didn't sit down to write a microservices book. I sat down to write a book about how you architect for continuous delivery and ended up writing a microservices book. So I sort of let the content follow...almost let the content guide me initially. And then once I had a sense this was gonna be its own book, then I had to pause and I had to kind of reshape the content and think about the structure a little bit. This time along, I'm going through the second issue at the moment, and I've just hit another point like that with the second issue. I'm looking at the whole area of microservice collaboration, and I've been very thoughtful myself this time to put a very big pin in that. I placed all the content that I'm not sure about off to a different document in a different Git repo. So, I’ve got the second edition to finish, and then I'll go back to that content if I want. So, yes, I got diverted along the way, but it was sort of a happy diversion.

When to use microservices

Martin Fowler: I often imagine that when people think of advocates of microservices, they think of these people who are determined to use microservices in every situation. "There's a 1,000-line program here. We've got to break it down into 10 100-line programs." And yet as I know too well, I've actually only ever heard you complain of people not using microservices when they shouldn’t have done. I don't think I've ever heard you complain of the opposite. So, maybe you should talk about when people should actually even consider using microservices because I don't think I've actually ever heard you state that argument.

Sam Newman: Oh, okay. So, if you want one quick answer for when you should use microservices, it's when you've got a really good reason. I know that sounds like a trite answer. Of course, we wouldn't use them for a bad reason.

Martin Fowler: Please.

Sam Newman: But I guess what I mean by that is, there's a danger in our industry that we often focus on the activity, not the outcome. We focus on the tech tool, not the thing the tech tool lets us do. And so, for me, a microservice architecture is a conscious choice you have made to kind of implement something in that style because of some outcome you're looking for. There's some benefit you think a microservice architecture is going to give you. So, my qualifying criteria is going to be, "What is the thing you think it's going to give you?"

I could talk about the things that microservice architectures can give a lot. It gives you more options around how to scale up applications. It gives you this lovely property of independent deployability. When implemented correctly, it can really help isolate the surface area of failure, what some people call kind of limiting the blast radius, which can help make applications more robust. I mean, ultimately, you could argue that this is a James Lewis quote, "Microservice architectures buy you options, and fundamentally, when you buy into microservice architecture, you're buying into a whole other series of options and choices that you can make." I think in James' quote the "buys you options" is quite deliberate though, right? Options, great. We all have options, but "buy" implies a cost and they do have a cost.

Don't use microservices as a default option?

Martin Fowler: It's almost like you're saying that your default option should be not to use a microservice, right? Unless you have a really good reason, go with the monolith.

Sam Newman: Yes, I would say that absolutely. I would also caveat this by saying and trying to be really clear about this idea that microservices aren't like an on-off switch. People think that they are like that often because we don't have time to engage with the topic more fully, we like to sort of very clearly delineate things and say, "This is this thing, and this is that thing." We say: "Microservice architectures are distributed systems, and distributed systems are hard." The phrase "distributed systems are hard" is true. In a single process, monolithic architecture is not distributed. Well, actually it is, right? So, if you think about a normal single process monolithic application, if you're reading data from a database on a separate computer, that is a distributed system. If you're putting data from that process into a browser, that is a distributed system. It's just a really simple one. So, you know, you're gonna not even see a large amount of the differences.

My default is absolutely to look at a really simple deployment topology, a single process monolith albeit I might break down into modules within that kind of process boundary. And then if I think a service-based architecture could be a good approach, I'm gonna look to maybe just try out one of them, make my system a little bit more distributed. Just a little touch, like telling that little dial and just see what that does. Can I deal with it? Do I side-step these issues of, you know, horribleness that come from distributed systems? And do I get some benefits out of it? So, I think, yes, absolutely. My default is a single process, monolithic application, simple deployment topology, you side-step lots of issues. But if I'm interested in trying something new, we shouldn't view it as being a massive undertaking to try something else out. That's often a problem that a lot of organizations say, "Right. You know, we think we might do microservices. Let's spend six months building a platform for microservices." It's like, "No, no, no. Just try one and see what happens."

Top 3 reasons to introduce microservices

Martin Fowler: So, you need a reason to push for microservices. What would be your top three reasons that you think are valid reasons that people should be thinking of going down that path?

Sam Newman: Yes. Number one is independent replayability and specifically, I would say taken to the extreme would be zero downtime independent deployability. So, the ability to make a change to a piece of functionality, deploy that functionality, and do so in a way that the rest of the system doesn't need to change, so that limits the scope of each release, but also implement that deployment in such a way that I get zero downtime deployment. So, that's really useful if you think about, you know, a SAS based business where you can't afford downtime, and that's really, really key. So, I think that's kind of the big clear winner.

The second area that's come up a few times with my clients recently has been the isolation of data and isolation of processing around that data. Some of my clients have been operating in, say, healthcare industries. A lot of my clients have to be concerned about things like the GDPR and implementing it, "Well, how do I know where my customer data is? How do I implement things like the right to be forgotten?" Because with a microservice, you isolate the data and the processing that acts on that data. You can kind of clearly delineate these services, touch personally identifiable information, and therefore might require more oversight, a high degree of governance, and may be audited. And these ones never touched this stuff and don't even talk to the services that touch this stuff, and therefore, we could kind of separate them out. And so, I think that the data partitioning side of things I think is really kind of key.

The third reason...I suppose you could maybe argue that this is a facet of independent deployability. The third reason is really where you're looking to enable a higher degree of organizational autonomy. You're looking to push and distribute responsibility into teams, you want those teams to be able to make decisions, roll out software, and reduce the amount of coordination those teams need with other parts of your organization. So I'd say sort of independent deployability, I'd say data partitioning, and I would say sort of organizational autonomy. And there are other things like technology and different scaling models as well, but those would be the top three things that I kind of see as reasons most often.

How to avoid a distributed monolith

Martin Fowler: I'm looking through this independent deployability again. This brings us to a problematic setup that we see a fair bit, which is a distributed monolith, right? Just where you've got a system that's called microservices, but in order to deploy this service, I have to ensure I deploy this service and I've got to update the versions of these services. That's a trap that people can easily get into when they don't pay enough attention to independent deployability. But how do you avoid that trap? What lessons can you share so that people know how to avoid it?

Sam Newman: The first thing, which is to say, "Well, if you have an architecture which theoretically allows you to deploy your microservices independently, then actually, don't make that theoretical thing you do. Make it an actual thing you do." I've spoken to a surprising number of people who said, "Well, we did use to be able to deploy these services independently, but we decided to just bundle it up because it was "easier," and many months and years passed when you suddenly realized you could never go back to the old way of working because you've almost indoctrinated into your developing processes the idea that all these things get deployed together. So, if you have a theoretical ability to do it, you’ve got to make it an actual deployment mechanism. That's what you do. So, that's the first thing.

The second thing would be to start looking for patterns if you are finding it difficult to change microservices and isolation. So, do you see a collection of microservices often being changed together? One thing that could be quite useful is, if you are making use of a ticket tracking tool like JIRA, actually to make use of the ability to tie a commit back to a piece of work. Every month, look back at all the stories you completed and look at the commits, and then you can map those commits to which services those stories impacted. Are you seeing areas where you notice, "Well, these two or three services always seem to change together, these five or six services always seem to change together?" That can sometimes be a sign that you might want to merge those things back together again, or perhaps to look at different ways of sort of slicing and dicing those services in different ways. Those are kind of the two very quick things I'd be thinking about, is looking for those patterns.

I mean, really the technological idea or the design principle underlying independent deployability that I think is the most important is this idea of information hiding. So many things flow from that. When you're creating a market service, if you hide as much information inside that service boundary as possible, you're going to reduce the effect of the interface that your microservice has with the rest of the world. With a smaller interface to the rest of the world, it's much easier to make sure that any changes you make inside that service boundary don't change that interface. So, if I could make an internal change to a microservice without changing the interfaces that I expose, I can get my independent deployability done. I think the challenge is often that people don't know what information hiding really means.

We have a lot of technology available to us that makes it quite easy to violate this concept of information hiding. We have lots of help and aids to us in our code base to help us violate encapsulation, which, after all, is just an implementation of information hiding.

Why strive for independent deployment

Martin Fowler: That's talking about the sort of, "How do we avoid the distributed monolith?" And, again, it comes down to this question of independent deployability. But that makes me also want to go back and say, "Well, why is independent deployability such a big deal in the first place?" There are organizations that have big monoliths, and have had those, and are able to employ them at regular intervals. They have continuous delivery pipelines, they're able to take people's commits on a daily basis, redeploy the monolith. It is great to deploy a monolith when you have everything automated and set up. You can just roll it. So, why should we care about independently deploying a bit if we've got the necessary CD pipelines and we can just deploy our monolith?

Sam Newman: So, there are absolutely some great examples of organizations that have monolithic applications and the ability to deploy software frequently. Two examples of a monolith are Flickr and then Etsy, who were sort of monolithic PHP-based applications that had a really slick deployment model, and they weren't deploying once a day. They were deploying multiple times per day for developers working all over the world. They invested a lot in making a pipeline that would work for them in that environment. So, it's absolutely possible. But then the issue is it's easier with microservices to limit the impact of each release. So if I think about deployment, what I want to do is create an environment in which you feel safe in making a change. When I make a change, I feel safe.

One of the ways you can make a change and feel safe is by reducing the impact and the risk of each release. If I'm deploying an entire monolithic system, then I'm increasing the number of things that are potentially changing in my deployments, and therefore, there are more things that could potentially go wrong. With a microservice architecture, if I'm just deploying a single service, I can reduce the scope of that individual deployment, and I can manage that deployment more effectively and more efficiently. If you've also embraced ideas like zero-downtime deployments, you're also going to be doing that in such a way that your system isn't really going to be impacted. When you've got a single process monolithic application and you're trying to do things like zero-downtime deployments, there are quite a lot of limitations in terms of how you can do that, and there are also types of deployments that are very difficult to do in that environment.

I talked to John Allspaw, who was the release manager at Flickr and then at Etsy and went on to become Etsy CTO, about how you do things like database changes, for example. He would say, "Well, we can do these fast frequent deployments, but if we ever had to do the database migration, those sorts of things would still have to be done during the weekend, in sort of quiet times because of the larger impact on the system." But if I'm doing a change like that on a smaller individual microservice, it's much easier with the data. The volume of data is likely to be lower and therefore the impact and the time is taken for that migration to run might be lower, and therefore, the impact on the system will be lower. I'm not saying it's not impossible to do it with a monolithic application. Just, in my experience, it's much harder to do with a monolithic application to make those things...to get to a pipeline where you can make those changes in a quick, and effective, and efficient manner.

The other overlay here, I think to an extent, is organizational scale. So, for me, if I've got one team working on the system, you can afford within a single team to have a high degree of coordination, really fine-grained communication. You're working on things together. It's easier for you to reason about the changes you're making when you deploy something, be it a monolith or a microservice architecture. When you start getting into the world where you've got 5, 6, 10, 15, 20 different teams and they're all trying to work on the monolithic application, and then you want to deploy that monolithic application, you have a whole host of coordination required between those different teams in order to make a change happen. Certainly, you know, Flickr and Etsy never had development teams that are that big. So, obviously, you can do things like breaking services down around modules, but modules don't necessarily allow for hot deployment at least on most of the runtimes that we look at. So, there is also a scale element in there as well.

Organizations and teams

Martin Fowler: I must admit, I find those latter two arguments much more convincing than the general, "Hey, it's easier to deploy one thing," because the problem with the, "Hey, it's easier to deploy one thing" argument is, "Well, yes, you're deploying only one thing, but you've got a distributed system. There is nothing less complicated than a distributed system." So, yes, I only have to redeploy one part of it, but it's still got to connect to everything else. And yes, if you're really good, you can reduce the risks involved in doing that. But, I mean, that's part of the argument, right? It's hard to be really good. I'm not convinced that makes the bigger monolith a harder thing to deploy because you can much more effectively test the whole thing if it's a single monolith before it goes live. But the other two arguments about data, and particularly about the organization, I find much more convincing. As you say, data always takes time when you’ve got to do migrations. It's harder to contain within a single application because it's just easy to say, "Just get the data all the time."

Sam Newman: Yes.

Martin Fowler: And organizationally, that is certainly when I talk about microservices to people, that's the area that I tend to focus on more. That as team size increases, then it's harder to coordinate people. I believe it gets exponentially harder to coordinate people as team size increases. So, you need to set up barriers, and microservices kind of force you into an awkward way of working, which is actually kind of what you need with a bigger team anyway.

Sam Newman: Those barriers should be modules inside a monolithic application. I mean, setting aside the fact that most of us don't work in runtimes that allow for hot deployment of modules. I mean, that was the whole concept of structured programming, to a large extent, which was, "How do we take larger programs, break them apart into pieces that can be worked on in isolation to reduce that kind of coordination effort?" I find quite interesting that for a while, Eric Brooks, who wrote "The Mythical Man-Month," disagreed with Parnas' whole information hiding theory. And I think he wrote this in the foreword of the 20th edition of "The Mythical Man-Month," basically apologized, said, "I got it wrong. Information hiding is how you break apart work."

I think the conversation I remember I was having when you were helping with the "Building Microservices" was that modules within a monolithic system should work better than they do, but we find all sorts of ways to violate those modules. They're often not a first-class consideration, or application, or tooling, and the concepts of modules. Certainly, things like Java historically have been quite weak, but we violate them the whole time. But once you make that a service or process boundary, violating those things becomes really painful, and so it's something about making something you shouldn't be doing difficult. And so, I think there is something about the very fact that you've made this now separate process boundary. It means you may be slowed down, you're thinking about what this boundary should be, and make it harder for you to sort of just do arbitrary, silly things with them. You know, that, for me, is not great. I think it's true, but I'm disappointed that it's true in a way. We shouldn't need to make things difficult to make us do the right thing, but that just seems to be what life is.

Martin Fowler: Yes. It's kind of sad that programming language infrastructure has really not done a very good job at modularity. I think the class idea was kind of cool and gave us some handy tools, but it's too fine-grained. As a result, we ended up with nothing. None of the languages are really giving you much above the class level to really control modularity in any kind of sensible way. Without those tools, the best you can do is kind of set yourself up. I have come across teams that have done some good things of interrogating the code base in order to try and spot modularization failures and try and lead people in a better direction, but it's all stuff that people got to put on top of the language, and the languages are just not giving us the help. It's too easy to get around the language barriers when they're so minimal and then break it.

Handling data

Martin Fowler: I guess in the way I look at it, often that breakage most likely happens with data handling, as you say, with the information hiding section. Which then leads into the interesting question, that if we're looking at breaking apart or wanting to think about breaking apart a monolith into microservices, certainly one of the areas that strike me is one of the key hard parts of doing this comes around the handling of data. So, what are some of the observations you've made about how we can handle data better to look at that breaking apart a larger monolith into microservice-style thinking?

Sam Newman: Yes. So, let's start with the obvious thing. Data is hard. That's the first thing. And breaking data apart, which is in a relational database is also quite hard because of the fundamental nature of a relational database. A relational database is about relationships and turns out some of those relationships are going to end up being broken. There are some interesting benefits that actually come from working with a relational database, though, which is often that the relationships between data are sometimes significantly more obvious than the relationships between code. It's amazing how many codebases I work on where I find that the schema does a better job of communicating intent and understanding of the domain than the code does. That's often because somebody spent a lot of time thinking about a schema upfront. They never changed it afterward or in such a way, but it's almost like there's the granularity. You can start seeing things in there. You start seeing the shape of stuff emerging.

One of the earliest things I'll often do in these situations is just loading up the schema into a sort of a graphical tool and start playing around with it, just looking at the shape of it, the structure of it. Are there parts of this that seem more tightly aligned than others?
We think about a foreign key relationship in a relational database as being all about, "This is about referential integrity." And yes it is, but it's also about making the relationship between things really explicit. In fact, a lot of people don't know, but in relational databases, you can put foreign key relationships on it without enforcing referential integrity, not that anyone ever bothers.

I also realized that a lot of the complexity and breaking apart systems was going to be in the database. So I keep going backward and forwards on this. If I'm going to pull out a piece of functionality and extract the data out for awarding loyalty points for an order, for example. I thought "Well, if the database is often the most difficult part, then maybe you should tackle that earlier and make sure it's even possible to extract that part of your data model out from the system, and then you could do all the work to diligently separate out the database, and then the code would be easy by comparison."

The reality is that most people don't want to do that. Most people want to get some benefit from having these new points awarding functionality extract into a microservice first. And so, the model I see more often is that people extract the code and then they'll look to extract the data. Unfortunately, too many of them don't do the data extraction in the end. So, in a way, once I've pulled out my microservice, I've now got that running as a separate process but it's still talking to the old database. Then you get a bit of a clear understanding of, "What parts of that data do this new thing use?" And then you have to make the decision "Well of that data that this newly created microservices use, how much of that data should really move into this microservice? And what part of the data should really stay where they are, and in which case, we've got to clean up how that data is accessed?"

Martin Fowler: My colleague Prayful Todkar wrote a piece on martinfowler.com about breaking up our microservice, specifically focusing on the data. I think it is a particularly useful thing to look at because, to me, certainly, the data side is a really important part of it. People, of course, should remember that even with a single database, you can have separate schemas. In fact, that's usually the best way to go is to keep one database and separate the schema. By doing that can be an important part of keeping that data separated.

Sam Newman: If I look at organizations that run microservices on-premise, on their own data centers, on their own private clouds, they typically will have a lot of logically isolated databases running on the database infrastructure. This is partly because speeding up a fully isolated database infrastructure is too expensive. So, that's a very, very common model. You do then need to deal with, of course, the potential single points of failure you get. But that is a very common model, and that's often a bit of pushback I get, is that's gonna be really expensive. It's not every single relational database under the sun that lets you host multiple databases of database node. You can do that.

And to be fair, that's really the main pushback I get. There are all kinds of other challenges that people start seeing with breaking databases apart. You get concerns around performance, which I think are valid to raise, you know, the worsening latency. You get issues around things like data consistency because if you're breaking foreign key relationships, you're typically often also breaking the enforcement of referential integrity within the data model. So, you have to deal with how that all works. And then some people just want all their data in one place.

I think there are good arguments and explanations for how you resolve all of those issues, but it is all work that has to be done. It's right that the database chapter that I put in the microservices book is the biggest chapter in the book because there are so many difficulties that emerge in that space. And so, I think what we maybe don't have more widely as an industry are more tools in our toolbox to say, "Well, actually, in this situation, there's this, this, and this that could help you, and in this situation, there's this, this, and this that can help you." And I think that's what's really good now is that we've got more case studies of people that have done this that are able to share the techniques that they've used to make these things happen.

This is the first time I've kind of tried to write patterns was in the microservices book. I then tried to take some of those experiences and kind of create a named pattern around some of these things. I'm not very good at naming things, but I do think that we can't even imagine a world in which you break a database apart because it's not something we've ever done before. And actually, look, let's be really, really honest. There's another reason why a single process monolithic application works so well is relational databases are amazing. They are really, really good. Joins are awesome. There's a lot of value in being able to run arbitrary queries over large sets of data. There's a lot of good sides to it. An ACID transaction is fantastic in terms of helping you reason about the system. Guess what? If you go into microservices, that's all going out the window, and this is again, part of that sort of difficult journey of learning that you're undertaking,  where you are moving through this sort of rocky path towards some greater distributed future.

Handling people

Martin Fowler: Yes. Consistency is another reason to be very wary of going down the microservice path, right? Because it's a whole more complicated world of eventual consistency that you've got to start dealing with and you can no longer keep things all straight with each other. That's not something that's easy to manage. So, data is complicated, but if there's anything... The one thing I would say that is more complicated than data when it comes to software development is people because people are always the most complicated part of any software development effort. So, when I think about microservices, and we've hinted a little bit about this, is the difference in skills, the difference in culture. People aren't used to managing distributed systems to the degree that microservices requires it and thinking about independence and all the like of it. So, where do you see some of the biggest issues that tend to be top of your list when it comes to organization and people's sides when it comes to microservices?

Sam Newman: Yes, there's a famous Gerald Weinberg quote, which is, "It's always a people problem." There are obvious skill gaps that start creeping in. Let’s talk about the dysfunctions or the challenges I see at larger corporates that I work at. When you go from an organization that is used to managing more monolithic software where, or maybe the monolithic software is not the issue. It’s the fact that its software hasn't really changed much. The sort of structure, the outline of the software hasn't changed in 5, 10, 15, 20 years. This is the shape. It is a box. Things go in the box. And the organization is built up knowing how to manage that box.

And we're now moving into a world where we're saying, "There's not one box. There are lots of boxes. We don't know what the box is gonna look like yet. There's gonna be some boxes that will get bigger. Some boxes will get smaller." And just fundamentally, you know, the way an organization goes about making decisions, just scale or shift doesn't work in that world. You go from sort of a rather old-fashioned way of making decisions, which is maybe more centralized command and control type mindsets, where you don't need to make many decisions very often, but every decision you make gets debated endlessly. And now we're moving into the world of microservices and where it's like, "Well, what the hell is all this going to be?"

One of the earliest things that comes up, I feel, in this environment is, "Where is that power? Where is the power that goes about making decisions?" And there's got to be a bit of a willingness to change as an organization if you want to get the most out of a microservice architecture. I think if you are a very old-fashioned command and control mindset that is used to doing centralized decision-making, then I think you'll pay the cost of a microservice architecture. Let's be honest, microservice architectures will very rarely save you money. They do not save you money. They might help you make more money, but they are gonna cost you more money in the short-term. So in that environment, you might end up paying the cost and having the pain and suffering of a microservice architecture, but if you don't also look to maybe embrace some degree of organizational autonomy, then you're going to be missing out on the really big benefits.

It doesn't have to be overnight. I think this is the other thing that people start getting worried about. The other thing that I see is some organizations just will not change anything and everything still has to be done the way it used to be. Other organizations go from a situation where developers are used to turning up and working from 9:00 till 5:30 and then going home to their families, and then they turn up on Monday and say, "Oh, guess what? You're now a DevOps, and now you are gonna own and run the software, and you're gonna do production support, and you're gonna have full ownership." And, you know, in those sorts of organizations you get about 5% of people to get really energized, and 95 percent of people start looking for another job. It's almost like everything has to be a massive decision, everything has to be a big decision. For me, when I'm thinking about the organizational change aspects. I do kind of come back to that dial metaphor.

It's not big or showy for a CTO, or CIO, or CEO to say, "We're going to try doing microservices." I don't think a CEO should even know what a microservice is personally. But for me, as you're making incremental changes to your architecture, you should be experimenting with incremental changes to your organizational structure as well. So, if you're thinking about something like shifting responsibility for things, well, maybe just shift a couple of responsibilities into the teams and support them in that growth. One of the most common dysfunctions I see in this space is that people don't trust the people in the teams enough. They still want everything to be done the same way. They want the illusion that people have some sort of choice, and then a lot of their efforts will go into central platform engineering teams. I'm gonna create a platform on which all things will be done and effectively it's governance through tooling.

And this is obviously where some large companies out there make an awful lot of money selling in things like OpenShift. OpenShift is really good, but OpenShift is often used as a way to build a corporate platform that will try and tell everyone, "This is how things should be done in this organization." For me, it's more about saying, "Okay, what kind of organization do we want to be? How much power and responsibility do we want to have in the teams?" And actually having a bit of an honest conversation about that and saying, "Well, we're going to make some changes and just see what happens. We could try one or two things." But I think, all too often, people think it's either going to happen overnight or that nothing is going to change. And I genuinely think if you spend a little time, energy and money in a microservice architecture and then do nothing to change your old-fashioned top-down command and control organization, you're going to end up with probably the worst of both worlds.