Done correctly, microservices and microservices architectures help DevOps teams manage businesses' conflicting...
demand for speed and safety of application development and deployment. On a typical large system, DevOps teams must compromise between speed and safety regularly, said Irakli Nadareishvili, senior director of technology for Capital One. At API World 2017 in San Jose, Calif., he shared how Capital One has accomplished that compromise by implementing microservices and microservices architectures.
Not all web or cloud services are microservices. Only those services that enable speed and safety at scale and in harmony qualify, Nadareishvili said in a pre-API World interview. In this Q&A, he describes Capital One's best practices for and evolving use cases and drivers of microservices transformation. Nadareishvili is co-author of Microservice Architecture (O'Reilly 2016). At API World, he is co-speaker of the session, "Implementing microservices at Capital One" with colleague Mark Donovan, senior director of software engineering.
Microservices architecture is a collection of microservices interacting in a certain way. "And therein lies [the] root cause of the speed-safety compromise: For the end result to actually come together, the work of the various teams need to be coordinated," he said. In a microservices architecture, the system is designed as a natural collection of inherently autonomous components. "I believe the core tenet of microservice architecture is about reducing coordination of different parts, in a natural way."
What do you find to be the most fascinating part of your work in microservices transformation projects?
Irakli Nadareishvili: One critical aspect of microservicization is that it is more about cultural transformation -- changing the accepted ways of doing things in an organization -- than it is about technical transformation. Cultural transformation is always contextual: You cannot just download a set of tools or best practices from an early microservices champion like Netflix and declare victory when you start using them. Implementing microservices properly takes a much more nuanced approach.
Candid conversations with teams on their way of transformation helps a lot. At Capital One, on the road to microservices transformation, we [are doing] microservices workshops. In these workshops, we invite cross-functional teams of developers, architects, product managers and scrum masters to an intensive, two-day conversation covering key aspects of implementing microservices in a safe way. [Participants] have different degrees of experience with microservices. Some of them already have hundreds of microservices in production, but want to find even better ways for designing and deploying them, or want to share their experience. Others may be just tipping their proverbial toes into the architectural style.
Irakli NadareishviliSenior director of technology, Capital One
The blink of excitement I see in the eyes of people I talk to, loudly saying, 'This makes sense! This is so liberating!' is priceless.
From your experience, what is the primary driver for adopting microservices and a microservices architecture? Has that changed over the last couple of years?
Nadareishvili: I think we are still in very early days of microservices adoption. The main use case is still the elimination of coordination to safely increase speed and freedom of development. However, the need for containerization is also driving additional adoption of microservices. Significantly more people [are] interested in containerizing applications for the deployability benefits. Due to the nature of containers (e.g., Docker), putting large monoliths into containers doesn't make a lot of sense. So, containerization will likely drive wider adoption of the microservices architecture. I sometimes joke that containers are the 'gateway drug' to microservices.
Which new technologies related to software containers are sparking your interest now?
Nadareishvili: An extremely exciting development is the power that various container scheduling and orchestration solutions bring to a software architect's table. Aside from the obvious benefits in more efficient resource utilization versus VM [virtual machine]-based deployments, they also allow very interesting approaches in monitoring, security and standardization/compliance. Specifically, the notion of 'pods' in Kubernetes allowed service mesh solutions, such as Istio. Such novel solutions allow us to dramatically rethink how we approach security and compliance in a large distributed system. These are very exciting developments with great potential.
What new technologies are emerging that help organizations do microservices transformation well?
Nadareishvili: Due to the requirement of independent deployability, microservices pushed for autonomy of data models. The traditional approach of integrating system components via a central database is being forcefully challenged. Conventional, relational data-modeling approaches are facing strong emergence of alternative data-modeling approaches, such as event sourcing and Command Query Responsibility Segregation.
We are very lucky that extremely powerful, event-oriented data systems, such as Apache Kafka, emerged almost in parallel to the needs that event sourcing created for such tools. I don't think the two developments were necessarily coordinated, but it was a very helpful coincidence.
What is the future of microservices and the internet of things?
Working with cloud app performance and microservices
Looking at deployment options in 2017