How Netflix Will Balance Developers' Needs For Simplicity vs. Microservice Driven Velocity

In a recent article for InfoQ, Margot Krouwer discussed how Netflix is attempting to reconcile developer code and process ownership with multiple services shared across teams in API environments to get the most out of their microservices architecture.

The article references a post on Netflix’s tech blog titled "Engineering Trade-Offs and the Netflix API Re-Architecture", in which Netflix engineering managers Katharina Probst and Justin Becker highlight the challenges they face. In particular, the pair writes that they are working to, “reconcile seemingly conflicting engineering principles: velocity and full ownership vs. maximum code reuse and consolidation."

The media streaming service currently has one API acting as an orchestration service between different microservices and their individual APIs. But, the issue with this design is that individual services enjoy far less control over how their data is consumed by users, and the API takes on the burden of handling every kind of consumer request possible. This creates a single point of failure where the API going down affects every consumer services.

Another approach could be to ensure every Microservice has its own API for direct communication with the consumers, but placing the burden of every consumer request on the microservice detracts from the idea of it being a fully independent service operating at maximum productivity.

During her talk at QCon New York 2016, Probst revealed she planned to keep a single API that all consumer-facing microservices communicate with, but mitigate the risk through process isolation by using containers, thus solving the common microservices issue of shared tooling and services.

The post doesn’t provide a clear answer on other API decisions, such as whether to have multiple orchestration APIs that provide greater orchestration control for the underlying services, or to reduce the amount of logic in the existing API so it can serve strictly as an interface for the data. Both approaches have their benefits and drawbacks, and no final decision was given, but the Netflix post alludes to the solution being a compromise between different trade-offs. 

Be sure to read the next Microservices article: Five Principles of Effective Microservices Monitoring

Original Article

Netflix Attempts to Reconcile Large Scale APIs with Developer Autonomy