THE NEW STANDARD FOR BUILDING SCALABLE SOFTWARE?

State of Microservices
2020
Authors _Table of
contents
Patryk Mamczur
Editor in Chief

Tomasz Czechowski
Mateusz Mól Mariusz Nowak
Design of online version Design of print version
Developers
01 669 microservice experts from around the world 06

Maturity
02 Great architecture for solving scalability issues 12

Programming languages
03 JavaScript and TypeScripts rule all 20

Deployment and serverless

04 Microservice developers choose AWS 26

Experts
Repositories
05 Monorepo or multirepo? 32

Varia
Marek Gajda
CTO of The Software House
Adam Polak
Head of Node.js Team 06 Communication, authorisation, message brokers 38
at The Software House

Continuous integration
07
Yan Cui Peter Cooper
Host of Real World The Founder of Cooperpress Microservices + CI = <3 42
Serverless Podcast

Debugging
08
Ewelina Wilkosz Thomas Boltze
IT Consultant at Praqma CTO of Asto Digital
Are logs enough for your project? 48

Sarup Banskota Luca Mezzalira

Consumption of APIs
Head of Growth at ZEIT VP of Architecture at DAZN
09 Is static the future? 54
Richard Rodger
Micro frontends
10
CEO of Voxgig
Time for the microservice revolution on frontend? 60

Future
Published in 2020 Ver. 1.0 11 Microservices – the new backend architecture standard 66
How many IT experts filled
in the survey? Total answers: 669

252
Western Europe
163
Eastern Europe

96
North America
49
South and

23 24
East Asia

Central and Middle East

40 22
South America

Other Australia and

4 New Zealand 5
01 _develo-
pers

669 microservice experts

from around the world

6 7
 Microservice architecture – an architectural style where your application is based
on a collection of fine-grained, interconnected services – is definitely a hot thing
right now. But what are the pros and cons of this architecture? What’s the future
of this trend? Should we all jump on the hype train? Well, to find out, we decided
to create this report.

The goal of the State of Microservices 2020 research project was as straightfor-
ward as it was ambitious. We wanted to find out how developers around the globe
really build their microservices. And if you’re wondering if we succeeded – just
take a look at the map on the previous pages.

Firstly, over 650 software developers decided to take part in our survey. Secondly,
more than a half of these talented folks were CTOs, Lead Developers or Senior
Developers, showing us all how experienced the microservice community is. And,
last but not least, the respondents really came from all around the world, making
the report even more useful and universal than we had wished in the beginning.

However, numbers are just numbers. And this is why we decided to let the voice of
the microservice gurus be heard by inviting the awesome people of DAZN, Coop-
erpress, ZEIT and more to comment on the results. You’ll find their expert opinions
on the following pages.

We wanted to find out So, without further ado, I present you the complete State of Microservices 2020

how developers around

report – the most up-to-date source of information on the state of microservice
architecture.

the globe really build Patryk Mamczur

their microservices. Report’s Editor in Chief

How would you describe your seniority? How big is the company you are working in?

2.2% 3.9%
8.2%
9.4%
31.5% 25.7%
11.1%

14.3%

16.9%

23% 23.6%
30%

Lead developer, Head of technology (211) Chief technology officer (74) 11-50 employees (172) 2-10 employees (96)

Senior developer (201) Junior developer (55) 51-200 employees (158) 201-500 employees (63)

Mid-level developer (113) Others (15) 501+ employees (154) I'm the one-person company (26)

10 11
02 _maturity

Great architecture for

solving scalability issues

12 13
 I must admit that when we were designing the State of Microservices 2020 survey
I had some presumptions. And, when the results arrived, most of my assumptions
were confirmed – however, both the positive and the negative ones.

In my opinion, the two most important topics when it comes to microservices are:
improving scalability and improving performance. All in all, that’s why the idea of
microservice architecture was dreamt up in the first place, wasn’t it? Fortunately, it
seems that software developers around the world are truly happy about building
microservices when it comes to solving scalability issues (average rating: 4.3 out
of 5) and performance issues (average rating: 3.9). It’s even more evident when
you look at the responses of CTOs – who should hold the most informed view
when it comes to such issues – and who rated the scalability potential to 4.4 and
the performance potential to 4.3.

On the other hand, it seems that maintenance and debugging are a bit of a prob-
lem for many microservice developers. Speaking from my professional experience
at The Software House, I must confirm that these findings are true. For the last
2 or 3 years, more and more clients have approached us and asked us for help
because their in-house development teams lost control over microservice-based
projects. Usually, after some hussle, everything can be straightened out but my
protip for you is: hire an experienced DevOps engineer at the very beginning of
your microservice project. These guys can do real magic when it comes to fu-
ture-oriented thinking and planning out your whole system’s architecture.

The two most important All in all, microservice architecture is not a cure for all of your software problems.

topics when it comes

If you think that you can run a short-term microservice project without previous
experience, you’re probably wrong. However, if your business is based on scala-

to microservices
bility and you take a minute to plan out the software architecture in the very be-
ginning of a project – you’ll definitely see the benefits of microservices.

are scalability and Marek Gajda

performance. CTO of The Software House

For how long have you been Rate in scale 1–5 (where 1 means the worst, and 5 means the best
possible experience) how you enjoy working with microservices
using microservices? when it comes to…

7.5% Setting up new project Avg. 3.8

250 36%
31.2% 200 29%
17.5% 24.2%
150

100

50 6.7%
4%

18.4%

Maintenance and debugging Avg. 3.4

250

32.7%
30.8%
25.4%
200

150

100
16.4% 15.4%
More than 1 year (209) Less than 6 months (117)
50
More than 3 years (170) More than 5 years (50) 4.6%
6 months - 1 year (123) 0

16 17
Rate in scale 1–5 (where 1 means the worst, and 5 means the best
possible experience) how you enjoy working with microservices
when it comes to…

Efficiency of work Avg. 3.9 Solving performance issues Avg. 3.9

250 41.7% 250

33.8% 32.9%
200 200
26.9%
28.4%
150 150
22.7%
100 100

50 50
5.4% 5.1%
1.8% 1.3%
0 0

Solving scalability issues Avg. 4.3 Teamwork Avg. 3.9

350
49.2% 250
33.9% 33.9%
300 200

33.8% 23.9%
200 150

100 13.2% 100

50 50
6.3%
1.2% 2.7% 1.9%
0 0

18 19
03 _program-
ming langu-
ages

JavaScript and TypeScript

rule all

20 21
 To be honest, when I first saw the results of this part of the survey, I was pretty
surprised. I knew that JavaScript and TypeScript were getting more and popular
– but was it really possible that those were the main programming languages for
almost 2⁄3 of microservice developers? Well, it certainly seems so!

For a pretty long time, microservice architecture has been associated with huge,
enterprise solutions. And those were usually built using Java or .Net. However, it
seems that things are changing pretty rapidly. Firstly, more and more people are
talking about Universal JavaScript and how this language (both with TypeScript) is
gaining popularity. Secondly, developers start building microservices not only for
enterprise-grade platforms but also for medium-size software projects. Thirdly,
the “microservices plus serverless” model is also on the rise and we all know that
JavaScript and TypeScript go pretty well with serverless.

The results of our State of Microservices 2020 survey confirm all of these trends.
437 people (65%) named JavaScript/TypeScript one of their architecture’s main
technologies. And 171 of them (26%) chose JS/TS as the ONLY programming lan-
guage for their microservices.

Whether you like this trend or not, one must say that microservices and JavaScript/
TypeScript go very well together. Before the era of workers, Node.js architecture
was very prone to slowdowns, so Node.js developers simply had to learn how to
work with multiple small services.

Microservices and
Now, it’s a part of their developer’s DNA – and it makes building and maintaining
microservice architecture whole lotta easier.

JavaScript/TypeScript go Adam Polak

very well together. Head of Node.js Team at The Software House

What are your architecture’s JavaScript/
TypeScript (437) .Net (115) PHP (100) Ruby (19)

main technologies
Java (176) Python (110) Go (99) Other (47)

450
65.3% 450

400 400

350 350

300 300

250 250

200 200

26.3%
150 150

17.2% 16.4%
100
14.9% 14.8% 100

50
7% 50

2.8%
0 0

24 25
04 _deploy-
ment and
serverless

Microservice developers
choose AWS

26 27
 When I look at the results of the survey, I see that the market of cloud providers and
serverless is thriving – there are as many obvious findings as there are surprises.

Quite unsurprisingly, AWS is the most popular (49%) deployment target, and most
people are using Kubernetes (65%) for service discovery. What is surprising, howev-
er, is that 34% of respondents are running on-prem, which is as much as Azure (17%)
and GCP (17%) combined! I guess that when you're in the cloud bubble, it's easy to
forget that traditional DCs is still a $200B market annually and accounts for as much
IT spending as all the cloud providers combined.

I'm pleased to see that nearly half the respondents said they're already using
serverless technologies. Here, once again, AWS Lambda is the clear leader with 62%
of the responses. I did, however, expect to see Azure functions (13%) faring better
than Google Cloud Functions (14%) – given that GCP is still focused on their contain-
er services and has largely neglected Google Cloud Functions. Perhaps the num-
bers have been helped by Firebase, which has a strong user base and does have a
good developer story with Firebase functions.

I’m pleased to see All in all, while we can definitely see that Amazon Web Services are leading when it

that nearly half of

comes to cloud and serverless, the situation is still far from a monopoly. With other
providers reaching for their piece of cake, and with bare-metal servers grabbing

the developers are

a huge market share, one thing is certain – when you’re a microservice developer,
there’s plenty of options for you to choose from.

already using serverless Yan Cui

technologies. Host of Real World Serverless Podcast

Where do you usually deploy your Which serverless solution is your
microservices to? preferred one?
350 4.5%
49.9% 5.7%
300

34.2% AWS Lambda (207)

200
13.5%
Google Functions (48)
100
17.2% 17.2%
Azure Functions (45)
50
8.1% 14.4%
ZEIT Now (19)

0
Amazon Web My own Azure (115) Google Cloud Other (54)
Other (15) 62%
Services (334) server (229) Platform (115)

Do you use serverless technology? Do you use AWS Serverless

Application Model?

49.9% 26%

No (335) No (247)

Yes (334) 50.1% Yes (87) 74%

30 31
05 _reposito-
ries

Monorepo or multirepo?

32 33
 It's not a big surprise that the majority of respondents say that they prefer using
multiple repositories for their projects – that's been the status quo for years now.
It's more interesting, however, that as many as 32.9% said they DO prefer monore-
pos. And this number is sure to grow.

The monorepo approach to software development involves storing the files for
numerous projects within a single repository (that's internally segregated in some
way, usually through folder structure). One company well known for adopting
this approach is Google. With the majority of their code residing within a single
monolithic repository, they can take advantage of easier code reuse across the
company and easier integration with their company-wide Continuous Integration
systems. Other companies using monorepos, at least to some extent, are Micro-
soft, Facebook, Digital Ocean, Twitter, and Uber. On the other hand, the monorepo
approach is still broadly considered cutting-edge or experimental in smaller com-
panies and in single developer cases. To be honest, it’s not that surprising, as the
approach's main advantages are around teamwork and integration.

I expect to see
However, much like the almost universal growth of CI (after initially being more
popular within larger companies and teams), I'd expect to see significant growth

significant growth for

for monorepo use outside of its core user base over the next couple of years too.
Especially, as more tools emerge that target smaller use cases.

monorepo use over the Peter Cooper

next couple of years. The Founder of Cooperpress

How do you like your code stored? Multiple
repositories (446) Monorepo (220) Other (3)

0.4%

32.9% 66.7%

36 37
06 _varia

Communication,
authorisation, message
brokers
38 39
How do your microservices Do you use message brokers?
communicate with each other?
600

76.8%
500
36.9%
400

43.9%
300

200
13.5%
9.4%
5.7% No (247)

0
Http (514) Events (294) gRPC (90) WebSockets (63) Other (38)
Yes (442) 63.1%

How do you take care Which message-broker

of authorisation? software do you prefer?
3%
36.7% 18.2%
39.5%
RabbitMQ (155)
4.7%
Kafka (104)

Only the gateway API

Redis (66)
authorises the request (385)

Each system authorises

Nats (20)
15.6%
the request (264)

Other (20) 57.5% Other (77) 24.6%

40 41
07 _continuous
integration

Microservices + CI = <3

42 43
 It’s fantastic to see that almost 87% respondents use Continuous Integration. It’s
fair to say that CI is quickly becoming a standard – at least among the developers
who build microservices. However, I can’t stop wondering: what is the rest doing?
13% is a pretty significant number! So, the need to educate and help developers to
understand the topic is still there.

What makes me genuinely happy, are the results regarding the most popular CI
solutions. Frankly, I did expect Jenkins to have a bit bigger share, but the fact is
that the industry is changing and it is great to see that there is a diversity in the
area. Especially, as many of these CI solutions are available “out-of-the box”, pro-
vided to you alongside a repository or a cloud solution. In practice, it means that
running pipelines is now easier than ever before – and, judging by the numbers,
it is working really well.

Having so many options to choose from might also impact the way the CI pipe-

It’s fair to say that

lines are built. Nowadays, it makes a lot of sense to put an effort into writing a
pipeline in a smart way, so it is easy to migrate to another solution if need be. Of

Continuous Integration
course, that requires a bit more attention at the beginning of the process, but it
gives you bigger freedom and might be very rewarding in the future.

is quickly becoming CI/CD is an important aspect of the software development process and it can

a standard – at least
bring many benefits to those who use it. Having a variety of well-working solutions
and good practices to choose from is a luxurious situation for all of us.

among the microservice Ewelina Wilkosz

developers. IT Consultant at Praqma

Do you use Continuous Integration? Which CI solution do you prefer?

180

13.3% 160

25%
140

120

100

80 13.4% 13.3%
12.6% 12.4%

10.5%
60

86.7% 40 6.6% 6.2%

20
Yes (580)

No (89)
0

GitLab CI Jenkins GitHub Circle CI Bitbucket Travis CI Azure Other

(145) (78) Actions (73) Pipelines (38) DevOps/ (61)
(77) (72) Pipelines
(36)

46 47
08 _debugging

Are logs enough for

your project?

48 49
 For me, as the Chief Technology Officer, the survey results regarding debugging
solutions were particularly interesting. The thing that immediately captured my
attention was that the most popular debugging solution, with as much as 86% of
developers choosing this answer, were… logs.

It shouldn’t be that alarming, as it was a multiple-choice question. However, when

getting deeper, we can see that as much as 179 respondents (27%) use ONLY logs.
Knowing that logs definitely don’t show you everything, it poses quite a problem.
In yet another question – where we asked people how would they rate build-
ing microservices when it comes to various areas of software development (see:
Chapter 2. Maturity) – maintenance and debugging were voted the most prob-
lematic areas. These two pieces of information correspond very well.

Sadly, it’s also consistent with my personal observations. In general, I find that de-
velopment teams often struggle with two things: predicting the consequences of
going all-in with the microservices, and getting the scope of a service right. First-
ly, people start buuilding services, but forget about fault tolerance, permissions,
monitoring, etc. Secondly, they often tend to go overboard, making the services
super small before they have anything in place to manage that effectively – and
then wonder why failure modes are taking over, try to do distributed transactions,
and generally end up in some form of misery.

Development teams Microservice architecture is a great invention and I must say we benefit from it a

struggle with predicting

lot at Asto Digital. However, before developing microservices-based software, you
must think about the future and prepare for maintenance beforehand. Starting to

the consequences
care about debugging in the middle of the development process – when things
finally “go south” – is simply too late.

of going all-in with Thomas Boltze

microservices. CTO of Asto Digital

What are your favourite Logs (575) Metrics (193) Other (10)

debugging solutions?
Tracing (229) Health checks (110)

600 600

85.9%
500 500

400 400

300 300

34.2%
28.8%
200 200

100
16.4% 100

1.5%
0 0

52 53
09 _con-
sumption of
APIs

Is static the future?

54 55
 The findings in the report regarding the consumption of APIs are consistent with
the industry trends we've been noticing here at ZEIT. Consumers today are more
impatient than ever, demanding top-notch performance from the applications
they use.

Personally, I’m particularly interested in JAMstack-powered (static) sites, which

57.5% of the survey respondents are developing. Static sites are a great choice for
modern web apps. They can be aggressively cached, and served with minimal la-
tency via Edge networks. Thanks to the proliferation of API-based solutions span-
ning every aspect of development, businesses can focus on building core features,
testing variations, and ultimately serving their customers better.

Consumers today are

Going static allows rapid iteration, top-notch client performance, vastly reduced
development and hosting costs, zero-downtime, faster builds – there is little room

more impatient than

to complain! With a technology stack like Next.js and ZEIT, developers are able to
elevate their Git-based workflow to a Deploy–Preview–Ship workflow, unlocking

ever, demanding top-

all the benefits of working with static in one neat package.

notch performance
Thanks to integrations with GitHub, BitBucket, GitLab, and Slack – the adoption is
only increasing among remote teams. We're incredibly excited for the future.

from the applications Sarup Banskota

they use. Head of Growth at ZEIT

How are you consuming the responses of Service
to service (446)
Mobile
apps (225)
Other (22)

your microservices? Static SSR

frontend (385) frontend (175)

450
66.7% 450

57.5%
400 400

350 350

300 33.6% 300

26.2%
200 200

100 100

3.3%
0 0

58 59
10 _micro
frontends

Time for the microservice

revolution on frontend?

60 61
 I don’t expect the percentage of developers using micro frontends to grow far more
than the 24% that we see in the results of the survey. However, it doesn’t mean that
there’s no place for the microservice revolution on frontend. Quite the contrary.

The main problem when it comes to micro frontends is that this technology is just
starting to get traction and people aren’t really familiar with it – which gives rise to
lots of misconceptions. For example, people believe that assembling multiple micro
frontends in the same view, using a few different frameworks, may lead to an app
that weighs 10 MB instead of 100 KB. Well, yeah, you can do it – just as you could do,
technically speaking, with a single page application – but obviously it won’t work
well.

That’s why, some time ago, I’ve decided to debunk these myths and spread the
knowledge regarding micro frontends. The fact is that applications tend to get more
complicated on frontend, so you can’t always use the same pattern. So far, we’ve
usually built either a single page application (SPA) or one based on server-side
rendering. Now, there’s the need for a third option – a paradigm that allows you to
scale up by breaking your interface into separate features developed by separate
teams. That’s the micro frontend pattern.

This paradigm allows I discourage people from using micro frontends in new projects without under-
standing the business and organizational challenges which are there to solve.

you to scale up by That’s because when deciding to use micro frontends, you need to invest resources
in creating the automation pipeline, in designing proper communication, in taking

breaking interface care of governance, etc. However, if you believe that the frontend of your app needs
to be ready for scaling up, micro frontends are definitely something you should get

into separate features to know better.

developed by separate Luca Mezzalira

teams.
VP of Architecture at DAZN
The author of “Building Micro-Frontends”
Have you used micro frontends? How do you compose your micro frontends?

5%
8.2%
36.5%
23.8%

23.9%

76.2% 26.4%

No (510) Web components (58) iFrame (13)

Yes (159) Server-side rendering (42) Other (8)

Micro frontends as npm packages (38)

64 65
11 _future

Microservices – the new

backend architecture
standard
66 67
 The great benefit of the microservices architecture, and the reason why it will dom-
inate the future of software development, is that it provides a practical component
architecture. In my own work building such systems, two core principles keep com-
ing up, and their effectiveness in practice remains the reason why I believe micros-
ervices are the future: the basic principle of independent components exchanging
messages, and the dynamic routing of those messages.

The first, transport independence, means simply that how messages are transferred,
is quite irrelevant. I mean this up to the level of the messaging model – synchronous
or asynchronous, it really doesn’t matter. What does matter, is that messages are
the only interface. This reduces the component integration surface drastically, and
enables composition – the most important attribute of a component model.

And the second principle is zero identity. Microservices and components must not
know about each other. Messages are simply sent and received with no thought
for destination. This approach provides the dynamic ongoing modification of live
systems. Sadly, many implementations that I see in the wild still rely on concepts of
identity embedded within services – this is the single greatest mistake that leads to
most of the microservice horror stories.

However, with these two principles – which will become almost invisible features of
the microservice substrate – we will see the term “microservices” virtually evapo-
rate, and that means they will truly have become the primary architecture of soft-

We will see the term ware development.

“microservices” virtually Richard Rodger

evaporate.
CEO of Voxgig
Author of “The Tao of Microservices”
What do you think about the future of It will be a standard but only for more
complex systems (330)

microservice architecture? It will become the industry standard for

backend development (242)

It will be completely dethroned by some

new architectural solution (49)

2.7% It will end up as a curiosity used only by

a group of fanatic developers (30)

4.5%
Other (18)

7.3%

49.3%

36.2%
70 71
Software development
has changed for good
We help tech managers who understand this change
and want to make the most of it

Tech stack Microservice

migration architecture

Cloud migration, Modern

serverless real-time frontend

Find out how we can help you:

www.tsh.io