The wave of hype and excitement about microservices continues unabated. Understanding exactly why and how your organisation will benefit from a microservice architecture is an important first step to adoption and shouldn't be left as an afterthought.
Microservices promise many benefits that are of interest to application architects and development teams, including fluid, flexible delivery of changes, implementation technology flexibility, precise scalability and cloud readiness. These promises align with growing demand from business stakeholders for new systems that can adapt to the demands of digital business in highly competitive ecosystems.
Gartner defines a microservice as a tightly scoped, strongly encapsulated, loosely coupled, independently deployable and independently scalable application component. They first rose to popularity when digital business leaders like Netflix, Amazon, eBay and Twitter took a radically different approach to building and supporting their cloud-based applications. These applications were the antithesis of monolithic applications, where entire application scopes are developed, built, tested and deployed in concert.
Today, microservices are being adopted by leading companies in banking, retail and other industries to support continuous delivery of cloud applications. It enables them to deliver new features into their live production systems multiple times a day, as well as to support web-scale traffic volumes.
Microservices have built momentum and mind share among architects looking to address the challenges of scaling their applications and supporting more flexible and agile development practices. Early adopters like Airbnb, Disney, Dropbox, GE, Goldman Sachs and Twitter have seen development lead times cut by as much as 75 percent when using microservices.
Interest has also grown among architects without these explicit challenges, increasing the risk that the architecture is being adopted for inappropriate reasons, not least because it is heavily hyped, fashionable and will look good on a resume.
Avoiding “microservice-washing”
Where there’s hype and excitement, marketing teams will follow. Sometimes they get it spot on – especially where their audience is technologists that already understand the terminology. But sometimes they miss the mark and create confusion.
It doesn’t help that there isn’t a standard, universal definition of microservices – there’ll be many flavours and interpretations – but it does help to understand what a microservice is not. The “microservice-washing” of technology that has very little to do with microservices is not helpful to the marketplace. When architects and IT leaders have a different understanding of the same term it creates confusion and risk.
The most common misuse of the term microservices is calling a service delivered or exposed via web API a microservice. This drives me nuts because the whole point of an API is that it encapsulates the service implementation – which might be microservices or something much less glamourous. As the user of the API, you shouldn’t know or care what architecture the provider is using.
Microservices architecture is an implementation detail for the service provider that, if executed well, should allow them to deliver a more scalable, resilient and rapidly improving service. If your service provider is selling you a microservice, then buyer beware – it might be a great API, but it’s highly unlikely to help you deliver microservices architecture for your organisation.
When and when not to use microservices
Microservices can deliver better agility and scalability advantages than any other paradigm, so consider adopting for applications that have extreme requirements in these areas. Vendors and open-source communities are developing frameworks and platforms that simplify adoption of the microservices architecture. However, while they’re maturing rapidly, complete and robust mainstream platforms are probably at least a year away.
In the meantime, creating a complete microservice infrastructure requires composition and integration of a number of supporting tools to create what Gartner calls the “outer architecture.” It delivers the platform capabilities needed to help microservices work together to deliver flexible and scalable development and deployment.
Most organisations, however, don't have the type of web-scale agility and scalability requirements that push teams to adopt microservices. So don't get caught up in the hype and don't feel compelled to adopt the paradigm just because it's new and everyone is talking about it.
There are other ways to increase agility. Focus on development and deployment agility of larger components before attempting to do it for a swarm of dynamically evolving microservices. Most organisations will find microservices too complex, expensive and disruptive to deliver a return on the investment required.
Meanwhile, organisations can derive tremendous value from the miniservices model, which advocates a more pragmatic, coarse-grained services approach with relaxed architectural constraints.
Where to start
If you’re looking to modernise your application architecture and infrastructure with microservices:
- Determine whether your organisation is mature enough to adopt microservices. Do you have a strong application architecture practice? Do you have a mature agile and DevOps practice? Will your data management team support it?
- Take it slowly. Initially use microservices only where you need to — in applications with web-scale agility or scalability requirements. Direct teams to experiment with the new patterns and technologies and build expertise.
- Expect to implement a microservices infrastructure to provide the outer architecture capabilities needed to build, deploy and operate fleets of microservices. PaaS and container management platforms can provide a core, but you’ll need to supplement this with capabilities such as API gateways, service discovery, monitoring and telemetry, build and test automation, messaging and data persistence.
- If your organisation isn't prepared to adopt microservices architecture in its entirety, consider using miniservices to gain relevant experience and significant agility benefits.
Gary Olliffe is a research vice president at Gartner. His research focuses on application architecture, service-oriented architecture, microservices, event-driven architecture, web APIs design, API management and application integration. Gary will be presenting on microservices at the Gartner Application Architecture, Development & Integration Summit in Sydney on 24-25 July 2017.