Who better to offer insights on this than Sam Newman, a recognized expert in microservices architecture? At twoday, we had the privilege of hosting a workshop with him on the topic 'Application Modernization: Are Microservices the Answer?' During the workshop, we asked Sam Newman about the future of microservices, common mistakes organizations make when adopting them, and how to determine whether microservices are the right choice for a project.
Let’s take a look to his insights.
How do you see microservices architecture evolving in the upcoming 5-10 years?
According to Newman, the microservices landscape is on the verge of significant shifts. While microservices have been instrumental in helping organizations scale, there is growing recognition of the complexity they introduce. In the next decade, we might see a shift toward simplifying this complexity, especially for smaller organizations.
- More FaaS (Function-as-a-Service) Abstractions: Newman predicts that more people will move toward FaaS abstractions, especially in public cloud environments where it has proven successful in many use cases. FaaS offers a more developer-friendly approach than Kubernetes, which he notes is "not developer-friendly" and often requires expensive platform teams, a burden many smaller organizations struggle to justify. This hints at a growing need for better abstractions in cloud-native development.
- Modular, Hot-Swappable Runtime Environments: If we're lucky, Newman envisions a future where hot-swappable module runtime becomes more widespread. Imagine the ability to deploy modules independently within a single process, offering greater flexibility and ease of updates. He speculates that Java might offer a working implementation of this within the next decade.
- WASM on the Server-Side: WebAssembly (WASM) is often discussed in the context of frontend development, but Newman sees potential for its use on the server side as well. WASM could provide a simpler abstraction for deployments and possibly reduce the complexity associated with containerization, which has become a cornerstone of microservices deployments but also a source of operational headaches.
- Increased Usage of eBPF: Newman also highlights eBPF (Extended Berkeley Packet Filter) as a game-changer for improving the efficiency of security controls and service meshes. eBPF allows running custom programs in the kernel without changing the kernel's source code or loading kernel modules, potentially offering significant performance and security benefits.
Top 3 pitfalls organizations face when transitioning from monolithic to a microservices architecture?
While microservices promise many advantages, organizations often encounter significant hurdles during their transition from monolithic architectures. Newman identifies three key pitfalls.
- Lack of Clear Success Criteria: One of the most common mistakes organizations make is not defining clear outcomes or success criteria before embarking on their microservices journey. As Newman points out, "Microservices should be a means to an end, not an end in and of itself." Without a clear understanding of what you hope to achieve, the process can become an endless tangle of new technologies and complexity. Organizations should always keep their focus on the real-world outcomes that microservices are meant to drive, whether that’s faster deployment times, better scalability, or improved developer experience.
- Overcomplicating the Technical Landscape Too Early: Newman warns against adopting too many new technologies at the start. He suggests starting small: "Get one microservice up and running in production, and change as little technology as you can." By diving in too fast and embracing every shiny new tool or idea, organizations risk becoming overwhelmed, losing sight of the original goals, and bogging down their teams with unnecessary complexity.
- Lack of Continual Investment: Another major issue Newman sees is a lack of ongoing investment. Often, organizations front-load the work when setting up a microservices architecture, but fail to continue investing in it over time. Without ongoing support, the architecture can become brittle and harder to maintain, ultimately underperforming against its initial promise. As Newman reminds us, this ongoing commitment is crucial for maximizing the long-term benefits of microservices – a concept Neal Ford has dubbed the “microservice tax.”
What are the key factors to consider when deciding whether microservices architecture is the right choice for a project?
Adopting microservices is not a decision to take lightly. For Newman, this architecture should be considered a “last resort” in most situations, largely due to the complexity it introduces. Here are his key questions for teams considering microservices:
- What is the outcome you want to achieve? Before jumping into microservices, organizations should clearly define the results they’re aiming for. Is it faster deployment times? Better scalability? Simplified team structures? Microservices are a tool, not an objective, so it’s critical to have clarity on the desired outcome first.
- Have you explored all other options? Newman urges teams to list all the possible ways they could achieve their goals – and try the simple approaches first. This might involve refactoring a monolith, scaling infrastructure, or improving internal processes. “Microservices are a last resort architecture,” he emphasizes, and should not be the default choice.
- Have you tried the easy solutions first? Microservices are inherently complex. If there’s a simpler, less disruptive path to achieving your objectives, it’s almost always better to try that first. Microservices should never be viewed as the "easy" solution, but rather as a sophisticated architecture that comes with significant trade-offs.
Conclusion
The future of microservices promises exciting developments – especially in the areas of FaaS, server-side WASM, and more efficient security models with eBPF. However, the complexity of microservices means that organizations need to approach them with caution, starting small, defining clear outcomes, and continuously investing in their architecture.
Newman’s advice serves as a valuable reminder that microservices are not a silver bullet, and should only be adopted after simpler solutions have been thoroughly explored. As organizations continue to innovate, staying mindful of these pitfalls and developments will help teams make smarter choices about whether, when, and how to embrace microservices.