
Faster, cheaper, and better: A story of breaking a monolith - seperman
https://zepworks.com/posts/faster-better-cheaper-and-re-architecture/
======
trishume
It seems like most or all of the benefits listed in this post could have been
achieved just as easily by changing code in their monolith. Like the
ElasticSearch optimizations and the decoupling from the relational database.

Similarly the benefits they do tie explicitly to microservices like scoped
errors and tests can also be achieved in monoliths with simple filters on the
errors and tests being run, without all the work of splitting out the service.

~~~
seperman
I do not disagree with your comment. As I mentioned in the article the main
reasons to break into micro-services are:

1\. Independent releases 2\. Easier for on-boarding new engineers 3\. Scale
micro-services independently

The rest of the article is about how to use the breakout opportunity to make
major changes to the code and the data-structure. The goal is for the users of
the service to have an aha moment of "Search is so much faster after the
breakout!".

~~~
gitgud
Microservices are almost completely opposed to agile development. They require
a strong architecture before implementation and are much harder to reconfigure
regardless of versioning. The running system is also hard to manage.

~~~
seperman
Not sure if I agree with you regarding the agile part. If each team owns their
"micro-service", then they can have their own "sprints".

~~~
budabudimir
What is the difference between each team owning a microservice and owning a
part of the monolith?

There is common release process, but with proper infra in place, that
shouldn't be a problem.

~~~
sheeshkebab
It all comes down to coordination and regression, which are quite complex in
monoliths.

Suppose you'd like to push code change to production for your monolith - how
do you know that someone else's change 1) is ready to to production together
with yours 2) does not affect your module. Typically these can't be answered
easily - and so release process is converted to manual testing and scheduled
(and often slow) releases.

------
bobm_kite9
Why is microservices so much more popular right now than, say, distributed
processing via the actor model? It feels like splitting things up with HTTP
boundaries is a lot of work, less flexible and precludes a lot of re-use. Is
it just because of advances in tooling lately like Kubernetes and docker?

~~~
seperman
That is a great question. Kubernetes and docker and the recent addition of
service mesh layer definitely do make things easier for micro-services.
However as another commenter mentioned, Microservices are typically an
organizational rather than technical feature. We do use pubsub pattern for
distributed processing widely. Regarding the http boundaries point that you
brought up, we use gRPC instead of HTTP for most services.

------
aylmao
Interesting article, though I wish there were more details on why this was
cheaper, and where the hundreds of thousands of dollars saved annually came
from.

~~~
seperman
Mainly saved in infrastructure costs: Elasticsearch and Kubernetes resources.

~~~
ryan_j_naughton
Also from Fair here.

A lot of the cost savings were because we could decrease the size of our
elasticsearch cluster. This was mostly due to the flattening of the
elasticsearch document schema, which improved performance dramatically but
also allowed us to run significantly fewer ES nodes.

~~~
aylmao
Gotcha, thanks for reaching back!

------
yandrypozo
I went straight searching for advises on how to avoid a distributed monolith,
but no luck, looks like most of the micro-services now days are just
distributed monolith.

Let's share advises about it: [https://medium.com/unbabel/your-distributed-
monoliths-are-se...](https://medium.com/unbabel/your-distributed-monoliths-
are-secretly-plotting-against-you-4c1b20324a31)

------
argd678
This is cutting it close to say microservice, it’s just two services and they
don’t fan out or have a lot of the complexity that causes the down sides; such
as fan outs that require tracing to debug, requires too many services to
startup on your laptop for dev, load testing and tuning, common libraries that
cause systemic failures or require world rebuilds when modified, service to
service authentication...

~~~
seperman
This is a very simplified version of our architecture just for the purpose of
this article. We have exactly 83 micro-services currently.

------
tutfbhuf
Writing new code is faster than understanding existing code.

Different teams should have enough room to not step on each other toes.

Soft boundaries tend to be overruled over time, because of human laziness.

~~~
mnd999
I’m not so sure, I’d rather start from what is there, understand it and go
from there.

Sure, if you start over you may we’ll get there faster but you’ll probably
repeats some of the same mistakes all over again.

~~~
skohan
I think the temptation to "rewrite the whole thing" is often strong with a
large legacy project, and often doesn't pan out as well as it seems because
while it is effective at eliminating a lot of the cruft and architectural
missteps of the legacy codebase, it also means throwing out all of the subtle
behaviors and edge-case-handling which has been built up over years of
iteration.

I am a proponent of the disposable-code philosophy though: no system should be
considered "off limits", and a healthy codebase should probably be completely
rewritten every couple of years. It should just be done incrementally, in a
modular way in most cases rather than throwing out the whole thing and
starting again.

------
profalseidol
Can you view Microservices in the same light as multiple companies? Just like
when your monolith calls on a third party API that does the payment for you -
ain't that also a microservices that happens to involves 2 different
individual companies?

~~~
seperman
Hmm, not sure if I'm completely following... Yeah you can consider them
separate entities if they are truly decoupled.

------
raptorraver
Good read, thanks!

I’d be interested to know how long this all took and how many developers were
involved.

~~~
seperman
It took over a quarter of the year with one engineer 100% dedicated to it and
between 1 to 3 other engineers involved part-time over different stages of the
project.

------
manicdee
“Faster, cheaper, better” is a trigger phrase for Australians, given that it
was the three word slogan used by the Liberal Party to whitewash their
sabotage of our national Communications infrastructure.

I was wondering when the author would get to the punch line, but they just
kept solving problems not creating them.

