Today's episode of the technology on our podcast is proudly sponsored by emergence. The Journal of business agility. This quarterly publication brings you inspiring stories from the most Innovative companies and explores the themes of the new ways of working reclaiming management and humanizing business. It brings together a curated selection of exclusive stories by great, thinkers and practitioners from around the globe that can broaden your horizons and Spark. Your creativity.
Each issue is hen Illustrated. And contains 100% pure content, use the promo code tekhelet eech, Ali-A D to get a 10% discount on your annual subscription. Visit business agility, dot institute's less emergence to get your addition and support the publication supporting your podcast. Here's the link One More Time. Business agility, dot Institute, / emergence. So throughout this. I've been talking about rapid frequent Reliable Software delivery. What is that? So there's actually The four
metrics which come from devops. The research has shown to be a good indicator of high performance. So the whole point of microservices adopting microservices is not to have microservices. The goal is to improve those metrics and that's what people should be incented to improve because sometimes changing your development process around, your monolith will improve those metrics. But there In other situations where you really have outgrown your architecture, your
monolithic architecture. Then adopting microservices is the only way to improve those metrics. Hey everyone. My name is Henry Surya, we Robin. And you're listening to the tekhelet journal. The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your
personal work. So let's dive into our Journal. Hello again, to all my - it's great to be back here again with another episode of the tekhelet journal podcast. Thank you for spending your time with me today, listening to this episode. If you haven't, please follow technology, you know on your favorite podcast app and our social media channels on LinkedIn, Twitter and Instagram, you can also make some contribution and support this podcast by subscribing as a patron at technology.
No, dot f / Patron, and help me to continue producing. Great content every week. For today's episode. I'm extremely happy to share my conversation with Chris Richardson. Chris is, a renowned thought leader in micro services and the author of the book, microservices patterns and the popular microservices dot IO website. He also regularly speaks at International conferences, and delivers Consulting and training that helps organizations to successfully adopt and use micro
service architecture. Microservice architecture has been around for a decade now. And it has been widely coveted as the modern architecture to solve any kind of distributed, scalable system and much debate has also been discussed on how to adopt and Implement microservices properly, including how to migrate from a monolith architecture to microservices in this episode Kris. And I opened our conversation. Talking about the current state of micro Services versus monolith architecture.
And Chris explained why he thinks monolith is not actually an end. A pattern. And when is a good time for us to consider adopting microservice architecture? He then shared about the success. Triangle for implementing microservices important Concepts such as design time coupling and some important microservices patterns such as eventual, consistency The Saga pattern and how his current work on eventuate can help developers to implement these patterns easier
towards the end. Chris briefly explained some of his important principles that we should consider. Party composing. A monolith successfully. I highly enjoyed my conversation with Chris learning about micro services and how to adopt and implement it correctly, and I believe that you will enjoy this episode as well. Consider helping the show, by living the rating, a review on your podcast app and you can also leave some comments on our
social media channels, though. It may seem trivial, but those reviews and comments are one of the best ways to help me get this podcast to reach more listeners and Lee, they can also benefit from all the contents in this podcast, without further Ado. So let's get this episode started. Hi, everyone. Welcome back to another new episode of the technique Journal. Today. I will be someone that I really admire. He is one of the thought leaders of microservices.
He's actually the original founder of cloud. Foundry.com is also a recognized thought leaders and speakers in many different conferences. He is the author of the website called. Cross services, the I/O. So if you are into micro services and have research microservices before, maybe you have bumped into one of his articles or blog or patterns from that website. He's also the author of the book microservices patterns and is currently working on his startup called eventuate.
So maybe we'll also ask a little bit more about what eventuate is. His name is Chris Richardson. I'm really looking forward for this conversation. In fact to learn more about microservices. So welcome Chris to the show. Great. Thanks. I'm excited to be here. Thank you for inviting me. So Chris maybe for people who are not familiar with you yet. Could you maybe introduce yourself telling us more about your career Journey? Any highlights or turning points?
Yeah. Maybe I'll just start with the end. So for the past gosh as study would be forever. Now, I guess for the past seven plus years actually, even maybe even eight years. I've been somewhat focused on the mic for service architecture. I used to say, I like to travel all around the world helping They shouldn't sits up, microservices to mixture of Consulting. And training though, with covid. I just do Zoom from my home
office. Fortunately business is transitioned online, but I really am looking forward to working with clients face-to-face. So that's what I do. These days. How did I end up here? It was a long journey, right? We might first paid job actually was the summer before College back in 1982 as funny. When I was a teenager. I was actually interested in programming languages and compilers and so that's my focus area and after college, I got a job with a company, building lisp systems.
So if anyone can remember list that language with all of the parentheses, which at the time was used, very extensively for AI. People were building quite complex system where on the one client along customer. They're actually using a list based system. To schedule time on the Hubble Space Telescope. And then another client was actually using lists to do, payload planning for the space shuttle. So they actually use for some super interesting applications
there. I'm so I spent seven years implementing lisp systems, building everything from like compilers garbage collectors all the way up the stack to Rich sophisticated ID. He's this was actually all on machines that had eight megabytes of memory. I feel like you could run it on. On your smartphone today, right? Yeah. So anyway, that's sort of gave me an appreciation for sophisticated. Modern languages could certainly at the time late 80s, early 90s mainstream was C. Programming here.
I was building software in this sophisticated object-oriented functional language with garbage collection. Then of course Java came along. Right? There was a 1996 and initially I looked at it. I thought what A Primitive language but ended up embracing it and so I've been in the Java Community ever since. Basically, I was in the Consulting Group helping clients build applications on top of weblogic platform and then
discovered the spring framework. I went to the service side conference that he was less Vegas. 2004 discovered the spring framework and hibernate and those Technologies and just immediately switch to that. Literally came. I'm back to work the following Monday and just said okay. We're going to switch to Spring and hibernate.
I was this architect on his mobile device management platform who were just like, okay, we're going to migrate away from EJ bees and that technology to this more modern technology, which remarkably 17 years later is still dominant in the Java space. And that actually would led me to write my first book, which was pojos an action that was all about building applications with spring and hibernate sort of Formative Enterprise, Java Technologies, and I was 2006.
And I did ended up doing consulting and training around that for a while. And then I discovered the cloud actually was 2006, an evangelist from Amazon, gave a talk at the local. Jug we'd boy was going to give a talk about apis for buying books. Instead. He talks about S 3 SQ S and E C 2, which just blows my My mind, it's like, wait, with an API call. You can provision 20 servers and pay ten cents an hour. So I just got super excited about that. And ended up getting my guess.
It was beta access, maybe even a few months later, 2007 and that led me on the path to creating Cloud. The original cloud Foundry. That was a Java pass few clicks of the mouse. You could upload your War file and it provision the bunch of ec2 instances running Tomcat. Hachi. My Sequel and monitored manage
order of scale. Remember, none of that existed in the AWS functionality at the time and this fact, she was helped by the financial crash, in 2008, which made my Consulting business evaporate and it was like, well, I got this time on my hands instead of a zero Revenue consulting company. It can be a zero Revenue early stage startup much better sounding and that led to the
creation of the original cloud. Foundry, which was then acquired by Spring Source, I reconnected with the spring folks, which was pretty awesome. And then we got acquired by VMware and then spun out into pivotal. And I should say for clarity. Today's Cloud Foundry was developed by an entirely separate group, but they took the name from the cloud Foundry that I develop. So I have no claims on the technology, but it's nice. That least the name lives are during my time at VMware.
I had got interested in this concept. Set to basically functional decomposition into a set of services and now holds the their architectural style, which actually is very old. One ultimately got the label of microservices. I got interested in that sort of 20 2010 and then just got more and more interested in it and started talking about it and 2012 and it generated a lot of interest. Got here. I am 20 21 still talking about the same old stuff.
Perfect. Wow, thanks for sharing your story, the history where you got to where you are at this point in time. So thanks for sharing that. So obviously you have been doing this for quite some time. You mentioned and D12, maybe he was your first talk about microservice now is almost 10 years. So what do you think is the current state of all these micro service which is monolith debate? Or what kind of, you know, the cool things about? Microservices this day if it's still cool.
Yeah. Well, I think we almost every technology goes through the Gartner hype cycle. Well, first, it's amazing and it can do no wrong. Everybody should be using it. And then people realize that no technology is perfect. Right? Nothing is the silver bullet. And then there's the backlash and it's like that technology sucks. And then ultimately people figure out the trade-offs with in and the areas when it's best to use microservices or a
technology in general. I think very much microservices is going through Ooh that hype cycle right now and there's sort of numerous anti patterns of adoption. People are using it when they shouldn't. It's like I'm going to upgrade to a modern technology stack and automatically assume that includes using microservices. Usually there's a whole bunch of criteria for when you should use any particular technology versus another and that's exactly true
with microservices as well. The monolithic architectures rate for many Scenarios. And then the microservice architecture is great for other scenarios, like with everything. It's a giant, it depends you could. Certainly say, if you have a large project with the large number of teams, given that one of the primary goals of microservices, is a rapid reliable frequent delivery of
software. And the idea is so it in order for an organization to compete successfully in the modern world, where new competitors can emerge out of nowhere. I actually think it was Hong Kong government, decides to license 6, digital Banks. Suddenly, the brick-and-mortar banks have six new editors. Presumably, they need to be able to react quickly to that. And then, of course, covid you could say that's like the ultimate disruptor.
Certainly in the u.s. Online grocery delivery jump forward five years actually within about three weeks. I think it blocks. The world is very Dynamic and unpredictable, and businesses need to be nimble. Which means that it needs to be nimble, which then translates into certain architectural requirements, testability deployability, modularity is important, so that you can rapidly deliver changes to your software.
And sometimes some situations, you can have a modular and monolithic architecture with those characteristics. But once you get to a certain size, certain level of complexity, quite often the Microservice architecture is about of fit. It will very much depends, but you could save that. Yeah, if you look at the world's leading technology companies, I would think the majority of them are using microservices Amazon basically adopted I'm going to say a distributed architecture back in 2002.
Google have a distributed architecture. Well, those are companies are operating at massive scale with a gazillion users, but certainly Many cases, they didn't adopt Services because of scaling. A say, certainly. This is the case with Amazon, the adopted them because they were operating in a highly competitive environment and they needed to move quickly because you can scale a monolith more or less to have, you know, support a large number of users.
The microservices is all about tackling complexity. I saw one of your articles about monolith, which I think is pretty interesting too, maybe educate or clarified. A lot of people. So in that article you basically title it. The monolithic architecture is not an anti-pattern. So while so many people these days think okay monolith is a bad architecture. We should move away from it. Should adopt microservices. Why would this article saying that?
It's not an anti-pattern. Maybe you can Enlighten us on this front. Well, I mean if you think about what a model is this at such traditional architecture where everything gets packaged to say in the Java world is a single War file. So your architect it from a logical perspective, you've got modules packages and they're collaborating to handle requests and you've got a single database by me. It could be a bit more complicated than that, but it's best think of it as a single
database. That's really simple. All communication with in between the modules of your application of Simply method, or function calls. All of your data is in a single database, which means that you can Just use regular acid transactions, and is just the application. So it's just simple and familiar. Whereas, mediately switch to the microservice architecture. You're building a distributed system. So communication between the different parts of your application.
And now some kind of inter process communication, whether it's rest or gr, PC, or messaging, and so on, which is just much more complicated. Didn't simply calling a method and then your database and a microservice architecture. One of the key essential characteristics of a service is that it's Loosely coupled as a couple of different meanings
there. But one of them is designed time coupling, which is where you want to be out of change your service without other two services having to change in lock step one key way to achieve that is to treat each Services databases private, so Oh Kyle, a private fields of a class. Right? No one can access that. So, what does that mean? Well, it means that each service has its own database. So that makes transaction management, much more complex. You can't simply begin.
A transaction update arbitrary data in multiple services and commit that transaction where you could try, you could use two phase commit, but that's quite complex. And it also introduces another type of coupling run. Time coupling, which is where Services have to be up together in order to handle a request and that actually impacts your availability. So you end up, you can't use classic distributed transactions and you have to use eventual consistency, which is much more complex.
So it's likely monolithic World. Simple. The microservice wall can be more complex. So hearing what you say about microservices from all these complexity, probably, it's an exponential difficulty in terms of difficulty, right, where you have to handle transactions, for example, eventual, consistency. How about failures? If you need to coordinate multiple services, so why suddenly all these crazy about microservices?
What do you think will be the right time for any company or any product to actually embrace this? Well, it's sort of assume that you're operating in a context where we need to deliver software. Rapidly frequently and reliably view, the state-of-the-art for software development practices. This might sound extreme but the ideal world is where I'm a developer.
I commit my change. That change is just automatically built tested and deployed into production and as a developer, I'm committing changes at least once a day. So you've just got this constant stream of small changes. Automatic being built tested on automatically deployed into production one of the challenges. So if you've got a small monolith, you can do that. There's many different factors to consider. But if you think about what, how long does it take to run the
test? That's one key factor, you know. If your monolith is small, the test will execute very quickly. So your deployment pipeline can keep up with the rate of commits that are coming from your development. Put as your application, grows in size, it gets bigger, and bigger. And then the test take longer and longer. If you think about even just something as simple as the startup time for your application, massive monolith can take many minutes to start up and then you can run some tests.
So ultimately there are these issues around the site, just the pure size of your application, slows down your deployment Pipeline. And then also from the perspective of a developer. But if I'm working with its complex code base, that's can be overwhelming as well.
And there are ways to modularize it so that you can break things up. You have a modular monolith where you can break things up into vertical slices and which can be worked on independently, But ultimately, they have to be assembled together and tested at some point. It becomes problematic class. When you deploy the application, you're deploying it in its entirety, which I think is just Apparently complex. And then you contrast that with the make for service architecture where you have a
bunch of Team sized services. So I'm working on the order management team. I'm responsible for the order of service. That's a much smaller more easily. Understood codebase. I can build it test it quite quickly, push it into production and I can change the order service without having to update customer management. Or account management and so on. So you have that independent employability and so it can be, if you've got a rapid rate of change.
The microservice architecture is much faster, much more fluid. And then the last point I would make is, you know, you think about modern application or successful applications that run a business, they tend to last for decades. So you imagine that you've got some fifteen-year-old application and its massive. Upgrading that application to a new technology stack, even basic stuff. Like I want to apply security patches. So which means that you have to remain reasonably current, you
want to hire people. They don't want to work on Ancient technology. So it's important to keep your code base current, in terms of what technology Stacks it's using, that's really difficult. If you have a massive monolithic application, whereas, if you contrast that, That with the microservice architecture. Each service is relatively
small. It can have a different its own specific technology stack and you can upgrade one service at a time and that helps you build these applications that are sustainable over the long run. And I think you also mentioned that these triangle for Success implementation of microservices. Right? Could you maybe share? What is this model about? What is this success of triangle? Oh, yeah, so the argument goes
this way, right? Because the world is volatile and uncertain businesses and hence it need to be nimble and agile and they need to deliver software rapidly frequently and reliably and sustainably over the long run. And so the question is, how do you do that? And so that's the success. Triangle. It says, in order to accomplish those software delivery goals. You need to do three things. One is, you need to embrace death. The bolts as defined by the
devops handbook. It's a set of principles and practices for delivering software rapidly. Part of that is stream of small changes flowing into production. The second part of the success, triangle is the organization. The idea there is that you struck to your organization as a set, as a network of loosely coupled, autonomous cross-functional team because you really want to have Wait, with siloed, developers, develop QA tests and production
managers. Where are you have to hand off software from one to the other and then the people are incented for very different things. Developers are paid to change things. And up, Sileo basically paid to keep things stable. In other words, not change things. And so teams are just have all of those responsibilities within the same team, but then I actually Operations. They provide platform to enable the teams to do self service deployment.
Excellent book on that called team topologies, which is sort of like a blueprint for modern organization design. So we've got process, you got organization. And then the third part is architecture. You need an architecture that supports devops and that's getting into deployability and testability. You need an architecture that supports the organizational. Structure. And that's what Conway's law
replies. Basically Conway's law says that the structure of the architecture and the structure of the organization that created the architecture of basically mirrors of one another. So if you want a Loosely coupled organization, you need a Loosely coupled architecture modular. Your architecture is comprised of modules modules have apis, there's minimal coupling between those modules.
So that the Teams are not constantly in meetings to discuss an aligned and all of the other things, people seem to spend their time doing and tightly coupled organizations. We've got an architectural requirements. I think I said testability deployability Loosely coupled modular architecture. And then if you throw in the sustainable peace, that means you need an architecture. That lets you upgrade your technology stack easily over time. Which in a sense you could say,
as a modular. Concepts are related to modularity or it's evolvability. Right? So you've got a set of requirements that you architecture must satisfy, which then goes back to sometimes, you can satisfy those requirements with the monolithic architecture. But once you get to a certain level of scale, you're probably better off using the microservice architecture. So, you mentioned a couple of times already a regarding independent deployability, right
modularity. And also, Loosely coupled services and you refer to this as design time coupling also a few times, what do you think is a design time? Coupling. What is that actually? And why we should avoid that. Well the degree of design time coupling between two modules, not say A, and B is the likelihood that A and B have to change in lockstep and you want to minimize that, right. So let's imagine for instance, those two. Well, let's just say automatically customer management.
There are owned by different teams. So requirement comes in some new requirement comes in the ideal scenario. Is that requirement just impacts one of those modules. So it just gets assigned to the relevant team. Now, if there's designed time, coupling between those services or between those modules team, a changes their service that actually forces a changed.
To service B which requires having meetings in coordination with the other team suddenly, the whole process of implementing that change takes a lot longer ranging from you actually have to find a time when you can both meet. You have to find a meeting room. Most companies. I visited they never had enough meeting rooms. It was like finding a meeting room, was a major challenge in the work environment, which is sort of a sign that Organizations with too tightly coupled also.
Different teams can have different priorities and so to get something done that spans teams. They both have to make it a priority which can be challenging as well. Whereas if work is happening inside a single team. He does have a discussion at your daily stand-up. People have done studies. Go Works through the study of this and it was like decision making across teams took 10 times longer than decision.
King within a t so it all largely ties back to the concepts of design time cup like so it's sort of like how do you achieve that? And part of it is having well-defined stable, apis that encapsulate, the design decisions of the implementation so that they can be changed without impacting the API. This very kind of cool concept of software development that dates back to like the 70s.
That's why I designed time coupling is really important to just minimize coordination and communication between the tips, but I'll give you an example. This is from back in 2002. Nothing to do with microservices, but I was working on this device management platform, you know, I was leading the server team and then there was a client. He they wrote low-level code. That one in mobile devices. We were in the US and they were in the UK.
Well, we met we agreed on the Kpi simple API that we were going to use to communicate. They just went off and did their development and we went off and did our development and then, let's just say, six months later. We met and integrated the two pieces together followed by remember, it'll just kind of work and I think that was a good example of having Loosely coupled software that could be developed independently. Otherwise, the opposite would
have been some tight. Coupled software where we can constantly, having transatlantic phone calls. It would have just been a lot slower and a lot more unpleasant to actually develop product. So, also I see a lot of people who started from one of the, if because, they are so used to have dysfunctions all available to across different teams, and they just call each other. One of the common interpreters. ICS was, they break into different Services, right?
Not necessarily a lot of bike or Services. They will tend to have this shit. At library, maybe call it a core. Common modules that is shared across different services. So what do you think about that? Is that also a design time coupling? Well, it depends, you could view it as there's two types of shared libraries. So one libraries where different Services can use different versions than the library and still function correctly and
that's good. It just saves duplicated code, duplicated development and that's primarily It's to utilities, then there's the other type of library and that would be a library that has business logic. Everything is great until the requirements change, and that library has to be updated and all of the services that use it, have to be running on the same version. Now once in a while, that's okay.
It might be worthwhile trade-off because if a library is embedded within a service, it's invoked by Via local method. Cool. That's super efficient. There's actually a benefit to embedding to having a shared library, but then the downside is having to upgrade multiple services in lockstep. So it's generally a bad idea except when it's dull, you know, there was a company segment. I think they gave a talk about Hugh con about how we adopted microservices. It went badly and we went back
to a monolith. And I suspect that for remember correctly, the actual problem. There was, they had a shared library that implemented business logic, that kept changing the force that services to be updated in lockstep. Constantly, that scenario is known as the distributed monolith anti pattern, which is basically where you have a distributed system, but you have to change all of it in one go. So you've got a monolith. It really is like the worst.
Of Both Worlds, but in that keyword, here is the lockstep. If you notice that you always have to do this kind of lockstep where you'll require, once it is to change before you can change. I think that's anti pattern that we should avoid, right? Yeah, that's very much. An architectural smell. So you should design up front to eliminate it. But then it down the line, you see that, it's constantly occurring where Services A and B of regularly changing for the
same underlying. He's a, that's an indication that a refactoring is needed. So another thing that is complicated in all these micro Services architecture, is what we deem for distributed transaction kind of thing where you actually have to maintain consistency by committing in multiple databases across services, and actually our company eventuate is doing a solution around that, but before that could you maybe share with us? How do we commonly tackle or solve this problem?
Oh, yeah. So the example I use all the time is customers and Waters. There's a requirement where the customer has a credit limit, which means the in order to create an order, you have to reserve some of that credit. So you can imagine the customer and to the has an available credit attribute that gets reduced by the order total when an order is created and but it can never go below 0. So a monolithic application. No, big deal right in.
My cursor is architecture where you've got customers and orders and different Services. The order service has to Reserve credit. Inside the customer service, that request spans Services. The approach that you would use, as The Saga pattern. They would go basically like this. So, step number one. The order service would create an order in the pending State. A message would be sent to the customer service, asking it to. Have credit where tries to do that.
Two possible outcomes, of course where she three. Customer doesn't exist. Credit was successfully reserved or the credit limit was exceeded. So the customer service will send a message back to the order service. And the order service, it will change the status of the order to approved. If the credit reservation was successful, otherwise change the status of the order to reject it, if it was not So it's a bit more complicated and then there's a whole bunch of
subtleties, right? We're no longer using acid transactions. It's eventually consistent. But if you think about the context, imagine that the order service had. A lot of complexity, the customer service had a lot of complexity by splitting them into two, which would enable each one to be built tested and deployed independently. We've got tremendous benefit. Just that the downside is we have to use Is the Saga pattern depending on the situation that can be a very worthwhile
trade-off. Let me once again, this is all a giant. It depends, you know, sagas have the potential for them to be extremely complex, and it could be a sign that the two Services should be merged. But in other situations, they can be worth what you think. About. A really simple Saga, right? You have an order taking system that takes an order and then it just Fives that fulfillment system ship disorder. That's actually an example of a really simple Saga and no one
would argue with that. It just worked. One of the key thing is, sometimes it's very much, a worthwhile trade-off. Where is another situation? Deserves too complicated? We can't do this, and we have to merge together. Yeah, and then how does your product eventuate actually help with all this? Oh, yeah. So basically, it's a Framework, where it's platform because there's this sort of code that
runs inside the service itself. And then there's a sporting service, the implements, both The Saga pattern, and then some of the key underlying patterns that make all of this work reliably. So you can build sagas. That's definitely one part of it. Some of the underlying patterns are actually super interesting. So I want problem, you have is I said with the order service And water and sends a message via the message broker.
Those two things have to be done atomically, the you're doing two things, updating a database, talkin to a message broker. So, how do you do that atomically? Because if you do one and not the other, your system is in a permanently inconsistent state, so the pattern for that is actually known as the transaction out books, pass it and that's where instead of sending a message directly to
the message, broker the service. It's actually inserts the message into an out books table in the database as part of the transaction that creates the order. And that gives you atomicity, those two things because of the database transaction will both happen or neither of them will happen. And then there's a separate process, that's pulling the messages out of the database and sending them to the message broker. And that's sort of one of the key Foundation patterns that
eventuate sport. This is actually quite complex. Can the ideal case rather than querying the database table? It's actually reading the database transaction. Look sort of Highly database specific. So eventually it does that and then on the receiving end the message, broker can deliver messages multiple times. So the message Handler has to detect and discard duplicate messages and eventuate implements that patterns.
Well, so you the item Impotent consumer Captain, so that's just a sampling of some of the key pad instead eventuate supports. But the actual original motivation for eventuate was it was an implementation of the transactional out books pattern, and it grew out of that. So, based on the few things that you have mentioned thread section of box, pattern item, put them receiver pattern. Is there any other thing, or maybe tips for people to implement these Saga pattern
correctly? 12 is actually a quiet deep topic. So, for instance, if you think about one of the interesting things about the Saga pattern, right, so it's a series of local transactions in multiple services. So if step 5 over Saga fails, you actually have to undo the changes that were done by the first four steps. And usually it's the semantics can be a semantic undo. For instance. Do you actually have to execute what? The note is compensating transactions to undo what was
done. Previously, in the case of the customer and Order example, changing the status of the order to reject. It is actually a compensating transaction. So there's a lot of careful design required. Once again, you contrast that with a regular asset transaction where the service can simply execute a rollback statement to abort the transaction. Really simple happens automatically, but With sagas, you have to design it. That's another level of
complexity. The last thing that you have to actually think about when designing sagas, is what happens, when two sagas execute concurrently. Now, if you go back to like database Theory, but goes back to the definition of acid, Atomic consistent isolated and durable, turns out the sagas, lack, the isolation. Property then you go. What's isolation? So isolation is a property. That means that the concurrent execution of to database transactions is equivalent to
some sequential watering. So if a and b are executing concurrently the outcome is either a followed by b or B followed by a primitive databases, they do locking and stuff to make that happen. But anyway sagas don't have the isolation property. That gives rise to what is known as a data. Anomaly in classic database literature. There's dirty reads for one. Transaction can read the uncommitted changes of another one lost updates and fuzzy reads.
So if you look at the customer and Order example, the order is created in a pending State. That's actually an intermediate State because the Saga has not completed. The ultimate outcome is still All being determined and that's actually a dirty read. And once again, the sounds really scary and in theory could lead to slaughter them bugs and so on but it's sort of a level that you just have to be aware
of this problem. So for example, someone queries, the state of waters and this order that has just been created and in the pending state, is that a real order yet? Whoa, It's still being determined but it's like from a reporting point of view. Maybe it is. And and then if someone tries in theory, someone can cancel it, but what does it mean to cancel in water? That is still in the process of being created? And we may or may not have reserved credit.
So there's some sort of complex issues there to solve them. You have to be aware of these design techniques known as countermeasures. Countermeasure is a design technique that eliminates these data anomalies and it turns out, the reason you create an order in a pending state. Is that snake? Example of a semantic lock that order is locked at the application Level and it's sort of a softlock, the application logic.
Any application logic should actually look at the state of the order and go. Oh, it's pending, therefore I should do something different. Perhaps, if someone tries to cancel it, maybe the council should fail with her status saying, try again later. So, it's something you have to be aware of. And design for explicitly rather than just relying on the database to make this happen magically for you, Shameless plug. I have an online course that talks about all of these issues.
Right? So I'll make sure to mention that in the show notes. So as we put all these complexities, I think it's really good to have these kind of patterns. In fact, I think microservices. Are you try to have these patterns available for people to read about and understand what these the common problem that you see. And what are the typical patterns that you can use to solve this? So, I think that website itself is gold for people who would
like to invite microservice. Another thing that I saw you Advocate is actually when people try to decompose their monolith, there are ten principles. So I know that we are running out of time. We won't be covering all of them, but maybe if you can do in a kind of, like rapid fire Manner, and I think maybe five different principles maybe that start with make the most of your monologue. Yeah, like, principle number one is, don't Except in the sense try and make the most of you monolith.
So for example, yeah, I've sort of had this conversation a lot with people where it's like, yeah, you know how development process is really slow and there's bugs. I think we should just adopt the microservice architecture and that will fix our problems and it's sort of like, yeah, maybe microservices will solve your problem, but I would first look at actually optimizing your development process.
So, for instance, could common problem with a lot of Enterprises. They don't do automated testing the relying heavily on manual testing, while, if you put in place, automated testing, that's likely to have dramatically improve your ability to deliver software quickly, right? Fewer bugs, higher quality software, much more rapid delivery. That's just one example of how you can improve your Process with your existing monolith, especially when you're a small team of people.
If someone came to me and said that we've got 100 developers and we're having problems, perhaps it would be more likely, the part of the solution would be to use the micro service architecture. But if you have a team of five developers, probably not and it's not black and white, it will very much depends, but the smaller the team, the more likely that the monolith is, okay. Okay, and it's your development process.
That's lacking the second principle that I find interesting is that success is improved velocity. And reliability. Maybe can you explain a little bit more? Yeah. This is a really good point. So, throughout this. I've been talking about rapid frequent Reliable Software delivery. What is that? So there's actually four metrics which come from Devils. The research has shown to be a good indicator of how Performance one metric is lead time.
What's the time from a developer committing, pushing the changes checking in their changes, to that change being deployed into production, High performing organizations. That lead time is too short. State-of-the-art. You could say it's 15 minutes. Basically, you've got a fully automated deployment pipeline, the builds tabs. Deploys each commit. Another key metric is deployment frequency. How frequently are you deploying? And it's somewhat tied in with lead time. You could say.
A goal would be at least once a day per developer, which is quite different from the we deploy. Every two weeks to every one supporter. So those are the two metrics that are measuring velocity, what I should see with deployment frequency. One ain't seen example is Amazon. We're doing it like that 130,000 changes a day to production which is like weak points. Second. And then there's reliability. And interestingly you think about the traditional approach to doing things?
Reliably is to do things slowly and carefully but it turns out and this is key book to read is the accelerate book by Jazz humble and his colleagues and they found that high performing organizations are delivering small changes. Very rapidly in production, and it also leads to Greater reliability. T, which is completely counterintuitive, right? But the idea, if you do things slowly, that means every deployment, you're changing a massive amount, which is actually highly risky.
You don't fully understand the impact of the change. Whereas, if I change one line of code, there's a pretty good chance. I know what that's gonna be impact of that. The other extreme. So there are the metrics around change, failure rate how often to deployments actually. Rake production and interestingly with Amazon, with their massive rate of change.
They're hardly ever doubt. I mean, it's really unusual to go to amazon.com and Fritz and not work and then it related to that is mean time to recover if there is a problem. How quickly can you detect it? Diagnose it and fix it. And once again, you should rarely have production outages and you should be able to recover from them really quickly
nose for Or metrics. That's the measure of how performin your organization it. So the whole point of microservices and adopting microservices is not to have microservices. It's really is to improve those metrics, you know worked with an organization's where this is one case, CIO says, do microservices and it was a top-down hierarchical organization. I'd meet with developers and our gasps. Why are you doing?
For services and they go. Well, my manager told me to it is almost like, microservices became part of their keep the eyes, but that's not the goal. The goal is not to have microservices. The goal is to improve those metrics, and that's what people should be incented to improve because sometimes changing your development process around, your monolith will improve those metrics, but then in other situations where you really have outgrown your Teacher your
monolithic architecture. Then adopting microservices is the only way to improve those metrics, but thanks for reminding us again. The key metrics is not how many microservices you have. How small is your micro service? So it's more about all these four key metrics.
There are metrics some of them say so thanks for reminding that unfortunately, we cannot go on to cover the remaining eight, but for people who are interested in this principles, will check it out on Chris, Richardson's block. I think it's really insightful. So Chris, I know we are running out of time. But before I let you go, I normally ask this one question for all my guests, which is to share your tree. Technical leadership, wisdom as a tips for all of us here in our career.
Maybe we can learn from you. Yeah. Well, I've had a little time to think about it. Perfect. I got a few things come to mind. I think one is just learn be curious. The two other ones, that sort of come to mind one is, it depends recognize that it depends? There are no. No, silver bullets. You want to look at every technology as having a set of trade-offs and this sort of goes back to patents, benefits drawbacks and issues, which is sub problems that you have to solve.
And so, when you're doing any kind of design, you really want to just be aware of that. Lastly. I would just say think evaluate the trade-offs. So it's really a timely reminder. For those of you who are thinking of adopting microservices fall, not Good reason. Again, it's been a pleasure Chris for people who would like to learn more about this. Maybe follow you or contact you where they can find you. Oh, well couple of places.
It's like microservices thought I. Oh so that's where the patterns reside presentations code Etc. There's also Chris Richardson dotnet. So that's my Consulting Scion training site and then obviously eventuate dot IO, that's my company. So Great. Thank you so much for spending your time. It's been a pleasure. I learned a lot from you. So good luck with all your talks courses and also the product itself. Eventuate are a great. Thanks.
I've enjoyed it. Thank you for listening to this episode and for staying right till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow these podcasts better. You can also find the full show notes of this conversation on
the episode page at technology. No, the death. Including the full transcript interesting quotes and links to the resources and mentions from the conversation. And lastly make sure to subscribe to the shows mailing list on technology, another death to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.