
Why Microservices? - steilpass
http://dev.otto.de/2016/03/20/why-microservices/
======
dominotw
Monoliths used to have specalists, people who know intricacies of cloud
deployment, experts in db query tuning ect.

What happens to these people when ppl move to mircoservices. Now we have bunch
of devs who are expected to be jack of all trades doing everything sub
optimally .

I've seen some places move all database experts to 'db as service' team, but
this arrangement is awkward at best and have strange organizational and
management issues that were not present in monolith style development

~~~
gsteinacker
In the beginning, every team that is able to build a monolith should also be
able to build multiple microservices. Think of microservices being highly
cohesive and loosely coupled components...

But this will not scale with respect to the number of dev/ops/qa people or
with respect to the number of microservices. We did it differently from the
beginning by starting with four instead of a single team.

Today, we have ~12 "feature teams" and a few teams for "cross cutting
concerns": A team that is responsible for loadtests (ensuring scalability),
one for (ensuring) security, one for "platform engineering".

The feature teams are responsible for one or few "bounded contexts" (->Domain
Driven Design) like "ShoppingCart", "Search", "Navigation". Every BC is
implemented by one or more microservices.

Teams have developers, testers, and everything else, that they need to develop
and operate their services. Splitting teams by skill (DB, Frontend, ...)
instead of splitting by business domain (shopping cart, ...) would only have
the effect, that multiple teams heavily depend on each other, all the time.
IMHO not a good idea. I would strongly recommend to build mostly independent,
autonomous, cross-functional teams. DevOps teams.

\--Guido

~~~
merb
Actually what you describe here is mostly why I think that it was stupid to
rebuilt otto.de from scratch. microservices are a improvment over a monolith
inside a bigger Application with a big team. Microservices are happening
caused by team sizes and management overhead, it had nothing to do that a
monolith is bad at all. And that's why I dislike all the fancy posts about
them, nothing stops you from doing all the same things with a monolith,
especially when you have a small team. As your team grows you mostly change to
a service oriented architecture and evolve from there. it mostly isn't a good
practice to start with a microservice architecture without having a monolith
that you need to split (I know there are some but stil.. it's hard to say that
the overhead it produces with a "few" people is valueable). Actually a lot
inside this article explains what parts were easy, however the hard parts
about such systems are mostly not written anywhere near, which is most
managing logs, faulty systems, automatic routing, versioning, database
migrations if the system has a database, updating servers, service discovery,
service load-balancing, service monitoring, edge service router and that are
prolly just a few of the dozen things which makes such systems harder.

~~~
gsteinacker
We did not rebuild otto.de from scratch because we wanted a microservice
architecture. We had to rebuild otto.de, because the old monolithic shop was
not meeting non-functional (and a single functional) requirements anymore. And
we had to rebuild it, because the old shop was based on a standard product, so
we were unable to simply refactor it. When we started the development, we were
looking for an architecture that is meeting our requirements - and we did not
chose microservices in the beginning, but self-contained systems ([http://scs-
architecture.org](http://scs-architecture.org),
[https://en.wikipedia.org/wiki/Self-
contained_Systems](https://en.wikipedia.org/wiki/Self-contained_Systems)).
Microservices were introduced later, when the first SCS became too large
again. I think, you should not use microservices, because they are
interesting. You should use microservices, when you have problems that are
addressed by this architectural style.

I totally agree, that microservice architectures (just like any other kind of
distributed system) have a lot of challenges. It is hard to solve the
problems, that you mentioned. My article was about the good parts - but I
could very well imagine to write a follow-up about all the challenges :-)

\--Guido

------
squiguy7
> We are currently deploying multiple times a day, up to 250 times a week
> (continuously increasing).

That is such a huge win. Time spent deploying and monitoring is wasteful;
especially when you have a large application running on hundreds of machines.

~~~
gsteinacker
Not only deploying and monitoring: managing bugs instead of fixing them.
managing releases instead of releasing. And by the way: developing small
microservices instead of trying to understand how to extend a single big,
tangled monolith. \--Guido

------
zabeltech
i really miss the days when otto shipped games on their free cds ... what was
the name of the logistic/world trade game again .. back in the DOS days
(win95?)

