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

We've attended many conferences around the world and collaborated with some of the leading software creators and innovators in this new book club to bring you key takeaways from the teachers themselves in the form of book interviews. They've created learning strategies that allow us to become more efficient developers as we dive into our book club's first online series. This episode was made possible by growtopia.tech. We asked ourselves what would happen if we could take two of the brightest people in our industry and put them together with two people who have written and authored over 15 books. What if we could take Martin Fowler, the most viewed speaker on our YouTube channel of all time?

Reuniting him with Sam Newman, one of the most popular. speakers since 2013 at our conferences, this is the book club we started by asking Sam why another book on

microservices

, so the reason I wrote that book was pretty simple, so I wrote a book called Building Microservices in I guess which I wrote in 2014 and it was published in 2015 and times moved on and I thought I should revise, update and update that book and write a second edition of this book to cover all the new changes that have arisen, so I sat down to work on the second edition of building

microservices

and I thought I would choose the most difficult chapter to work on first, so I chose the chapter that was about how to break the service but separate things, how to take a large monolithic application and how to break it.

I broke it down into smaller individual services and I thought that chapter I knew was going to be very complicated to write, so I would start there and that way you would get a better estimate of how long the whole process of writing the second edition was going to take. take and so I started that process and then two months later I was still working on that chapter and the chapter of that book had gone from being 5,000 words to 25,000 words, so a chapter on making big things smaller had disappeared. very big and then I got stuck with this problem which was what am I going to do with this content and I realized that I was quite enjoying writing and exploring that deeper side, that monolithic side of decomposing things and thinking.

Well, actually this could work very well as a standalone book, so that's

when

I went back to the editors and said, look, I know I said I'd do the second edition and I'll do the second edition, but I've kind of deviated from that. a different leg of possibilities and this could actually work very well as a standalone title, so I stumbled upon it accidentally in the same way that

when

I wrote the first book I didn't sit down and write a microservice. book I sat down to write a book on how to design continuous delivery and I ended up writing a microservices book, so I let the content follow, you know, I almost let the content guide me initially and then once I had a idea. this was going to be its own book, so I went on hiatus and had to reshape the content and think a little about the structure this time.

I'm going to the second edition right now and I just hit Another point like that with the second issue when I'm looking at the whole Microsoft collaboration area, and this time I've been very aggressive in putting a very important point in that and testing all the content I'm not sure about. to a different document in a different git repository, so I got the second edit of finishing and then I'll go back to that content if I want, so yeah, I just got sidetracked along the way, but it was kind of bliss. fun, I often imagine that when people think of microservices advocates, they think of these people who are determined to use microservices in every situation, there's a thousand line program here, we have to break it down into a thousand line program, um and However, as I know very well, I've only really heard you complain about people using microservices when they shouldn't have.

I don't think I've ever heard you complain otherwise, so maybe you should talk about when people should even do it. Consider using microservices because I don't think I've ever heard you make that argument. Oh, okay, so if you want a quick answer on when you should use microservices, it's when you have a very good reason and that sounds. as a test answer of course, well you wouldn't, but I guess what I mean by that is that there is a danger in our industry that we often focus on the activity, not the result, we focus on the technological tool, not in what the technological tool allows us. do and that, to me, a microservice architecture is a conscious choice that you have made to implement something in that style because of some result that you are looking for, there is some benefit that you think a microservice architecture will give you, like my rating The criteria It will be what you think it will give you.

There are some great things. You know, I could talk about the things that Microsoft architectures can deliver. Gives you more options on how to extend applications. It gives you this beautiful independent deployability property when implemented correctly, it can really help isolate the failure surface area, what some people call a kind of blast radius limitation, which can help make applications more robust. I mean, ultimately, you could argue that Microsoft is a micro of the James Lewis quote. service architectures buy you options and fundamentally when you buy a Microsoft architecture you are buying a completely different set of options and choices that you can make, I think James' quote, you know, it buys you options is quite deliberate, although the right options are great for everyone. they have options but buying comes with a cost and they have a takeaway cost number one our industry tends to focus on the technology rather than the outcome one should use microservices as a means to get the desired outcome rather than using a new technology , it's almost like you're saying that your default should be to not use the microservice properly, unless you have a very good reason, go with them olive, uh, yeah, and I would say that I would absolutely also caveat this when saying and trying to be really clear about this idea that microservices are not like an on and off switch, um and I think partly often because we don't know or we don't have the time to engage more fully with the topic, we like to outline things very clearly and let's say this is this and this is that and you know we say that microservices architectures are distributed systems and distributed systems are hard and the phrase distributed systems are hard is true and a monolithic single process architecture is not well distributed. , it's actually correct, so if you think about a normal single process monolithic application if you're reading data from a database on a separate computer which is a distributed system, if you're putting data from that process into a browser which is a distributed system, it's really simple Then you know you won't even see a lot of differences, so my default is absolutely to look at a really simple deployment topology, a single process monolith is going to be one that you could break down into modules within that type of process. limit and then if I think a service-based architecture might be a good approach, I'll try to maybe try one of them to make my system a little more distributed, just a little touch, like turning that little dial, and just seeing What Can I deal with that?

Do I avoid these horrible problems that come from distributed systems and get some benefits from it? So I think yes, absolutely, my default is a single process monolithic application, simple deployment topology, you avoid a lot of problems, but if I'm interested in trying something new, we shouldn't see it as a huge task to try it out. otherwise and that's often the problem that a lot of organizations say, you know, we thought we could do microservices, let's spend six months building a platform for microservices, it's like no, no, just try one and see what happens. Remove number two.

Microservices shouldn't be the default option if you think a service architecture could help try it with one of the modules of a very simple monolith and let it evolve from there, so you need a reason to push microservices, which ones? would be your top three reasons why you think there are valid reasons why people should think about going down that path? Yes, I would choose the main reason number. one is independent deployability and specifically I would say taken to the extreme would be zero downtime independent deployment capability, so the ability to make a change to a functionality implements that functionality and does it in a way that the rest of the system does not need. change so that limits the scope of each version, but also implement that implementation in such a way that it has no downtime, so that's really useful if you think you know a sas-based business where you can't afford downtime and that's really really key, so I think that's the big clear winner.

The second area that has come to mind for my clients recently has been data isolation and isolating the processing around that data, some of my clients have been operating and they say the healthcare industries are a Many of my clients have to worry about things like the GDPR and its implementation. How do I know where my clients' data is? How do I implement things like the right to be forgotten? Because with a microservice, the data and the processing that acts on that data are isolated. You can clearly delineate these services touched by personally identifiable information and therefore could require more oversight, a higher degree of governance and perhaps audited and these never touch these things and they don't even talk to the services that touch these things and so We can both separate them, so I think the data partitioning side is really key.

The third reason, I guess you could argue that this is a facet of independent deployability. The third reason is really where you are. It is seeking to allow a greater degree of organizational autonomy. You are looking to drive and distribute responsibility across teams. You want those teams to be able to make decisions. Deploy software and reduce the amount of coordination those teams need with other parts of your organization. I would say sort of independent deployment capability, I 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 three main things that I see as reasons.

Most of the time we remove the number three, the top three reasons for using microservices are zero downtime, independent deployment capability, isolation of data and processing around that data, using microservices to reflect the organizational structure, looking again at this independent deployment capability, I mean, this leads us to a problematic configuration that I see a lot, which is a distributed monolith which is where you have a system that is called microservices, but to implement this service I have to make sure to deploy this service and I have to update the versions of these services, um, that's it. a trap that people can easily fall into when they don't pay enough attention to independent deployability, but how can you avoid that trap?

What lessons are you finding with people to avoid it? The first thing is to say well if you have an architecture that theoretically allows you to deploy your microservices independently, then don't actually do that theoretical thing, make it a real thing. I've talked to a surprising number of people who said well, we used to be able to do it. implement these services independently, but we decided to just bundle them together because it was easier and you know, many months and years went by and they suddenly realized that they could never go back to the old way of working because you know they almost indoctrinated in their process of I developed the idea that all of these things are implemented together, so having a theoretical ability to do it, you want to turn it into an actual implementation mechanism, that's what you need to do, so that's the first thing and the second thing would be Get Started look for If you find it difficult to change microservices in isolation, look for patterns, so do you see a collection of microservices that are often changed together?

One thing that can be very useful to you is if you are using, for example, a ticket tracker. A tool like Jira is really about making use of the ability to tie a commitment to a job. You know, every month, go through all the stories you completed and look at the commitments, and then you can assign those commitments to which services. storiesShocked Are you seeing areas where you see 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 or maybe look at different ways to slice and dice those services from different ways and those are the two very quick things that I would be thinking about is looking for those patterns, I mean really the kind of technological idea or the The design principle that underlies the independent implementation capability and that I think is the most important is this idea of ​​hiding information, uh, and you know, a lot of things flow from that when you're creating the United States service, if you hide as much information within that service boundary as possible.

If we're going to effectively shrink the interface that your microservice has to the rest of the world, with a smaller interface to the rest of the world, it's much easier to ensure that any changes you make within the boundaries of that service don't change that. interface, so if I can make an internal change to the microservice without changing the interfaces I expose, I can achieve my standalone implementation. I think the challenge often is that people don't know what information is actually hidden. means and um and and so you know it's and we have a lot of technology available to us that makes it pretty easy to violate this concept of information hiding um in the same way that we have a lot of aids and aids for us in our codebases to help us violate encapsulation, which after all is just an implementation to hide information.

Take away number four, you can avoid a distributed monolith by creating a deployment mechanism that looks for patterns and decides how to deal with them, but keep in mind that people don't do this. I don't really know what hiding information really means. Goto gives you the opportunity to learn from the brightest minds in software development. Join highly rated community meetups and conferences and delve into your favorite topics with masterclasses that talk about how we avoid the distributed monolith and again it all comes down to this question of standalone deployability, but that also makes me want to go back and Well, first of all, why is independent deployment capability so important?

I mean, there are organizations that have large monoliths and they've had those and they're able to deploy them at regular intervals, I mean, they have continuous delivery pipelines, they're able to take on people's commitments on a daily basis, redeploy the monolith, I want I mean, it's a great thing about a monolith to deploy, you know if you have everything automated and configured you can just deploy it, so why should we worry a bit about standalone deployment if we have the necessary cd pipelines and we can just deploy our monolith, so there's definitely a great example of organizations that have monolithic applications that have a very, very good story about their ability to deploy software frequently.

I mean the kind of poster for this was originally flicker and then etsy, which were kind of monolithic PHP based apps that had a really clever deployment model and they weren't deployed once a day, they were deployed multiple times a day for developers who were walking around and had invested a lot in creating a pipeline that would work for them in that environment, so it's absolutely possible that it did, but I think the problem Is it easier with microservices to limit the impact of each version? So if I think about an implementation, what I want to do is create an environment where you feel safe making a change.

When I make a change, I feel safe and one of the ways that can make a change feel safe is to reduce the impact and risk of each release. If I'm deploying a complete 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 only deploying a single service I can reduce the scope of that individual deployment and I can manage that deployment more effectively and efficiently if you have also adopted ideas like zero-downtime deployments.

Know that it will also do it in such a way that your system won't really be affected when you have a monolithic single-process application and you're trying to do things like zero-downtime deployments. Quite a few there are 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, so I talked to John Olspor, who was the release engineer on Reefs Manager. on flickr and then etsy and it became etsy cto and he talked to me about how you do things like database changes, for example, and he said, "Well, look, we can do these quick and frequent deployments, but if would we ever have to do some database migration." That kind of thing would still have to be done over the weekend in quiet times because of the greater impact on the system, but if I'm making a change like that to a smaller individual microservice, you know.

It's much easier, the data, the volume of data will probably be less and therefore the impact and the time needed to execute that migration could be less and therefore the impact on the system will be less, so I'm not arguing that it's not impossible to do it with a monolithic application, just from my experience it's much harder to do it with a monolithic application to get those things into a pipeline where you can make those changes in a quick way. , effective and efficient. Another overlap here, I think to some extent is the organizational scale, so for me, if I have a team working on the system, you know you can afford within a single team to have a high degree of coordination, a really excellent fit of the communication. you're working on the same things together, it's easier for you to reason about the changes you're making when you deploy something, so whether it's a monolith or a microservice architecture when you start getting into the world where you have 5 6 10 15 20 different teams and everyone is trying to work on the same monolithic application and then you want to deploy that monolithic application.

It takes a lot of coordination between those different teams to make a change happen. You undoubtedly know Flickr and Etsy. I've never had development teams that are this big and obviously you can do things like break things up into modules, but modules don't necessarily allow for hot deployment at least in most of the runtimes we look at, so there are also a scale element there. Also, I have to admit that I find those last two arguments much more compelling than the general "hey, it's easier to implement one thing" argument because the problem with the "hey, it's easier to implement one thing" argument is that yes, you are implementing just one thing but you have I have a distributed system there is nothing less complicated than a distributed system so yes I only have to redeploy one part but I still have to connect to everything else and yes if you are really good , you can reduce the risks involved. do that, but I mean that's part of the argument, it's hard to be really good at, so I'm not convinced that that makes the larger monolith harder to implement because you can test everything much more effectively if it's a a single monolith before it becomes operational, but I find the other two arguments about the data and particularly about the organization much more convincing.

Number five should strive for independent deployment because it is easier to limit the impact of each release when using microservices and depending on the size of the team. increases, it becomes exponentially harder to coordinate a deployment, since you say data always takes time when you have to do migrations, it's harder to contain it within a single application because it's easier to say just access data all the time, yes, and organizationally that. Certainly when I talk about microservices to people, that's the area that I tend to focus on more than as the size of the team increases, then it's harder to coordinate people.

I think it becomes exponentially more difficult to coordinate increases in people's team sizes, so you need to configure. Barriers and microservices force you into an awkward way of working, which is actually what you need with a larger team. Anyway, those barriers should be modules within a monolithic application. I mean, leaving aside the fact that most of us don't. It does not work on runtimes that allow hot deployment of modules. I mean, that was pretty much the whole concept of structured programming, which was how we take larger programs, break them down into chunks that you can work on in isolation to reduce that. kind of coordination effort, I find it quite interesting that for a while Eric Brooks, who wrote Mythical Man Month, didn't agree with the full parnassus information, um, the theory of hiding, and I think on the 20th , I think he wrote this in the full word of the 20th issue of the mythical man month he basically apologized said I was wrong hiding information it's how you separate the work the kind of interesting thing I think the conversation I remember we had when you were helping build microservices was that the modules within a monolithic system should perform better than them, but we found all kinds of ways to violate those modules that we didn't think about.

They are often not a first-class consideration. Our application or our tools and the concepts of the modules. Certainly things like Java have been historically. pretty weak, but we violate them all the time, but once you turn that service into a process limit, violating those things becomes really painful and there's something about doing something you shouldn't do difficult, so I think there's something about The fact that you've now made this a separate process limit means you may find yourself slower. You're thinking about what those boundaries should be, and it makes it harder for you to do silly, arbitrary things with them.

You know, that's it for me. It's not great, I think it's true, but I'm disappointed that it's true in the sense that we shouldn't need to do the hard things to do the right thing, but that seems to be what life is. Take conclusion number six. we tend to violate the monolithic architecture by not respecting modules when incorporating them into services, it makes it harder to do so, so it's a bit sad that it's a programming language framework that hasn't really done a very good job on modularity . I think the idea of ​​the class was something like this.

Great and gave us some useful tools, but then we did it but it's too detailed and as a result we ended up with nothing. Neither language really gives you much more than the class level to really control modularity in any sensible way, um. and without those tools the best thing you can do is configure yourself and I have come across teams that have done some good things by interrogating the code base to try to detect flaws in the modularization of modules and try to guide people in a better way. manner. direction, but they are things that people have to put above language and languages ​​just don't help us and it's very easy to get around language barriers when they're so minimal and then break them and I guess The way I often see it , the breakage will most likely occur with data handling, as you say with the information hiding section, yes, which then leads to the interesting question, but if we are looking to break up or want to think about breaking a monolith.

Without a doubt, one of the areas that I find most difficult to do is data management. So what are some of the observations you've made about how we can better handle the data to look at that separation? a module in a larger monolith in microservice style thinking, yeah, so let's start with the obvious, data is hard, that's the first thing, and separating data that is in a relational database is also quite difficult because of the fundamental nature of a relational database, you know. relational database is about relationships and it turns out that some of those relationships will end up breaking.

There are some interesting benefits that actually come from working with a relational database, although often the relationships between the data are sometimes significantly more obvious than the relationships. between code, it's surprising how many code bases I work in where I find that the schema does a better job of communicating the intent and understanding of the domain and the code does, and that's often because someone spent a lot of time thinking about a schema . At the front, they never changed it after or after thatway, but it's almost like that, there's a granularity, you can start to see things there, you start to see the shape of things emerging.

One of the first things I often do in these situations is simply charge. the outline into a sort of graphical tool and just start playing with it just by looking at its shape, its structure, there are parts of this that seem more tightly packed or aligned than others if you think of it as something like um, a weird key relationship, ya You know, we think of a foreign key relationship in a relational database as being about referential integrity, and yes it is, but it's also about making the relationship between things really explicit, and in fact, a lot of people don't. it does.

I know, but in relational databases you can extract key relationships without enforcing referential integrity, no one bothers, so there is often some help for you in that space and there it was, but I also realized that great part of the complexity is breaking down the separate systems were going to be in the database so I keep going back and forth on this like I'm going to pull out a piece of functionality and I think this is my data and the processing, I don't know, give loyalty to ordering points for an order, I'm going to extract them and I thought well, if the database is often the hardest part, then maybe you should address that first, make sure it's possible to extract that part of your system data model. and then you could do all the work to diligently separate the database and then the code would be easy in comparison.

The reality is that most people don't want it to do that, and what most people want to do is make some profit. have this new point awarding functionality extracted first into a microservice and so the model I see most often is that people pull the code and then they will look to extract the data, unfortunately many of them don't do the data extraction um. and somehow once I got my microservice out, I now have it running as a separate process, it's still talking to the old database, at least then you get a somewhat clear understanding about what parts of that data this new one uses thing and then you have the decision that is Well, of that data that these new micros, these newly created microservices use, how much of that data should really be moved to this microservice and what parts of that data should really stay where it is, in which case we have to clean up how that data is. i accessed my colleague preferable tutka wrote an article on

martin

ville.com about how to break down a data-centric microservice and I think it's something particularly useful to look at because for me certainly the data side is a really important part and people Of course , you should remember that even if you have a single database, you can have separate schemas; in fact, that's usually the best way to do it is to maintain a database and separate the schema, and doing that can be an important part of keeping that data separate.

And that's actually, if I look at organizations that are running microservices on their own premises in their own data centers on their own private clouds, they're typically going to have a lot of logically isolated databases running on the same database infrastructure, so which is partly due to the cost of spinning. Creating a completely isolated database infrastructure is too expensive, so it's a very common model that you then have to deal with, of course, with the potential single points of failure that you get, but that's a very common model and, often, I get a bit of rejection.

It's going to be really expensive, it's not like every relational database under the sun allows you to host multiple databases on the same database node, you can do that, um, that and to be fair, that's really The main obstacle that I have, there are all kinds of other challenges that people start to see how databases are separated, you will have concerns about performance, which I think is valid to bring up, you know, worsening latency, You're going to have issues related to things like data consistency, because if you're breaking Frankie's relationships, enforcing referential integrity within the data model is often also violated, so you have to deal with how everything works and then some people just want all their data in one place.

I think there are good arguments and explanations on how to solve it. all those problems, but it's all work that needs to be done, um, that's right, that database chapter that I put in the monitor microservices book is the biggest chapter in the book because it's the nas, there are so many difficulties that arise in that space and So I think what we may not have more broadly as an industry is more tools in our toolbox to say, well, actually, in this situation there is this and this that might help you in this situation. This is a problem that can help.

You and I think that the really cool thing now is that we have more case studies of people who have done this and who can share the techniques that they have used to make these things happen, so this was my, this is the first time The time I tried to write patterns was in the Microsoft Monitor book, so then I try to take some of those experiences and create a named pattern around some of these things. I'm not very good at naming things. but I think we can't even imagine a world where we separate a database because it's not something we've done before and in fact, look, let's be really honest, there's another reason why single-process monolithic application works so good.

Relational databases are amazing, they're actually very good, joins are amazing, there's a lot of value in being able to run arbitrary queries on large data sets, there's a lot of positives to it, and acid transactions are fantastic in terms of helping you reason. the system, guess what happens if you go to microservices? That all goes out the window and this again is part of that kind of difficult learning journey that you're going to go on and that you're moving through that kind of this. It's kind of a difficult path to a better distributed future. Yes, consistency is another reason to be very cautious about going down the microservices route because it's a much more complicated world of eventual consistency that you have to start dealing with and you can't. keep things in order with each other, that is not something that is easy to manage, scratch the number seven, much of the complexity of breaking a complex system lies in the data, after extracting the microservices, you need to understand what part of the above database uses the system.

Data is complicated, the only thing I would say 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 about this is a difference in skills, the difference in culture, people are not used to managing distributed systems to the extent that microservices require it and thinking about independence and all that, so where do you see yourself? some of the most important? problems that tend to be at the top of your list when it comes to people organization when it comes to microservices, yes, there's a famous quote from jerry weinberg, which is, it's always a people problem, there are an obvious skills gap, things are starting to appear, but maybe it will be talked about. the kind of dysfunctions or maybe the dysfunctions, but the change that I see, I say larger corporations that I work in when you go from an organization that is used to managing more monolithic software where, and maybe even the monetary software factors, not They are the problem. the fact that it is software that has not really changed much the type of structure the software scheme has not changed in 5 10 15 20 years this is the way it is a box things go in the box and the organization is built I learned to know how to manage that box and now we are moving into a world where we say there is not one box, there are many boxes, we don't know what the boxes will look like, but there will be some boxes. they get bigger, some boxes are going to get smaller and fundamentally you know that the way an organization makes decisions just doesn't scale or change doesn't work in that world, you know you go from a pretty old-fashioned way of making decisions that such Maybe they're more centralized command and control mindsets where you don't have to make a lot of decisions very often, but every decision you make is endlessly debated and then, well, now we're moving into the world of microservices and you know it's like Well, what the hell is this all going to be?

One of the first things I feel in this environment is where is that power? Where is the power that is going to make decisions? um and there has to be some willingness to change as an organization if you want to take full advantage of the US service architecture. I think if you have a very old-fashioned command and control mentality and are used to making centralized decisions, then I think you will pay. the cost of a microservice architecture, let's be honest, Microsoft architectures will rarely save you money, they won't save you money, they might help you make more money, but they will cost you more money in the short term.

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 embrace some degree of organizational autonomy, then you'll be missing out on the real big benefits that it doesn't have. be overnight, I think this is the other thing that people started to worry about, is the other, the other thing that I see is that some organizations just won't change anything and everything still has to be done like it used to. ser and other organizations continue from a situation where developers are used to working from nine to five thirty and then going home to their families and then they show up on Monday and said: oh, guess what you are now our devops and now you're going to own and run your software and you're going to provide production support and you're going to have full ownership and you know those types of organizations you get about five percent of the people who get really excited and 95 percent of the people They start looking for another job um, it's almost like everything has to be a huge decision, everything has to be a big decision, so for me I'm thinking about the organizational change aspects.

I go back to that metaphor of the dial, it is not big or flashy for a cto. A CIO or CEO says let's try to do microservices. I don't think a CEO should personally know what a microservice is, but to me it's like, as he makes incremental changes to his architecture, he should experiment with incremental changes. to your organizational structure as well, so if you're thinking about something like handing off responsibility for things, maybe just handing off a couple of responsibilities to the teams and supporting them in that growth, one of the most common dysfunctions that I see in this space is that people don't trust the people on the teams enough, they still want everything done the same way, they want the illusion that people have some kind of choice and then a lot of their efforts will go to the engineering teams of the central platform. we're going to create a platform where all the things will be done and effectively governed through tools and this is obviously where you know some big companies make a ton of money selling things like openshift no one change is really good but openshift is.

It's often used as a way to build a corporate platform that will try to tell everyone that this is how things should be done in this organization, so to me it's more about saying, "Okay, what kind of organization do we want to be?" ", how much power and responsibility we want to have in the teams and actually have a kind of honest conversation about that and say, well, let's make some changes and see what happens, we could try one or two things, but I think that Too often it's As you know, people think it's going to happen overnight or that nothing is going to change and I really think that if you spend all the time, energy and money on a Microsoft architecture and then do nothing to change your old top down command. and control organization, you will end up with probably the worst of both worlds, conclusion number eight, there has to be a willingness to change as an organization if you want to get the most out of using microservices, subscribe to the YouTube channel now.

For ad-free videos posted almost daily and join the experts in person or online at any upcoming conference using the book club promo code, visit

goto

pia.tech for more information.