I'm starting to notice lots of posts and

articles on the topic of why developers

are dropping microervices as an

approach. I think that this is probably

wrong, but also probably a mistake if

true. So, are developers dropping

microervices? And if so, why is that?

And what can we learn from all of this?

And how could we do better? That's our

topic for today.

[music]

Hi, I'm Dave Farley of Modern Software

Engineering. Welcome to the channel. If

you haven't been here before, please do

hit subscribe because it helps us reach

a bigger audience. And if you enjoy the

content today, hit like as well. So,

first, is this really a thing?

Microservices as an approach remains

very popular and you can see that from

this Google trends graph as a search

term at least micros service doesn't

seem to be going anywhere at all. But

based on the number of articles on the

subject with titles like the death of

microervices or why microservices aren't

popular anymore, there's certainly some

realization that things aren't quite as

straightforward as people once thought.

As I started exploring this idea online,

there were a lot of links to one article

that doesn't exist anymore, published by

Amazon a couple of years ago, which

describes how they dramatically improve

performance and reliability and reduce

costs by moving one of their

applications from microervices to a

monolith running in EC2. I think that

this article may well be at the root of

the flurry of posts on the defa

microervices. It's referenced so often,

which is kind of ironic because if you

read the description of the so-called

micros service approach that they

describe in this post, it raises some

questions. Thanks to Wayback Machine,

here's an architectural diagram from a

disappeared article. My first thought is

that this looks nothing at all like a

micros service design to me. One of the

defining characteristics of a micro

service is that it is based on services

aligned with a bounded context. Can you

see any sense of bounded contexts in

this diagram? Given the aim of this

system is to analyze frames and audio

buffers in real time looking for

defects, I'd expect to see something

about video streams identifying defects

maybe in buffers and frames. So, okay,

some of these concepts are mentioned

around the edges of the the system

diagram, but seemingly only as inputs to

the bit that presumably is meant to do

all of the work, which looks more like a

generic diagram for process stuff to me.

This is the core of the system, which is

built from AWS Step Functions. Step

functions are an orchestration system

that manages workflow between services,

often pre-anned generic services. This

is not really the same thing as a micro

service architecture at all by any

stretch of the imagination. So doesn't

by itself make this a micros service

approach. The original article says that

it was this orchestration that was the

bottleneck that made system perform so

poorly. This isn't really surprising

since they're using a generic low code

tool for processing high volumes of

data. That doesn't sound like a very

good strategy to me. Sounds pretty

risky. Despite the fact that Amazon

claims that this is exactly what Step

Functions were good at. The cynic in me

does wonder if this is why the original

article is no longer available on the

Amazon site. They realized that this

story exposed a weakness in their own

design and their misuse of their own

tools rather than a weakness in

microervices in general. Let me pause

there and say thank you to our sponsors.

We're fortunate to be sponsored by Equal

Experts, Transfic, and Mail Trap. Mail

trap is an email platform that

developers love for fast email delivery,

high inboxing rates, and live 24 by7

expert support. Check their details out

in the description below. All of these

companies offer products and services

that are very well aligned with the

topics that we discuss on the modern

software engineering channel every week.

So if you're looking for excellence in

continuous delivery and software

engineering in general, do check on

their links in the description below and

check them out. Thank you. Let me be

very clear here. I don't want to sound

like a micros service apologist or a

flag bearer. I also don't want to

dismiss a popular effective tool for no

good reason. I think that microervices

are the best solution to the problem of

scaling development activities. They

allow small decoupled autonomous teams

to make progress independently of one

another when they're done right. That's

what they're for really and that's the

reason that Amazon, Netflix, Spotify,

and many, many others built their

business on this approach. You can see

what the Spotify CTO has to say about

their use of microservices in this

video. But microervices are often a

poorer choice for small teams. And the

reason for that is that there is a

significant overhead of complexity in

microservices that simply can't be

ignored. The complexity comes in several

forms. If you'd like to learn more about

the traps waiting in the weeds of

microervices and how to avoid them, do

check out my new LeanPub training

course, Mastering Microervices, for a

more in-depth exploration of some of

these pitfalls and the ways to avoid

them. Follow the link in the description

for a discount on this new course. The

whole win for microervices is captured

in the opening paragraph of the original

definitional article. They are systems

built from suites of independently

deployable services. If you can't deploy

your service without testing that it

works together with other services

first, then this isn't a micro service.

This defining characteristic places a

very high bar on design. You don't get

independently deployable services unless

your design is very good, well

abstracted, very decoupled, very

modular. And that's the real point. If

you follow the guidance, the sometimes

demanding constraints of a microservices

approach, it will keep you on track to

achieve the promised benefit. But if you

ignore those that guidance and simply

think that microservices are all about

small services each in its own

repository without really worrying about

the coupling between them or ideas like

decentralized data management and

deployment independence you'll miss the

point entirely and suffer the costs and

consequences as a result to achieve the

kind of benefits that the successful use

of microservices depends upon. If our

designs must be more decoupled from one

another, then there must also always be

a tradeoff cost for this decision. It

isn't that microservices are a mistake,

but rather that to gain the benefits,

you must also be cognizant of their

costs. Decoupling at the boundaries

between microervices means that

translation at those boundaries. We must

insulate one micro service from changes

in another and so must preserve a

difference or at minimum a potential

difference between the internal

representation of the service and its

external contract with other services.

This always means doing more work at

these boundaries. And so whatever form

that translation takes, it will always

be a little slower than no translation.

Add on top of that the cost of a remote

call across a network and this cost is

dramatically higher than any local

inprocess call. Add in addition an

allowance for the all the ways in which

remote calls can go wrong and speed

reduces and complexity explodes. As I

keep saying, none of this means that

microservices are a bad idea. It just

means that they aren't always a good

idea and that even when they are a good

idea, you need to approach them with a

bit more caution than simply dividing

the work up into tiny pieces each stored

in its own repository and then having a

big integration phase to try and make

all of these pieces work together later

and a big test phase to verify that they

do. This greater caution is about two

things really. a degree of

sophistication in development approach

and a degree of sophistication in terms

of design. The developmental scalability

of microservices is dependent on our

ability to work autonomously. We need to

be able to easily and safely change them

without depending on other people

outside our team being forced to

coordinate what they're doing with us or

us being forced to coordinate what we do

with them. So we need our changes to be

organizationally and technically

decoupled and isolated. We need to

achieve this by careful

compartmentalization of the problem

dividing them into services but also

abstracting the conversations between

those services so that we can change the

services at either end of the

conversation without changing the nature

of the conversation.

This means that we need to be able to

make such changes confident in our

ability to do so without compromising

the conversations.

Those interfaces between the services

then are important. This means good

design as well as good testing and good

feedback. This is a pretty complex

design problem, but it is fundamental to

making the micros service approach work

well. I wouldn't argue that autonomous

teams with full-blown continuous

delivery, trunkbased development, TDD,

and continuous integration are really

table stakes for microervices approach.

If you don't do these things, then I'd

say you're doing it wrong. In most

cases, I'd add that you also need

contract testing in some shape or form

and strongly recommend a ports and

adapters approach to design to defend

these crucial interface points between

services. You can't sensibly be sure

that your changes are safe and won't

leak breakages to each other without all

of these things. These things are what I

mean by sophistication in development

approach. And this is all complex

enough, but we aren't finished yet. By

definition, microservices are components

in a distributed system. And distributed

system are complex in lots of

interesting ways. Because they are

distributed and so successfully

compartmentalized the system, a

well-designed microervices system can be

easy to scale up in terms of computation

and performance too. We can have more

opportunities to scale services

independently of one another because the

boundaries are obvious. But again, this

depends on thinking carefully about how

we divide up the problem and how we

avoid sharing data between services, how

we avoid all the pitfalls of distributed

system, things like circular chains in

communications distributed

transactions, race conditions. And we

need to think of ways to deal with the

fact that now we're exposed to

deadlocks, resource starvation, and deal

with ideas that are very complicated

like eventual consistency, bulkheading,

data sharding, back pressure, and other

arcane complexities of concurrent

systems. How do we trace paths of

execution and understand or debug

failures? Given all of this, it's not

really surprising that teens that have

not previously been exposed to these

sorts of distributed system challenges

find microervices a lot more complex

than they thought they'd be. So perhaps

it's also not surprising that many

people who have now experienced this

complexity when they expected a much

simpler approach to building these

complex distributed systems have felt

somewhat disillusioned. But I would

certainly recommend pausing before

throwing the idea away completely. This

is really about what are you comparing

it to. The truth is that large

distributed systems are always extremely

complex things. They may be easy to

develop if we get things right, but they

are never simple. I believe that a

distributed service model is probably

the best way to organize live systems.

Generally, it provides a valuable

organizing strategy that gives us some

loose guidelines on how best to arrange

things to limit the impacts of all of

this complexity that we've talked about

inherent in distributed systems. These

loose guidelines are called out in the

original definition of microservices by

James Lewis and Martin Fowler. And if

you're working or intend to work on

systems like these, I recommend that you

read and carefully think about what they

say in that description. There are ideas

here that are important to take

seriously if you're going to succeed.

Microservices is a much more than only

about small services. It's about how

they are divided up and how they

communicate. Here are a few ideas from

that original article and my thoughts on

them to help you to follow the advice in

those loose guidelines that's all too

often ignored. They are based on

componentization via services. If nearly

every change requires the coordination

of work in different groups of people

and changes in multiple services, you

have a problem because now microservices

will make that kind of work more

difficult, not less. One guideline that

helps with this is that microservices

are organized around business

capabilities.

This naturally helps us to divide the

problem into less coupled more

independent pieces separated by clearly

defined abstractions of the

conversations between them. This isn't

easy to do well and one way to help us

to better achieve this is to approach

micro service development as products

not projects. This matters because what

this is really calling out is the vital

importance of an incremental

evolutionary approach to design and

development. You aren't going to get all

of this right first time. So assume that

you'll need to adapt and change things

as you learn more. Use the stuff that I

talk about to make your code easy to

change. That is one of the reasons why

micro is there in the name. By the way,

a good micros service system is composed

of many small simple pieces. The key to

this idea is perhaps rather subtle in

that the communication between the

pieces matters more than the pieces

themselves. This is hinted at, but to my

mind perhaps not clearly enough called

out by the idea of smart endpoints and

dumb pipes. I would add to this that the

real design of a micro service system

comes in the design of the conversations

between the services rather than the

implementation detail of the services

themselves. The implementations at the

smart endpoints are somewhat more

tactical. In part this is because of the

need to achieve decentralized governance

and decentralized data management. The

benefit and major advantage of

microervices is that it is a wholly

decentralized approach. This is true

both in technical terms but even more

importantly if you aim to get to the

real benefits of a microservices

approach in organizational terms. We

decentralize decision making every

autonomous team responsible for its own

small part of the system as a whole.

This comes at a cost of a loss of

standardization because these teams are

working more independently than before,

but at a huge advantage of enabling them

to make progress in parallel without

being constrained by what other people

are doing. And this works for sometimes

very large groups of people. Indeed,

microervices is the most scalable way to

build software, but it's probably a

mistake for small teams. And whatever

the size of the team, it comes with some

significant overheads and demands a

level of sophistication and

thoughtfulness. So don't dismiss it, but

also don't treat it likely as some kind

of silver bullet. Thank you very much

for watching. And if you've watched this

far, thank you for supporting our

channel. And if you'd like to support us

further, why not consider joining our

Patreon community? We have a very active

discord channel where you can discuss

ideas in depth about software

engineering and a wide range of other

topics that we talk about here on the

channel. There's links to how to join

that in the description below. And to

our existing Patreon members, as ever,

thank you very much indeed for your

support. It's very much appreciated.

Bye-bye.

[music]