
A pattern language for microservices - exploreshaifali
http://microservices.io/patterns/
======
friendly_chap
I have been doing microservices for 4 years now and I can tell you something:
do not go there. The tools are simply not there.

Although I am working on one platform like that right now (see
[https://github.com/1backend/1backend](https://github.com/1backend/1backend))
the reason I started it was more the fact that I could not easily deploy a
custom tiny service and call it easily.

We have solved both problem with 1Backend: launching a new service is as easy
as creating a git repo on GitHub, and calling them is just like calling a
library with the autogenerated clients.

That being said, until a project like 1Backend matures, anyone who starts
their startup on a microservices architecture instead of a simple monolitic
one is out of their skull.*

I have personally watched millions and millions of dollars burnt on building
on such platform while our competitor (Uber) became one of the biggest
unicorns the world has ever seen.

Don't be that startup! We managed to screw it up with 100+ million dollars in
funding, which was (is) extremely exceptional in Europe. Of course the tech
was only part of the reason for failure, still: there are better way of
spending money than chasing bugs across hundreds of services and building
instrumentation.

*Edit: this sentence of mine was very unfortunately worded and said the exact opposite of what I meant. Hopefully the tons of upvotes I got was because that the upvoters correctly inferred from the context that I advice you to start with a monolith, and not with microservices. Thanks.

~~~
je42
it depends on your reasons.

\- if you need to scale the number of teams working on the same product you
need to introduce microservices to make the teams work independently from each
other.

\- if you need to scale the (monolith) service and it is too expensive to just
scale it n times. microservices can help because you can scale each
microservice independently.

\- that's said the overhead is real. There have been quite a few publications
and advocates (like Randy Shoup) that staying monolith is fine until you have
pain that a microservice architecture can ease.

~~~
marcosdumay
> if you need to scale the number of teams working on the same product

You can do that by several different ways. Overall, if one wants a "one size
fits all" answer to how to break code into teams, it is by breaking the code
into libraries, not services. Services are a niche tech here, to be considered
when the others won't suffice.

> if you need to scale the (monolith) service and it is too expensive to just
> scale it n times.

Again, nearly every time this happens, the correct answer is to refactor the
monolith so replicating it scales. Services are only for those cases where
this won't suffice.

I don't think I disagree with how you think. But I do think your comment is
easily misunderstood and harmful without those qualifiers.

~~~
philwelch
I’ve seen the library approach in practice. It is works to a certain point,
but it isn’t too long until having a single deployable[1] artifact becomes as
much of a bottleneck as having a single codebase, if not more. Taking this
approach makes it harder to do other things that are just as important, such
as continuous delivery, empowering development teams to take ownership of
operational excellence, or even ship updates in a reliable and timely fashion.

Most of the hatred towards microservices is probably better directed at REST,
which is a good paradigm for serving documents to web browsers but is
overcomplicated for microservices. RPC is a good alternative, and gRPC is a
good implementation of it.

[1] My phone autocorrected this to “deplorable”, which is also a good
adjective for a monolithic web application that contains lots of libraries and
is only deployable as one artifact.

------
stingraycharles
Having done "microservices" for more than a decade, I think most of these
patterns are horribly overengineered or incomplete. As with the GoF design
patterns, it's almost always a bad idea to implement these patterns as-is.

Rather, look at these patterns as solutions for problems that worked for other
people, and try to adapt that to your own situation. You're almost certainly
going to come up with something more simple and reliable in the process.

~~~
hliyan
I was just about to make the exact same comment. As principles, even the GoF
patterns are fine -- a lot of good engineers independently derive and use
those patterns without ever knowing their names. Problems arise when engineers
who don't understand the principle somehow match a pattern to a problem they
have an implement it literally, right down to naming classes after patterns.
That's not what patterns are for.

~~~
codeflo
How do you name your classes instead? I ask because I'm now mostly in favor of
naming classes after the patterns, at least when there's no relevant term from
the domain to use. That is, when the alternative is to invent a _new_ abstract
name, I think it's better to use the one that comes with the design pattern.
The resulting names are often ugly, but at least they clearly communicate the
intent to people also familiar with the pattern.

~~~
hliyan
If there's no relevant term from the domain, that's an indication (at least
for me) that the class hierarchy is wrong. I've been programming for 15 years
and I've never found myself without a proper domain-oriented name for a
class...

------
mpweiher
I converted a set of quasi micro services to a monolith 14 years ago, and the
results were incredible in the truest word: you probably won't believe them.

100-1000x better performance, 10x reduction in machines used, ~100x reduction
in number of processes, >100x improvement in reliability, deployment changed
from "oh my god" to "copy this jar here", output improved, quality improved,
development times improved etc.

[https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...](https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_11)

There _can_ be good reasons for microservices. There rarely _are_. The Fred
George piece that (I think) introduced micro services as a distinct concept
specifically pointed out that they must be independent, that is, if one of the
services fails you don't get that one service and that's it. Almost all real-
world instances either fudge this or just blatantly disregard it.

------
andrewflnr
It's interesting to contrast the distaste and horror for microservices in this
thread with the respect commonly shown for Erlang and similar systems.

Isn't an erlang actor basically a microservice, or perhaps nanoservice? Is the
difference simply that the Erlang runtime takes care of logistical issues like
addressing, marshalling, and deployment that are big time sinks in a "normal"
microservice architecture?

------
ChrisRus
The more you look at microservices, the more you'll appreciate basic TTL logic
design with buffers, blocks, latches, and sequential logic. I wrote a paper
about this subject a long time ago. Everything I've seen since further
convinces me that this is the path forward for software.

[http://blog.encapsule.org/early-encapsule-project-
history/20...](http://blog.encapsule.org/early-encapsule-project-
history/2003-encapsule-aurora-platform-whitepaper/)

~~~
0x445442
Do you see change management as a problem with the state of current runtimes?
If so, how do envision this issue being solved? I know there's been attempts
with things like OSGI but that sort of failed.

------
romaniv
I'm watching some OOP videos from mid-eighties right now. Can't shake the
feeling that the original notion of OOP was solving the same problems as
microservices try to solve today, but with far more elegance and more coherent
theoretical framework.

(Example:
[https://www.youtube.com/watch?v=QjJaFG63Hlo](https://www.youtube.com/watch?v=QjJaFG63Hlo))

~~~
eeZah7Ux
Spot on. Objects were meant to be close to microservices, although with the
limitation of being implemented in the same language. RPC was meant to allow
objects running on different hosts send messages to each other.

That, before OOP turned into the
ConfigurationParserSecureProviderCollectorGeneratorFactoryFactoryFactory
disaster.

~~~
romaniv
Interestingly, it seems RPC was one of those older ideas that was resurrected
and replaced remote message passing when Smalltalk was phased out.

Alan Kay on RPC: _" The people who liked objects as non-data were smaller in
number, and included myself, Carl Hewitt, Dave Reed and a few others – pretty
much all of this group were from the ARPA community and were involved in one
way or another with the design of ARPAnet->Internet in which the basic unit of
computation was a whole computer. But just to show how stubbornly an idea can
hang on, all through the seventies and eighties, there were many people who
tried to get by with “Remote Procedure Call” instead of thinking about objects
and messages. Sic transit gloria mundi."_

Source: [http://mythz.servicestack.net/blog/2013/02/27/the-deep-
insig...](http://mythz.servicestack.net/blog/2013/02/27/the-deep-insights-of-
alan-kay/)

------
konschubert
I don't like it when I open a technical website and the first thing I see is
the bio of some guy and his picture

Makes me feel like this is about content marketing more than about defining a
standard.

------
jpalomaki
I see similar issues here as with big data tools and NoSQL. We read how
companies like Netflix and Uber are doing things and take advice. Yet they are
operating on completely different scale than most other business.

Preparing to scale may be good, but those technical choices tend to add their
own complexities (as random example, see the Saga pattern [1]). Need to think
if you should be building platform that can manage 10M active users or is it
more important to add features that get you the first 100.

Couple of days ago there was a discussion on HN about Instagram. Somebody
pointed out why they went with Python instead of something more suitable for
large codebase. This seems to be quite common theme - companies who made it
big facing growing pains because of doing things "quick and dirty". This led
me thinking if this "let's get it running and worry about growth later"
thinking is the reason why they outperformed their competition.

[1]
[http://microservices.io/patterns/data/saga.html](http://microservices.io/patterns/data/saga.html)

~~~
cottonseed
Relevant: You Are Not Google [1]

[1] [https://blog.bradfieldcs.com/you-are-not-
google-84912cf44afb](https://blog.bradfieldcs.com/you-are-not-
google-84912cf44afb)

------
matchagaucho
It's amazing how many service-oriented projects continue to add basic patterns
like security, observability, and reliability after the fact.

This looks like a great set of templates for setting the tone and expectations
on a project. Will definitely use.

------
he0001
I don’t understand the microservice hype. To me it seems like you are trying
to solve something that, at least for me, were never a problem. However when
people have been trying to solve that problem a lot of nice tools have
emerged, and that’s a good thing. But most of the supporters I’ve spoken with
seem, to me at least, base their ideas and beliefs from having a poor eco
system/platform or structural inabilities and tries to solve that with
breaking things apart.

~~~
cc81
It is most likely solving a real problem at Netflix.

Most people don't work at a company like Netflix though.

------
vadimberman
Sorry, is this in the same vein as GraphQL or SOQL of SalesForce.com?

~~~
camus2
Nah, looks like another iteration of UML.

~~~
platz
"no design necessary" kind of folk, eh?

~~~
ex_amazon_sde
Proper design has little to do with drawing hundreds of little boxes and
arrows.

I've seen a lot of horrible designs bundled with visio diagrams made by
"architects" and good designs described in a txt file made by system
engineers.

~~~
Terr_
Cargo Cult, "Design" edition. Take a bad idea chosen for unclear reasons and
then detail the heck out of it.

------
1_2__4
A lot of hate for microservices in this thread. I think you’d be surprised how
much some major tech companies (Google etc.) are and have been relying on
microservices and that style of architecture for many years now.

I think the biggest conflict here is scale of the services involved. For
smaller scale - which is what most people are familiar with - monolithic
architecture can offer distinct advantages. At scale though? Monoliths have
been relentlessly excised for years because of all the very real scaling and
maintenance problems that go with them.

~~~
mcphage
> I think you’d be surprised how much some major tech companies (Google etc.)
> are and have been relying on microservices and that style of architecture
> for many years now. [...] I think the biggest conflict here is scale of the
> services involved.

I wouldn't be surprised that Google, Microsoft, Amazon, Facebook, Apple, etc.
use microservices heavily.

But I think it's more, the scale of the companies, rather than the scale of
the services. When you've got a lot of developers—thousands or tens of
thousands, on hundreds of teams—having independent microservices is surely the
way to go.

But, when you're a small company, with ~10 developers? It's not.

~~~
xab9
Yep, last time I worked at a company w around 13 devs, everything had to be
done "the microservice way", because all the cool guys are doing it and it is
the way to go.

Microservices is the new snake oil :D Now downvote me into oblivion :)

~~~
mcphage
> Microservices is the new snake oil :D Now downvote me into oblivion :)

Downvotes definitely won't be coming from me :-)

