Why Microservices? | Hacker News Reader

Why Microservices?

dev.otto.de

67 pointssteilpass8 comments

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

I think the biggest challenge with monolith -> microservice architecture is that nobody really adjusts their team organization or planning to account for it. They're super highly-coupled problems, and if you solve one without the other you just end up pushing debt off to "some service with a contract".

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

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.

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, 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

> 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.

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

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?)

Reply on news.ycombinator.com