At the last QCon London, Michael Brunton-Spall, Technical Architect at the UK's Government Digital Service (GDS), expressed his views on how DevOps patterns are crucial to successfully operate microservices. Brunton-Spall identified the key ingredients to identify a microservice, explained how to build your first microservice and the necessary tools and practices to manage an ecosystem of microservices.
A microservice must be small and own its data, without any kind of database integration. All data must be shared via public interfaces, following a "dumb pipes / smart endpoints" approach. Each microservice must have only one owner: a team that owns the code and the runtime. Brunton-Spall agrees with Jeff Sussna when he declares:
Microservices represent a new organizational model as much as a new architectural model.
This new organizational model also means that the role of developers and operations is changing, with developers taking ownership of the whole lifecycle of a microservice and operations taking more and more a consultant role.
Brunton-Spall advises to start small when starting with microservices. An organization should start with just one microservice and ensure it is built with the correct supporting tools and practices. The suggested tools and practices are the ones discussed in the DevOps community: automating infrastructure; automating deployments; log aggregation; monitoring tools that are easy to use and integrate with; good alerting practices.
Moving from one to many microservices brings a set of extra challenges, mainly related to the increased troubleshooting complexity. As Brunton-Spall put it:
Microservices are going to fail in more spectacular ways than the equivalent monolith.
The need to understand all the complex interactions between microservices requires excellent diagnosis and monitoring tools - the emphasis on monitoring was a constant in every microservices talk at QCon London. Brunton-Spall distinguished between shallow - is my service working? - and deep monitoring: is my service and its dependencies working?. Although the latter is more comprehensive, it can trigger a cascade of alerts and obfuscate the real cause of the problem. This can happen if a microservice that is used by many others fails.
The need to design microservices for failure as well as providing consistent admin interfaces was also highlighted many times. For instance, there should be a common way to trigger a microservice's circuit breaker. TwitterServer provides an example of this approach.
Developers should be given pagers and the keys to deployment, as long as there are excellent deployment audits in place. The pagers help developers feel the pain of their own mistakes, ensuring the swift fixing of recurring problems. But this is not enough for a mature support process. For instance, what happens when developers "get bored" and move on, asked Brunton-Spall? Or if a team gets disbanded? A first line of support and triage must still exist. A maturity model for support should be used to define rules for such things as handovers, e.g., "systems must have < N faults in M weeks and complete run book to be handed off".
Simple solutions enable good microservices operation practices. Brunton-Spall mentioned the case at The Guardian, where he worked before joining GDS. The initial server provisioning process consisted of a base Ubuntu image; a provisioning script consisting of a few lines of bash script code to "apt-get" packages; and a wget to download a JAR file and execute it.