In the past month, I’ve talked to technology and business leaders from a number of Fortune 500 companies, and they’ve all asked the same thing: “We want to do microservices, but how?” They’ve seen the success of companies like Amazon, Netflix and Google. They’ve bought into the promise of APIs and containers. In some cases, they’re moving forward with a standardized PaaS solution, or are even trying to use Netflix OSS as the basis of a new enterprise platform in order to reap the benefits of microservices. Is this the right approach?
In the API Academy, we advocate an approach to microservice architecture adoption for organizations that goes beyond technology choices. To start with, I would answer the companies’ question above with my own question: “You want to do microservices, but why?”
It’s easy for technology-led initiatives to get stuck in the weeds and lose sight of the goals that sparked the need for change. There are a number of potential benefits for organizations looking to introduce microservice architecture, but they depend on the structure of the organization, its culture and common practices just as much as on the technology changes they introduce.
Consider a well-established bank that is struggling to meet digitally-driven consumer demand in the face of competition from FinTech startups. How would such an organization take advantage of the microservice opportunity? How would they even start? How would they make the impact last? In order to answer these questions, there are a number of design areas to consider that we also explore in our book, Microservice Architecture.
First off, it is vital to take into account the specific outcomes you are aiming for by adopting a microservice architecture. By settling on specific goals, and developing associated metrics and targets, you will ensure that you stay on track to achieve real business benefits.
You also need to review the scope of the system you will be building through microservices. Defining coherent business domains and cohesive service boundaries will reduce dependencies and improve runtime efficiency.
Designing services from the outside in helps to make them developer-friendly and also more adaptable over time. Good service design helps provide independent deployability, more nimble manageability, and greater replaceability.
Once the more abstract system and service designs are settled, benefit can be gained from determining their foundations. Platform components, shared policies, wide-ranging principles and processes are all fundamental to maintaining stability and security as your microservice implementation grows in scale.
Finally, it is important to figure out how to keep the organizational structure and communication in tune with the software architecture and delivery methodology. Misalignment can impede all benefits, especially over time.
I will explore these microservice design practices through an enterprise banking example in my upcoming live online training, Microservices for the Enterprise, on April 19. This design-based approach examines the considerations of adopting a microservice architecture through five perspectives: outcome design, system design, service design, foundation design and organizational design. If your interest has been piqued by the microservices stories at Netflix, Amazon, and others, but you’re struggling to see how you can apply their lessons within your enterprise, I encourage you to join this training session.