Adopting Microservices at Netflix: Lessons for Architectural Design

My comment, slightly edited, from the previous posting of this, at <a href="https://news.ycombinator.com/item?id=9106813" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9106813</a><p>&gt; One kind of coupling that people tend to overlook as they transition to a microservices architecture is database coupling, where all services talk to the same database and updating a service means changing the schema. You need to split the database up and denormalize it.<p>That sounds like a decision you wouldn&#x27;t want to take lightly; the kind of thing you might do once your company is already big. I wouldn&#x27;t want to start out that way though, it sounds like a recipe for a mess.

This seems like it&#x27;s just taking the idea of decoupling your service and talking to them via APIs a little further by saying.. decouple them to an even smaller granularity?<p>This has always been the generally accepted way to scale out software services. Is there a novel idea being discussed here, or just that they&#x27;ve been doing this at Netflix?

If your app depends on lots of of them, it&#x27;s only going to run as fast as the slowest dependency. 1% chance of poor performance isn&#x27;t to bad, the joint distribution of 20 microservices each with a 1% chance, well that gets pretty ugly. In the normal case, everything is great, but the failure modes of each service become a much bigger deal.<p>It&#x27;s a great architecture, but fan out of dependencies is a real risk.

My team recently added a microservice to support our fairly monolythic backend service. The big challenge we found was that it takes a lot of effort to make a new (micro)service. We need to create a system of alarms (instead of relying on existing catch all defaults). We need its own test environment, we need to find ways to send traffic to pre-prod. We needed to figure out how to bootstrap the new service into the companies infrastructure. We needed to think about how the dependent service would authenticate against the new service. All of that on top of the core feature work.<p>All these things are good. You want isolated, focused test environments. You want tightly defined alarms. However we underestimated how long creating a new service would take. In the end we ended up pushing features out when they were ready but before the operational work was complete. Unsurprisingly we saw the issues we knew we wanted to protect against.<p>Better microservice franeworks that match the companies infrastructure would be helpful. Make building microservices cheap by building tools to speed up the process.

A few questions:<p>a) How do you prevent technical debt? It seems to be more difficult due to APIs which shouldn&#x27;t have breaking changes. In theory you could always version up the APIs and serve both versions or just add a new API for a breaking change, but these solutions seems awkward.<p>b) How do you start developing multiple microservices at the same time? I would expect APIs to change a lot in the beginning, which would mean that updating one microservice would break another. Perhaps that is acceptable before the first &quot;stable release&quot; of a microservice.

building and rebuilding and maintaining applications is hard enough. Now we have whitepapers from a company that wants to sell us on a new paradigm which -- cough cough -- they just happen to have software to support.