“We need microservices.”
That’s one sentence heard many times wondering if they are worth it, if we really need them, and whether organizations are ready for it.
There has been so much waste in jumping on the bandwagon of microservices for the wrong or bad reasons, or without the correct foundations.
Many organizations have just other issues to solve first, and don’t need the complexity of microservices, at least for their current maturity and scale.
This article shares the Microservices Adoption Roadmap to perform a step-by-step assessment to decide if it’s the time to start microservices, or not.
Vocabulary: Microservices Definition
There is no time to lose if people do not agree on the vocabulary around microservices; endless and wrong debates would take place on the granularity, opinions or even technology preferences for each person in the room.
“The term “Microservice Architecture”describe a particular way of designing software applications as suites of independently deployable services with common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”
—Martin Fowler, A definition of the architectural term Microservices.
Succeeding the organizational transition to microservices requires to align the actors on the motivations and definition of microservices. That common ground will foster collaboration on a shared vision and objectives.
The microservices vocabulary alignment is achieved with a:
- Microservices vision statement
- Microservices definition
- “Before and after” schemas.
The vision statement must be linked to business objectives that will be assessed in the following step. The definition and schemas are more valuable when using concrete examples of the company, like Zalando did above.
Business: Concrete limiting factors
Microservices popularity made them the standard answer to solve our problems. But without clarifying the why and the problems to be solved, microservices will just create more problems without solving the core ones in the first place.
A typical point raised is the “lack of scalability” with a shortcut that technology scalability is limiting business scalability. As reference, Zalando successfully grew their business to 2 billion of annual revenues with a monolith without scalability issues.
That’s where clarifying the problem you are trying to solve is so important—you may need microservices in the end, but that’s probably not the only thing to address.
Formalize the transformation drivers using:
- Business stakeholders interviews
- Business strategy and roadmap
- Technology landscape and roadmap.
These activities will give you the necessary content to craft a One Slide Problem Summary acting as a written narrative that clarify the context, problems, scenarios and recommended options.
Concrete questions you have to answer:
- How do we compare on the market on Accelerate metrics?
- Which software assets can mostly improve the value proposition?
- What are the limiting factors and root causes on the value stream?
Your analysis will be of impact the more it contains facts and a clear link between business drivers and technology enablers. Use the techniques of value-stream mapping, limiting factors, and self-questioning to challenge your argumentation.
This is the most important step of the adoption roadmap giving a Go/Nogo to further investigate microservices. In many cases, the ranking of problems, identification of causes, and generation of more than the “microservices scenario”, it will be a nogo.
Methods: Governance and reviews
Microservices come with a decentralization that will amplify the limitation of your software delivery processes. Lacking the necessary foundations will generate much more technical debt and complexity, that in the end, will slow you down.
A strong governance with review mechanisms are therefore needed before adopting microservices.
Governance is achieved through reviews that are not necessarily centralized, boring, and slow; they can be implemented in a lightweight model with asynchronous reporting to central instances for visibility and alignment, while simple topics follow a light process.
Reviews are done in different forms like architecture reviews, code reviews, or production-readiness reviews. One particular way is to perform testing using the Agile Testing methodology with both manual and automated tests.
Each of these reviews improve the capability to contain the complexity and keep an alignment while decentralizing the decision-making, and can be implemented without a microservices adoption.
An example to balance the centralized visibility and decentralized decision-making is to perform “Architecture review as peer review” that systematically produces an Architecture Decision Record (ADR).
Other reviews can be performed directly by cross-functional teams that include a live demo with the product owner, and operational teams to get early feedback. A Tech Radar is also a way to implement a whitelist concept to guide technological choices at scale.
Architecture: Modular business urbanization
Microservices aim to build independent services that change in size or functionality with more speed that inside a monolith. That premise is true if the enterprise architecture from business to technology is modular in the first place, to be effectively distributed.
Many teams suffer from monoliths that become too complex with a spaghetti architecture. But the same thing can happen when building microservices without the sufficient upfront urbanization work and culture.
The ThoughWorks survey on microservices adoption contains the following challenges in the top 5 : “Decomposing functions” (38%), “Integrating with legacy systems” (32%), and “Increased complexity” (30%)—all good reasons to ensure modularity.
A modular architecture aims to perform the city planning of business services around key business capabilities. That first level of division can then be cascaded on software components, whether or not in a microservices architecture.
The work consists in drafting the target business architecture identifying functions inside domains to then define applications with their scope of functions, data, and flows. And only then, microservices components can be built.
Domain-Driven Design (DDD) can be used to identify domain boundaries for business and software components. Then mapping techniques and tools are available to document the architecture with diagrams and maps.
A lack of urbanization at that stage must be fixed before proceeding with microservices to avoid creating services that are hard to change and complex to operate. The advice on granularity is to start with microservices before miniservices and microservices.
Engineering: Self-service automation
More components built by multiple teams in parallel, potentially with different technologies, will inevitably increase the workload of existing teams if nothing is done to counter-balance that side-effect.
The issue is that companies do not have an infinite budget—and even if they would have, the cost of delay due to the additional coordination and complexity would reduce the initial value of microservices by going faster.
That’s why self-service automation is required.
The key automation prerequisites for microservices shared by Martin Fowler are rapid provisioning, rapid deployment, and minimal monitoring. Each of them must be provided through self-service automation solutions.
Automation also brings the necessary standardization to microservices with:
- Code and test bootstraps per approved technology stack
- Deployment templates that include standard pipelines and secrets
- Native integrations for monitoring, security, and alerting.
Teams can start using versioned templates and will quickly raise the need to have a developer portal, such as Backstage coming from Spotify. That raises the following points of having a modern stack to provide such automation, and someone to take care of it.
Technology: Cloud-native stack
The goal of microservices is business scalability achieved through software scalability. Even if services are easier to change with modularity, available in self-service, microservices will reach physical limitations if they are not built in the cloud-native way.
Building software in cloud-native enable to deploy independent units of computing that scan up or down depending on the load, with horizontal or vertical scalability. But for this to work, resources must be isolated to enable the individual scalability of components.
Cloud-native software have to provide the following decoupling:
- Deployment with externalization of resources such as secrets, data
- Temporal through event-driven connectors
- Technology using open standards like REST or asyncAPI
- Infrastructure with PaaS or FaaS with infrastructure as code.
These criteria enable components to be built to do one thing well, be adapted and changed depending on the context without reinventing the whole thing. That’s where microservices provide their business and technology value.
Reference models like 12-factor application, Terraform or Cloud providers architecture guides can help in building components the correct way. “Lift and shift” approaches are possible, but they won’t benefit from cloud capabilities not being cloud-native.
Management: Ability to empower
Microservices lead to more parallel implementation by teams having more autonomy in their decisions. Managers comfortable with micromanagement, detailed planning, and reporting are not needed in that context and must have the ability to empower.
Managing the transition to a microservices architecture requires significant leadership and drive from influencers in the organization. The existing managers are useful in adapting the culture and rituals of the different teams to support in that change.
The number one challenge for adopting microservices is “overcoming cultural mindset” at 40%, reinforcing the need to have aligned management layers to effectively drive the cultural change needed for microservices.
“If you are working in an organization that places lots of restrictions on how developers can do their work, then microservices may not be for you.”
― Sam Newman, Building Microservices
Empowering teams require managers able to share the vision and the purpose of the transformation. That alignment is the foundation of giving more autonomy on the right priorities and pushing to continuously improve the outcomes.
Managers must have the capacity to inspire their teams, resolve conflict across teams, and equilibrate business and technology drivers. They are the guardians of business value creation implementing retrospectives rituals for instance.
Organizations with a centralized model lacking trust and autonomy have a high probability to fail at microservices. They may implement a few components at the start, but will lack the capacity to deploy practices across the organization and will not improve speed.
If your organization lacks these managerial traits, it is best to first address the staffing and cultural subjects before moving on to microservices, also creating value by improving the work ecosystem for the teams.
Organization: Dedicated platform role
The creation of more software assets, with more technology and by more people will inevitably increase the complexity to manage. If nothing is done, each team will have its own version of things because “it’s faster on their own”.
While local optimizations can seem positive, leaving that level of autonomy to decentralized teams will in the end slow down the overall cycles of iteration due to a lack of global effectiveness. Each team will reinvent the wheel creating its own maintenance work.
That’s why a dedicated platform role is needed for microservices.
We are talking about a “role” and not necessarily a “team” because growing companies may not have the need for full-time persons in that role (they also may not need microservices, but see the first points of the adoption model).
The platform role is responsible to provide the self-service automated solutions to engineering teams focused on iterating over the value proposition. That role can also help to contain complexity by limiting the number of technologies supported.
Team Topologies is a model that can be used to formalize a platform role. The two main interaction modes in the case of microservices are “self-service” and “enabling” to provide sufficient support to the team, especially at the start.
Growing organizations can then allocate more people to the platform role, effectively creating the “team”. The key point for microservices is to ensure that the role can be correctly fit to support the scope of microservices to implement.
Skills: Continuous learning ecosystem
Last but not least, the skills of the teams is an important checkpoint. Microservices push engineering teams to deliver with more autonomy coming with additional responsibilities, usually outside of their comfort zone.
Software engineers must understand and interact more directly left and right, from the business and operational team. “I’m waiting from operations with the ticket #123” or “I do not interact outside the development environment” are not valid excuses anymore.
“Ninety-nine percent of the failures come from people who have the habit of making excuses.”
―George Washington Carver
Software engineers building microservices must be able to iterate from specifications to operations with ease. If they are not up-to-date in modern technologies, not able to deep dive and solve problems on their own, microservices delivery will be ineffective and slow.
Companies willing to deliver Quality at Speed software must hire and retain talent building a continuous learning ecosystem. It is also a better investment than merely competing on compensations that always have an end and tends to attract short-term individuals.
The prerequisites of microservice like modern technologie, self-service, and empowerment are all contributing to improve the hiring and retention of talent. It is another reason for ensuring their implementation as part of a microservices dynamic.
Organizations can then foster a continuous learning ecosystem with a community of practices, mentoring, or roles of Practice Leader. The important point is to attract profiles with a growth mindset first, and continuously improve the learning ecosystem.
Microservices or not, make Quality Engineering
The adoption of microservices is a challenging transformation journey requiring the alignment of Methods, Architecture, Management, Organization and Skills, which are the five domains of the Quality Engineering framework, MAMOS.
Microservices provide value in the mid-term. That’s why it is important to carefully assess the need and pre-requisites of microservices before proceeding; the first step being to assess a candidate scope to avoid trying to get the whole organization “ready”.
This guide does not cover event-driven, observability, or reliability in the adoption assessment as these practices come with maturity, practice and time on concrete implementations once the journey has started.
We can see that many valuable engineering decisions are not about technology, it’s about deciding what to do , and especially what not to. And sometimes, we are the only one pushing in another direction, but we may also be the only one that is right.
The microservices decision is yours.
References
Mike Loukides, Steve Swoyer (2020). Microservices Adoption in 2020. Oreilly.
Malte Pickhan (2016), Four lessons learned when working with Microservices. Zalando’s Engineering Blog.
Priyank Gupta (2020), Understanding the modular monolith and its ideal use cases. Tech Target.
Piethein Strengholt (2021), Data Domains — Where do I start? Towards Data Science.
Joao Rosa (2020), Using Team Topologies to discover and improve reliability qualities. Xebia.
Katie Smith Milway, Amy Saxton Summer (2011), The Challenge of Organizational Learning. Stanford Social Innovation Review.
Gary Olliffe, Kevin Matheny, (2021), 10 Ways Your Microservices Adoption Will Fail — And How to Avoid Them. Gartner.