
Lessons Learned While Building Microservices - sundip
http://blog.runnable.com/post/149676042396/lessons-learned-while-building-microservices
======
derrekl
One of the stated lessons learned is: we'd still be on node 0.10 if we weren't
using microservices. I've worked a lot on huge monoliths and microservices.
Being "stuck" on a version has less to do with monoliths/microservices than it
does consistent update practice. If you are using FOSS and schedule periodic
updates of the core language and the apps dependencies you'll prevent yourself
from getting stuck on old versions. If you run across some dependency that
isn't working on version X of the core language you can open tickets against
it and/or schedule updating the dependency yourself (this doesn't go away with
microservices). Opening tickets against dependencies as the core language
updates helps both you and the dependency owner by helping them test and get
out ahead. Not only will you prevent from getting stuck on old versions but
you'll also have the latest security updates. Note: you don't have to be on
the bleeding edge but you should strive to be, in my opinion, no more than 6
months or so from the edge.

~~~
Jtsummers
> If you run across some dependency that isn't working on version X of the
> core language you can open tickets against it and/or schedule updating the
> dependency yourself (this doesn't go away with microservices).

What does go away with microservices (or, in my case, a suite of applications
since my stuff doesn't run online), is that each portion only deals with _its_
dependencies. If I have two applications or services X and Y. X depends on D
depends on language/library version N. Y has no such dependency, Y can migrate
to N+1 while the issues with D are worked out (changing the dependency, fixing
the depency, removing the dependency).

In a monolithic application, this is more difficult or impossible. You gain a
lot with a monolith, but you lose the flexibility to maintain components as
individual components.

------
ChemicalWarfare
So while I'm not anti-microservices, from the developer's perspective
sometimes there's just way too many moving parts.

one code change+one test change back in the "monolith" days (and if the change
broke the existing tests you know right away) now becomes an ordeal.

Tracking down the client services/altering their code + tests+ simulators (not
to mention that you now have to check the code out from bazillions of repos,
run it locally etc) and then waiting for their respective build plans to pass,
wait for the integration tests to pass etc.

~~~
throwanem
I've done a lot of work on monoliths, and a fair amount with microservices.
I've never observed the perceived simplicity of the former to bear out in
practice; there's just as much complexity, but instead of being reasonably
well contained and prevented from spilling across service boundaries, it's
smeared all over the application, so being confident you've tracked down and
addressed all of it is much more difficult than it has to be.

It sounds like you may be having problems not because the architecture is
designed the way it is per se, but because it's poorly documented and hard to
discover. There's nothing about the monolithic style which prevents that, or
even makes it less likely to occur.

~~~
StavrosK
As I see it (and I haven't been convinced otherwise), the only advantage
microservices have over monoliths is that they can scale horizontally more
easily, and a slight advantage is that they pressure you to write cleaner
interfaces.

There's nothing preventing a monolith from being as modular as a microservices
architecture, only without all the headaches that come with monitoring tens of
services and sticking a network between them. There is _NOT_ just as much
complexity in a monolith, because you have no network of services to monitor,
there's only one service.

Sure, your _business logic_ is going to be the same in either approach, but
you're comparing badly written monoliths to well-written microservices.
There's nothing that says microservices can't be a mess (and I've seen
multiple people completely botch it and have all the services talk to the same
database).

~~~
lcarlson
Polyglot can be nice too.

~~~
StavrosK
Ah, true, that's a nice benefit, agreed.

------
Bahamut
My current company learned this a couple of years ago - on their first Node
project after deciding to move away from .Net, it ended up a giant monolith,
and so 4 years ago or so they decided to move towards microservices. The
burden of trying to upgrade a monolith is colossal, and it is where
microservices shine.

------
socmag
Yup, and even better when you aren't even tied to any language.

------
erikcw
Does anyone know of a good resource for learning microservices best practices?
We're at a stage at my company where it makes sense to consider the transition
from a monolith -- but would love to do the right homework first to avoid some
of the pitfalls.

~~~
vkjv
I highly recommend reading Martin Fowler.

[http://martinfowler.com/articles/microservices.html](http://martinfowler.com/articles/microservices.html)
[http://martinfowler.com/eaaDev/EventSourcing.html](http://martinfowler.com/eaaDev/EventSourcing.html)

