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.