Key Insights on Microservices Adoption and DevOps Practices from QCon London

At the recent QCon London conference, Michael Brunton‑Spall, a technical architect from the UK Government Digital Service (GDS), discussed the critical role of DevOps in achieving successful microservice operations. He highlighted the key factors for identifying a microservice, described how to create the first microservice, and outlined the essential tools and practices needed to manage a microservice ecosystem.

A microservice must be a small, self‑contained service that manages its own data without integrating with external databases. All data should be shared via public interfaces following the "dumb pipes / smart endpoints" principle. Each microservice should have a single owner—the team responsible for all code and runtime. Brunton‑Spall agreed with Jeff Sussna’s view that microservices represent both a new architectural model and a new organizational model.

“Microservices not only exhibit a new architectural model, they also embody a new organizational model.”

This new organizational model shifts the responsibilities of developers and operations: developers assume full lifecycle ownership of their services, while operations increasingly act as advisors.

Brunton‑Spall recommends that teams starting with microservices keep the scope small. An organization should begin with a single microservice, ensuring the adoption of appropriate supporting tools and practices such as easy‑to‑use automation infrastructure, automated deployment, log aggregation, monitoring tools, and robust alerting practices.

Scaling from one microservice to many introduces new challenges, primarily the growing complexity of error diagnosis. As Brunton‑Spall noted:

“Compared with a monolithic architecture of the same size, microservice failures appear far more conspicuous.”

Understanding the complex interactions between microservices requires excellent diagnostic and monitoring tools. He distinguishes shallow monitoring (“Is my service running?”) from deep monitoring (“Are my service and its dependencies running?”). While deep monitoring provides a more comprehensive view, it can also generate cascading alerts that obscure the true root cause, especially when a widely‑used service fails.

Two additional points are frequently emphasized: design microservices with failure scenarios in mind, and provide a unified management interface. For example, TwitterServer offers a standard way to trigger a circuit‑breaker for a service.

If an organization already has a mature deployment‑audit process, developers should be equipped with pagers and data‑center keys. Pagers make developers experience the impact of their own mistakes, encouraging rapid resolution of recurring issues. However, mature support models also need policies for developer fatigue, team turnover, and hand‑over procedures, such as requiring that a system have fewer than N errors over M weeks and that a run‑book be submitted during hand‑over.

Simple solutions can promote effective microservice operations. Brunton‑Spall shared a case from his time at The Guardian before joining GDS: the initial server launch process used a basic Ubuntu image, with a bash script that employed apt-get to install packages and wget to download a JAR file and start it.

Disclaimer: The content originates from publicly available internet sources; we remain neutral to the viewpoints expressed and provide it solely for reference and discussion. Copyright belongs to the original author or institution; please contact us for removal if infringement occurs.