
Microservices – Please, don’t - JensRantil
https://blog.komand.com/microservices-please-dont
======
agravier
Past discussion:
[https://news.ycombinator.com/item?id=12508655](https://news.ycombinator.com/item?id=12508655)

------
mightybyte
I would like to propose a new variant on an old maxim: Premature microservice-
izing is the root of all evil.

I've worked with an app that had been factored into half a dozen
microservices. Each of these needed two EC2 instances for redundancy. They
weren't using docker or any other container infrastructure and were treating
EC2 instances as pets instead of cattle, which meant that a LOT of effort was
spent maintaining the dozen or so instances. Each of these instances was
running at < 1% load average! So in this case the microservice architecture
was also costing a significant amount of money.

My takeaway: don't build an app from scratch using microservices, especially
if all you're splitting apart is web handling which is almost never going to
be where your application spends a significant amount of time. Instead, build
apps in the straightforward monolithic way, and only split things out into
microservices when there is a very clear reason that has been identified from
performance monitoring or some other metric gathering.

~~~
mr337
"and were treating EC2 instances as pets instead of cattle"

There is sooo much truth to this statement. Never be afraid to put down an
instance, and if so your doing it wrong!

~~~
hueving
Where do you store your data? Would you be able to terminate all of your
instances and not lose data?

------
kozikow
1\. X that is a good idea for solving problem P appears on the tech scene

2\. People who have problem P pick up X and say good things about X

3\. People, usually junior devs, read blog post about X. They start treating X
as solution to every problem they encounter and ofter take it to the extreme.

4\. After realizing it's not helping, they blame X and write posts like this.

You can replace X by many things, starting from methodologies like
microservices or TDD, ending on things like nosql databases.

~~~
aikah
Enough with that bullshit.

> junior devs

mostly don't make architectural decisions. It's a bit easy to keep on blaming
"junior devs". Who keeps on hyping up and marketing useless stuffs ? that's
not "junior devs", that's big consultancies that want to sell their crappy
services, that's PAAS that want to sell more servers, that's vendors that want
to sell more useless stuff. Enough with blaming "junior devs". Junior devs
don't lead teams and have very little say when it comes to architectural
choices, they don't contract this or that consultancy, they don't decide
whether a business will run on Amazon or Azure. Junior devs didn't invent
NoSQL, Microservices, "Serveless" and all that bullshit. Well established
players sell these services to others, and the people who drink the kool-aid
are managers, not junior devs.

Do you really think "junior devs" want to maintain 50 micro servers just
because it's trendy? when they could get away with a single one?

~~~
sotojuan
Heh, you describe me exactly. I'm "junior"-ish and the second to last place I
worked at was microservice, a ton of Docker, _and_ MongoDB. Definitely wished
we had a simple monolith with Postgres instead.

~~~
Thaxll
Yes because on HN Postgres is the "god" DB, In the real world MySQL / Mongodb
don't suck.

~~~
lcarlson
Postgres is pretty awesome though. :)

------
msoad
I'm living the Microservices nightmare every day at work! Every single
function is a service and you have to run 40 docker containers to get
something show up in your browser!

If there is an issue in one those services it takes a long time to figure out
which service was it and why it wasn't throwing a 500 error. Even if they
throw 500 status codes you still don't get the nice line number and stack
trace in a large application gives you.

I think the whole microservices thing is a mistake, I as a developer should
not care how this application is running in production. I want to work on a
large app and leave the deployment business to someone else. I get it that
it's hard to scale a big application but it shouldn't be my concern.

I miss the old .NET days where I could run the app on my machine...

~~~
PerfectElement
Those days are not gone. Outside of the HN bubble there's still a lot of
successful monolithic application development going on. Not every project
needs to scale to the size of Twitter.

~~~
threeseed
From what I've seen it's about 50/50 these days. Most of the monolithic
applications still around are legacy J2EE or Ruby on Rails.

People seem to forget that microservices isn't new. It's just SOA all over
again.

~~~
rpeden
I believe that a huge amount of SOA in production wouldn't qualify as
microservices - _especially_ enterprise SOA.

Heck, I'd bet a lot of enterprise SOA is just a giant crufty monolith with a
bunch of its functionality exposed via service endpoints. I suppose that a
pretty decent approach - add endpoints to a monolith. As long as the service
interfaces remain the same, you can bust it up into as many medium or micro
sized services as are necessary on the back end and the users of your services
won't notice the difference.

------
Animats
Microservices are useful when there's inherent isolation between the data used
by each service. If they talk to totally different databases, and you don't
have to do atomic updates across service boundaries, why not?

Our DARPA Grand Challenge vehicle in 2005 was all microservices. There were
tasks for each sensor, a location task which integrated AHRS, GPS, and map
data into "where are we now", a steering task, and a planning task which took
in the sensor data, built a local point cloud map, and issued steering
commands. There was also an emergency stop task monitoring the radar and able
to stop the vehicle if it detected an incipient collision, independent of the
mapping systems. The non-hardware tasks could be run separately, or in a
simulator, and we could tap in at a boundary and log.

This was all QNX, hard real time. This part of the system worked quite well.

Synchronization was unusual, in that the sensor data all came in at different
times depending on the sensor. So we timestamped everything at the millisecond
level, and interpolated between sensor frames to get values for all sensors at
the same instant. The overall update rate for planning was 100ms, rather slow
by modern standards.

------
rpeden
As the author mentions, it's not that microservices are necessarily bad - just
that they're too often used when they're not the appropriate solution for the
problem at hand.

I feel as though about 80% of the programming blog posts that breathlessly
pontificate about why everything you're doing is wrong and what you should be
doing instead would all be better if replaced by a phrase along the lines of
"understand the problem you're trying to solve, understand the possible
solutions at hand, and pick the one most appropriate for your problem and your
circumstances."

Instead, we often see dev teams chasing off after the newest and shiniest
options available. And sometimes, the newest and shiniest option is the best
one, which is great! But often, it's a far from optimal. However, in an
industry where so many companies hire largely on the basis of buzzword
compliance, I really don't blame developers at all for choosing the new, hot,
and shiny solutions over proven solutions that are better solutions for a wide
class of problems.

~~~
sotojuan
If there was ever an uBlock for the brain, the first thing I'd block would be
programming blog posts. Sure, I'll miss a ton of good ones (which I can
whitelist!), but they're really not worth the investment.

------
quantumhobbit
I believe that in order to be effective an engineer should be able to run the
whole application stack on his/her laptop. Microservices seem attractive
because each microservice is easier to setup and hack on than on a huge
monolith application, but you don't know that it is working until it is
integrated with all the other microservices. Thus I end up having to deploy a
dozen applications to ensure that my feature is working.

In theory you could avoid the integration hassle if each service is so well
defined and "loosely coupled" that I can be assured it will work without
having to test with all the other services, but in practice the architecture
is never that well defined.

~~~
zepolen
Sure, run all of Google on your laptop.

------
stevesun21
Microservice architecture is more about business modelling rather than the way
how your coding functions.

I think if someone would dislike microservice if they don't understand the
following points very well: 1: The business model of the system you are
working on. 2: how to design/develop business models – write a bunch of CURD
services on top of database doesn't count. 3: define business boundary is far
more important than you think, especially you are working on some projects for
computerizing real world business operations.

Strongly recommend reading Domain-Driven Design book.

------
spotman
Oh microservices. Here we go again.

Yes, it's easy to get burned. Yes, it's often the absolute wrong tool for the
job as a young startup. Further, its all too easy to just light cash on fire
once you get some real serious traffic hitting all these things that may
autoscale individually. We have seen it all before, and we will see it again.

But don't throw the baby out with the bath water. In fact, I think the
healthiest approach is to drop the "micro" and think of classic Service
Oriented Architecture (SOA).

When you hire your 50th engineer, and you don't have this yet, its not the end
of the world, but slowly moving from a monolith to a SOA, is pretty much a
very well travelled path, and at a certain scale is how you maintain sanity.

It's like the old saying, the first code you write is never the best. Try the
2nd or 3rd rewrite, and you finally know what you want. So start with a
monolith, but don't back yourself into a corner, and move one obvious service
out at time.

The main benefits are not even what the article gripes about. It is
compartmentalization between teams, and honoring stable internal functionality
between teams that it makes the biggest difference. Sure scaling CAN be
easier, but it can also be harder. Things like managing connection pooling
becomes easier with an SOA. But not to the tune of doing it concurrently
across 40 services, that is irresponsible to design without knowing exactly
how they are all going to get hit when you finally get insane traffic.

One thing the author said that I agree should be more obvious to people is
that somewhere in-between hiring engineer 12 and 50, you will end up running
your monolith a bit like an SOA, where even if its the same codebase, you can
run in different clusters/pools and service a specific part of the
application. This is a wonderful way to get the benefits of SOA, with out the
nightmare, furthermore, you will quickly learn which of the parts of code,
when your rewriting it the 2nd time, you actually want to divorce from the
monolith, and you already have patterns, load balancers, and metrics for what
that code should do.

When you hire your 200th engineer, it's easy to get on HN and say SOA is the
only way to get the job done. But people need to realize the importance of the
journey of getting there. Otherwise your just taking a shotgun to the
skateboard your cruising down the road with.

Sanity is the key takeaway. Always optimize for sanity.

~~~
partycoder
Doesn't depend on number of rewrites or number of engineers.

It's an approach to organizing the responsibilities of a code module, and
abstracting implementation details such as what technology stack is
implemented in, what operating system is running on, etc.

By making services depend on each other through a protocol like REST (or
Thrift, gRPC or whatever), you can then replace that module by another one
that respects the same interface... and you can reimplement it in whatever
technology you want. I can have a module implemented on Elixir running on
FreeBSD talking to another one running on OpenBSD implemented on C, talking to
another one running on Linux implemented in node.js...

Similar to SOA, but SOA was much broader in scope. You had service
composability, discoverability, etc. That's in most cases overkill for most
companies.

~~~
spotman
You say:

> By making services depend on each other through a protocol like REST (or
> Thrift, gRPC or whatever), you can then replace that module by another one
> that respects the same interface... and you can reimplement it in whatever
> technology you want. I can have a module implemented on Elixir running on
> FreeBSD talking to another one running on OpenBSD implemented on C, talking
> to another one running on Linux implemented in node.js...

I said:

> It is compartmentalization between teams, and honoring stable internal
> functionality between teams that it makes the biggest difference.

Maybe we agree more than disagree?

You also say: > Similar to SOA, but SOA was much broader in scope. You had
service composability, discoverability, etc. That's in most cases overkill for
most companies.

Not sure if the normal way of thinking of micro-services does not include
this. If so, that is a new definition to me. To me micro-services mean
services which perform less functionality, therefore you need more of them. If
you have a platform that has 40 functions-as-a-service running in docker
containers, you will need discoverability, for example.

~~~
partycoder
You not necessarily need to roll out a discovery service. You can put services
behind a DNS, load balancer... and load balancers can be smart enough to mark
a node as down.

Now if you need more granularity than that, there's for instance Zookeeper
ephemeral nodes, that get deleted when the client stops emitting heartbeats.

------
bioneuralnet
I cannot help but wonder if the over-enthusiasm for microservices these past
few years is a direct result of the over-enthusiasm for "MVC" these past 10
years or so (since Rails).

MVC outlines very clearly the areas of responsibility for _the framework_. But
many of the popular MVC frameworks take it a step further, declaring that MVC
should be the primary dividing lines _for your app code and business logic_ ,
with little thought given to separation along functional/domain lines. (Or in
DHH's words, "The framework _is_ the application!")

So is it any wonder that 10 years later, the industry is freaking out because
our nice, clean MVC apps became business logic casseroles? Microservices _can_
help with that, just like MVC _can_ help with the PHP spaghetti code that came
before. But none of those things can substitute for basic design principles.

I wonder how things would be different if 10 years ago, instead of _app
/models_, _app /views_, and _app /controllers_, Rails had promoted _app
/auth_, _app /billing_, _app /spline_reticulation_, etc. Might such a simple
thing have pushed us in a better direction, leaving microservices to the 10%
of apps that really need them? Or would we all have followed that pattern to
illogical extremes as well?

------
echelon
Microservices probably aren't appropriate for companies with fewer than 100
engineers due to the maintenance overhead. For larger companies, however,
they're an incredible, team-oriented organizational tool. Microservices let
you deploy more frequently, make changes with higher confidence, and scale
with less heft and burden. You'll almost invariably need an entire team (or
teams) dedicated to the tooling and platform aspect of the SOA that supports
the rest of the engineering. Unless you can afford this, do not attempt a
microservice architecture.

------
gbog
I think the good question would be: say you are Google and accidentally lost
your code base (I heard it's a java monolith with around 5000 major intricate
dependencies, something unsplittable). How would the Google eng team rewrite
Google if they had to? I'm kind of 100% sure they would not go monolithic.
They more likely would have services built upon a platform, maybe not nano
services, but still services that can be handled by a small team with well
defined responsibilities.

The same with Facebook and php or stackoverflow and .NET: a successful start-
up doesn't prove it's tech stack is the best, it just proves it can work.
Someone who left to build a new ambitious competitor is more likely to choose
a better tech stack, e.g. Python for Quora.

~~~
spotman
I don't work at google but have many friends that do. (so take this with a
grain of salt)

But just because they may put all their code and commits in a giant common
repository, does not mean that its hosted, scaled, and deployed as a monolith
in current day.

From the grapevine, I know that some of their stack is c++, and some is java,
as an example.

Also, google losing all their code, made me laugh. Maybe that is a
possibility, but seems like they have to have so many backups and failsafes.
But I get you said that to illustrate a point :)

~~~
cromwellian
Google front end services are no where near monoliths. Why do you think Google
invented protobuf? Practically everything we do is RPCs from front ends to
backend smaller services.

------
davidgh
In the right circumstances, some microservices make a lot of sense. I was
recently working on a .NET project where the need for compiling handlebars
templates on the sever came up. This was the perfect use case for a little
service. Its purpose was clear and independent from the rest of the
application. In this case, we deployed the microservice on AWS Lambda, saving
the need to install Node or spin up another server with all the associated
care & feeding. Compiling large handlebars is fairly CPU intensive, and we
don't have to worry about the load on our app servers. To me, it was an ideal
scenario to develop a microservice. It solved a specific problem and didn't
bring new ones to the table.

Microservices make sense to me when the task is clearly abstract from the
application using it (which allows the service to be used more widely), the
nature of the service is such that it has significantly different resource
requirements than the rest of the application (allowing it to be scaled
independently), and the problem it solves is not trivial.

I would be happy indeed as a developer to walk into a project and have a
handful of tools at my disposal for doing things like sending emails, event
notifications, logging, encryption key rotation, etc. I just consume the API.
It's the reason I appreciate AWS; they provide a load of features (i.e.
microservices) that let me focus on domain problems and not things that have
been solved a thousand times already. So as a thoughtful developer, deploying
something as a microservice can be a prudent contribution that brings a great
deal of business value down the road.

But it starts to get out of control. After a bit of success with a legitimate
microservice or two you become a hammer and every function starts to look like
a nail.

If you can't visualize the microservice you're building ever becoming an AWS
product, popular open source project or service offered by some SaaS company,
likely it's too domain-centric and should stay in the monolith.

"Better learn balance. Balance is key. Balance good, everything good. Balance
bad, better pack up, go home. Understand?" \- Mr. Miyagi

------
gbog
Martin Fowler, as usual, wrote something foundational, deeper et better
balanced, years before this article and many other.
martinfowler.com/articles/microservices.html

------
ap22213
Geez - Am I supposed to really believe all the hyperbole in here? It makes it
sound like a move to Microservices is the main reason for a company's failure.

To me, Microservices are a pragmatic solution to build software in an age of
complete chaos. Clearly it's not a silver bullet - but what ever has been?

As someone who has to manage a complicated application architecture with lots
of pieces, very little time to think, a flat organization of full stack
developers, and a bunch of executives who pivot every other week, it's the
only scheme that works.

Would I like to go back to the old days when a team of 20 and six months would
do what a team of 3 and two weeks does today? Hell yes. But, that's not
reality - the world has moved on, and it's not slowing down anytime soon.

Startups these days are often about taking on as much risk as can be tolerated
in a race toward dominant market share and exponentially positive revenue.
And, Microservices help get us to that goal. It's often not pretty, no doubt.
But, it's way easier to manage risk in that kind of environment. With proper
monitoring, alerting, and automation - the risks go down a lot.

Some might say that I'm crazy to work in such an environment. Maybe they're
right. Generally, this is all completely experimental. But, it's helped me
scale to 25 developers and $25M revenue in 8 months. Is it sustainable? Who
knows - but, I know that the alternatives certainly wouldn't have worked. In
another 8 months, we will either be at $200M in revenue or will have died a
horrible death - but we will have died because of the business model, not
because of the software.

~~~
gerbilly
>Would I like to go back to the old days when a team of 20 and six months
would do what a team of 3 and two weeks does today?

This is yet another race to the bottom, which as programmers , we should
advocate against whenever we can.

------
gamedna
Everyone gets so caught up in the terminology "micro" "macro" . The real value
in what the microservice movement brings to the table is the push for well
defined contracts between components before writing any code. But any good
software engineer/architect knows the value of documenting design, so this
should not come as as surprise.

When considering only production systems, anybody that has a nightmare
microservice deployment that is unruly to upgrade, version, or maintain always
had some story about getting to market in record time before hand. Shipping
services as quickly as possible to get the feature out the door without
considering the downstream impact. (my absolute favorite... "we can solve auth
later with a microservice in a container")

I don't care if you have micro, macro, monolithic, or (pick a buzz word)
architecture. If its not designed properly, it will always be a nightmare.

------
EdSharkey
Lemme tell you what I want, if this is a product idea, feel free to run with
it and make $$$.

I want a framework/container that lets me set service boundaries in code, and
if my services are deployed to the same logical cluster, a local call is made
if there is a service to service call. This way, I can develop my services as
a monolithic codebase, with sharing of common code, but at deployment time,
service modules can be split up and hosted separately (or not.)

Also we need some forwards/backwards data type compatibility like you get with
protocol buffers.

Also some simple human and business process workflow support built in.

~~~
EdSharkey
And yes, I know what I'm asking for sounds a bit like SOA Suite or IBM Process
Server. What I want is an evolution (in terms of standards and protocols) of
the simple approach that you find in microservice development.

------
partycoder
This article mentions "The principle of least power", which is about
complexity management in projects:
[http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLe...](http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html)

"Given a choice of solutions, pick the least powerful solution capable of
solving your problem" Be it microservices, OOP or whatever... keep this
principle in mind.

------
dy
Great article - two key insights for me:

\- distributed transactions are hard to do well especially in write scenarios

\- microservices often solve team issues better than technical issues

------
intrasight
I feel like the article represents a school of thought that has been
deprecated with the arrival of "serverless" microservice platforms like Azure
Logic Apps or Amazon Lambda. The "pain" and "penalty" of microservices is
being eliminated by those new platforms. I'm in the process of migrating to
this better place, and so far I really like what I see.

------
rexreed
I've been using microservices for a particular app since 2011 and it's working
quite well. So in my instance, yes, please do. Maybe not for you, but for me.
So, change this to: "Microservices - not for me".

------
slowmovintarget
Microservices are an application of Conway's Law at scale. If you don't have
the scale, don't do microservices, because you can't afford the trade-off.

------
chetanahuja
The original post is completely on point and this thread is full of so full of
"No True Scotsman" syndrome.

There's a fundamental mathematical truth that if you have N moving parts in a
system, you're looking at possible O(N^2) ways the system can break. Now that
doesn't mean that you build everything as one gigantic binary but it certainly
means that system architects should be always be looking at _reducing_ the
number of moving parts not increasing them. The whole microservices craze is
exactly the opposite of that.

------
philliphaydon
If you need a distributed transaction isn't that just an indication your
service isn't right to begin with?

------
DigitalJack
Sounds like the kernel arguments of yore.

------
contingencies
All aboard the anti-bandwagon bandwagon!

------
sivanmz
I'm hopeful that some of this will fade once the Java 9 module system becomes
available.

