Microservices, have you met… DevOps?
By Jeff Sussna
Numerous commentators have remarked that microservices trade code complexity for operational complexity. Gary Oliffe referred to it as “services with the guts on the outside”. It is true that microservices potentially confront operations with an explosion of moving parts and interdependencies. The key to keeping ops from being buried under this new-found complexity is understanding that microservices represent a new organizational model as much as a new architectural model. The organizational transformation needed to make microservices manageable can’t be restricted to development; instead, it needs to happen at the level of DevOps.
Microservices work by reducing the scope of concern. Developers have to worry about fewer lines of code, fewer features, and fewer interfaces. They can deliver functional value more quickly and often, with less fear of breaking things, and rely on higher-order emergent processes to incorporate their work into a coherent global system.
In order for microservices to work, though, ops needs a similar conceptual framework. Trying to manage an entire universe of microservices from the outside increases the scope of concern instead of reducing it. The solution is to take the word “service” seriously. Each microservice is just that: a software service. The team that builds and operates it need only worry about it and its immediate dependencies. Dependent services are customers; services upon which a given microservice depends are vendors.
How do you ensure robustness, and manage failure, when you restrict your operational scope to local concerns? The reason we try to operate microservice architectures monolithically in the first place is because we think “but it all has to work”. The answer is to treat them as the complex systems they are, instead of the complicated systems they’re replacing. If each microservice is a first-class service, its dependencies are third-parties, just like Google Maps, or Twilio, or any other external service. Third-party services fail, and systems that depend on them have no choice but to design for failure.
Microservices promise increased agility combined with improved quality. To achieve both goals, organizations have to shift their definition of system-level quality from stability to resilience. If they can do that, they can reflect that definition of quality in their organizational structure. Just as a SaaS company as a whole would use DevOps to deliver service quality and agility, so too each microservice would do the same.
Rack image CC 2.0 Steve Jurvetson
Originally published at blog.ingineering.it. Used with permission.
