The path to microservices

Blindly implementing microservices can create more problems than it solves.

Applications professionals face increasing pressure to deliver applications quickly and support rapid scaling. Microservices appear to be the shining light, promising development agility, deployment flexibility and precise scalability.

Following many successful, high-profile microservices implementations at Netflix, eBay, Amazon and others, organisations are attempting to adopt microservices because the blogosphere is telling them that it’s the necessary next step in architecture. But it isn’t.

Microservices is an architectural pattern aimed at solving two problems that organisations experience as they grow. The first is the inability to meet customer demand for new features. When applications grow large, the pace of delivery tends to become limited. This is because multiple teams working on a single application need to coordinate development, testing and release.

The second is the inability to scale quickly and cost effectively. Organisations with large monolithic applications and high consumer demand for their services find that scaling is expensive. This is because all parts of the application must be scaled together, regardless of relative demand.

If your organisation doesn’t have these problems, blindly implementing microservices will create more problems than it solves. In fact, Gartner predicts that, by 2022, 70 percent of organisations that attempt to adopt microservices will have found the effort too disruptive and will have switched to miniservices instead. These have a larger scope and more relaxed architectural constraints, making them a better fit for most organizations than microservices.

Successfully adopting microservices

The key to success with microservices architecture is setting your sights on agility and flexibility, not on a specific architecture paradigm. Organisations that see success are those that focus on making incremental improvements to skills, technology and application architecture, in service of clear, measurable business goals.

Adoption of microservices requires more than changes to application architecture. It requires significant changes to an organisation's practices across development, operations and data management, as well as investments in complex infrastructure and tooling.

The robust implementation of agile and DevOps practices, including organisational changes to enable a product, not project, oriented model for development work, is critically important. By mastering these practices, your organisation will benefit regardless of whether you ultimately adopt microservices or not.

Improving application agility means adopting modern testing practices and embracing automation throughout the development and deployment process. New skills and new ways of thinking are required for developers, architects, testers and infrastructure and operations staff. After all, there is no point to having an architecture that can deploy changes multiple times a day when your development process takes weeks.

Successful adoption of microservices also requires automated testing and delivery, as well as a "shift left" approach to quality. Testing isn’t just about validating that your software is free of known defects. It's about ensuring that your software is reliable, secure and performant and that it meets expectations.

As the granularity of your services and the complexity of your architecture increase, the traditional approach of testing the application as a whole can become a significant impediment. Therefore, a "shift right" approach is also required to increase agility and embrace validation in production and canary deployments. This requires a high degree of technical sophistication, including the ability to carefully segment user and other traffic, to detect anomalies and to respond quickly.

Finally, as your applications become more fine-grained, you’ll need to invest in creating and developing the capabilities that enable microservices to operate – these are known as the "outer architecture.” Organisations that move toward more fine-grained architectures find themselves dealing with a somewhat paradoxical situation – as the complexity of individual services decreases, the complexity of the surrounding ecosystem increases.

Outer architectures provide a context in which individuals services operate. This effort can — and should — be done in stages, adding capabilities as they are needed to support your increasingly fine-grained architecture.

Delivering applications you need

Don’t treat the adoption of microservices as a large-scale waterfall project. Moving from traditional application architecture to microservices is an incremental process.

Organisations that successfully adopt microservices will have iterated through this process many times, refactoring their architecture and applications to meet the evolving needs of their customers, clients, partners, members, constituents or citizens.

Beware of a project mentality. The reason to move to a more granular, more agile architecture is to enable rapid, ongoing change to an application. If your "project" has an end, then microservices will offer few benefits.

Your goal shouldn’t be to "adopt microservices architecture," or even to convert a specific application to microservices. Rather it should be to refactor your architecture and processes so that you can deliver the applications that your organisation needs.

Kevin Matheny is a senior director analyst at Gartner. His focus is on application architecture, integration and development. Kevin will be presenting on microservices at the Gartner Application Architecture, Development & Integration Summit in Sydney, 29-30 July.