
Kill “Microservices” Before Its Too Late by Chad Fowler - devnulled
https://www.youtube.com/watch?v=-UKEPd2ipEk
======
davidw
Ok, this is why I _hate_ videos compared to reading.

The first minute is some guy chatting about how Chad gave a talk that was
'visually horrifying' which it turns out was because it looked like a
McDonalds theme.

Total waste of my time; with something written down, I could have skimmed some
of the headlines in that minute, started reading, or otherwise learned
something.

~~~
oridecon
Sometimes I like to consume content like it's not fast-food.

~~~
davidw
That's what's great about reading - you have the freedom to do so if you want
to!

This is about a specific design pattern that some of us may have exposure to.
It's not a speech for the ages as far as I can tell.

"The only thing we have to fear... is fear itself! And microservices!"

"I have nothing to offer but blood, toil, tears and sweat. Oh, and
microservices. If we can get the Germans to adopt those, they're totally
fucked"

------
sp527
Going to play devil's advocate here and suggest that the concept of a
microservice has never been that difficult to grasp.

It's a self-contained service presenting a set of related functionalities in a
system having a clearly defined, documented, published interface that then
becomes a dependency of other services in your system (and may itself depend
on services; in the long run you end up with a DAG). It could be viewed as the
most natural alternative to monolithic development and makes more sense
nowadays, in a world that has better tech/standards around containerization
and DevOps.

It's particularly suited to large organizations that allow for organizing
teams around specific services. This also means that different teams can
choose different tech stacks, depending on what's suitable and what the team
has (or wants) experience using.

It's also very well-suited to async/eventually consistent functionality in
evented systems. Most complex systems these days present a lot of requirements
suited to this paradigm. You often see AMQs show up in relation to
microservices for this reason.

You do have to worry about cascading failure when you need strong consistency
and low latency responses (so make sure you build systems with sensible
fallbacks and constantly test failure scenarios).

Load testing and SLAs are also good ideas with microservices. Another cool
ancillary benefit to service-orientation is the ability to scale services up
or down depending on load. In a monolithic system, you might end up with more
waste because functionality is highly coupled. When you break things out, it
becomes easier to identify where more resources are required and resources are
correspondingly allocated more efficiently.

That's the high level overview imo.

~~~
falcolas
I'm going to disagree with one particular point - microservices are not better
than monoliths. They introduce whole new layers of complexity, latency, and
points of failure that no amount of tooling can overcome.

The primary reason microservices have the opportunity to shine is that they
are easy to scale horizontally.

Having been repeatedly burned by microservice complexity and failures, I'm
firmly of the opinion that you should do Monoliths until you can't do them
anymore. If you compose your code thoughtfully and have well defined API
boundaries from the beginning, it won't be that hard to start breaking it out
into microservices _if_ you find that you can no longer scale vertically.

~~~
sp527
I feel like I alluded to this, so my bad if I wasn't clear enough.
Microservices are absolutely more (and perhaps only) appropriate for larger
orgs dealing with serious traffic. I do also think there's an intermediary
'macroservice' concept that isn't quite several hundred services a la
Netflix/Uber, but also isn't as primitive as a layer of (stateless,
homogeneous) overburdened API servers with too much business logic.

~~~
twic
I don't buy the scaling argument in the slightest. You can scale a monolith
more easily and more efficiently. It's called cookie cutter scaling:

[http://paulhammant.com/2011/11/29/cookie-cutter-
scaling/](http://paulhammant.com/2011/11/29/cookie-cutter-scaling/)

The one performance-related thing that microservices give you is isolation.
Say you are a newspaper; you render articles and handle comments. If you have
one article where the comments section completely blows up, then with a
monolith, requests for comment handling will eat all the CPU and I/O, and
articles will render slowly for everyone. If you have separate services for
articles and comments, you should be able to ensure that articles continue to
get enough resources to be served smoothly.

~~~
falcolas
As with all things, it's not always that easy.

A great example I've been fighting with recently - a backend which requires a
very large in-memory data graph which is unique for each user. Rebuilding this
graph from the backing datastores takes between 5 and 10 seconds, but if it's
in memory, responses take under 100ms.

The problem is that this monolith will be deployed in a microservice
environment - stateless routers between dozens of docker hosts, each hosting
multiple dozens of services, and any one of which can go up or down seemingly
at whim.

Even if we were not concerned with the challenge of putting stateful
applications in a stateless environment, we'd still have to worry through how
to ensure that servers going down doesn't cause the entire cluster to
rebalance and give everyone 10 second load times, how to route secure traffic
so that users are always hitting the same servers (even across sessions), how
to mitigate the data flood if the servers did catastrophically rebalance, and
so forth.

So yes, theoretically, monoliths may be capable of scaling horizontally in a
cookie cutter pattern. But the devil is still in the details.

Oh, and to fix your article/comments problem - just segregate off the one
article to dedicated servers. Not too had a problem to solve, especially since
newspaper articles are nicely routable via their URLs. Back when I worked with
bare metal in colocated datacenters, it was a very popular method of handling
popular customers.

------
striking
Here's YouTube's attempt at a transcript for this talk:
[http://sprunge.us/MSSg](http://sprunge.us/MSSg)

(if someone would like to clean it up, that'd be great. That someone can't be
me, because I'm in class right now. If you want to find a copy of this, go to
the "More" option on YouTube and pick the "Transcript" option.)

One point I could pick out was:

> I've been talking to people who want to know how they can do microservices
> too and like they really don't understand what it means. "It's just a word
> I've heard, it's good you know" and they're really smart people so we've
> already destroyed this concept.

------
carsongross
Despite the title, the talk is in favor of microservices.

I'm not convinced by the arguments (some of them seem somewhat contradictory:
"Small projects succeed" v "Small is not the goal") but I would be interested
in seeing the talk turned into a blog post that could be studied more closely
and discussed.

------
Terr_
> [16:35] Maybe you should just _plan_ to throw it away.

Definitely. To reiterate something I posted on Reddit a while back:

___

The lesson I've drawn from it is this: _Design for deletion._ Your first
priority is to design your code for the inevitable day when your successor (or
perhaps you yourself) dislikes it. The less effort/risk to uncouple and remove
it, the better.

Even the most elegant work will eventually stop being relevant as the
business' underlying problems change. If that's not true, then what you're
working on should probably be structured as an independent library _anyway._

