You know that microservices can improve application performance, simplify deployment, and enhance scalability.
But here's another, easy-to-overlook benefit that microservices bring to development teams: the ability to experiment more easily with application features and functionality.
Here's how microservices enable experimentation, and why developers should consider leveraging that benefit as part of their microservices strategy.
Why Experimentation Matters in Software Development
Developers tend not to talk about experimentation very often, but the ability to experiment is crucial for building effective apps.
Related: 5 Mistakes to Avoid When Designing a Microservices Architecture
The main reason why is that it's often impossible to predict with total accuracy which features will bring the most value to applications, let alone how best to implement those features. But when developers can experiment with different approaches, they can iterate through different possibilities and approaches until they arrive at the best features, implemented in the best way.
Experimentation could involve implementing a feature, then relying on pre-deployment testing to determine whether it meets development goals. Or developers could build experimentation functionality and release it only to certain users as part of a canary release strategy. They could also push experimental code out to all users to see how well it works, while remaining ready to revert the update or modify the code further if it turns out not to achieve its intended goals.
No matter how developers choose to experiment, however, the point of the strategy is to "play around" with new features or coding strategies and iterate upon them until they are optimized. That beats trying to plan and follow the ideal process from the start, which is in many cases simply impossible because there's no way of knowing what will work best until you try out different approaches.
The Downside of Experimentation: Risk
Of course, experimentation brings with it an obvious challenge: the risk that something will break due to an experiment gone awry.
Related: Do Programmers Still Need to Have Linux Skills?
Developers might write code that turns out to be buggy, for example. Or they may implement a new feature that consumes more resources than it should without bringing value to users.
Risk, in other words, goes hand-in-hand with experimentation. It's the price developers have to pay for the ability to iterate through different ideas and approaches.
How Microservices Enable Experimentation – and Reduce Risk
Developers can experiment with features and coding strategies under any application architecture. But experimentation is easier, and the risk of unintended consequences is lower, when developers use a microservices architecture.
There are two main reasons why.
1. Containing experiments within microservices
The first is that, with microservices, complex codebases are broken into smaller, more discrete units. It's easier to add and test experimental code in a single microservice without worrying that the experiment will break other parts of the application. With a monolithic app, there is a greater risk that experimentation will negatively impact the application as a whole.
Put another way, microservices make it possible to experiment with code on a microservice-by-microservice basis instead of running an experiment that could impact the entire application. That makes experimental code easier to implement and deploy while also lowering risk.
2. Fixing bad experiments quickly
The second way that microservices drive experimentation is by making it easy to revert or fix unexpected problems that could result from experimentation. Because it's almost always faster to deploy or redeploy a single microservice than to deploy an entire monolithic application, a bad experiment inside a microservice can be corrected more quickly.
This means that the risk of causing serious problems due to experimentation is lower with microservices, even if the level of experimentation is the same.
Taking Advantage of Experimentation Through Microservices
Not all applications stand to benefit equally from experimentation. Applications that are highly mature and don't require new features are not great candidates for rapid experimentation. Neither are apps created for use cases where there is a very low tolerance for risk. Relying on experimentation to enhance a mission-critical application is not the best approach.
But for apps where a reasonable amount of risk is acceptable, experimentation is a great way of optimizing the application's feature set and codebase. And it's easier to experiment under a microservices architecture — which is yet another reason to move to microservices if you haven't already.
About the author
Christopher Tozzi is a technology analyst with subject matter expertise in cloud computing, application development, open source software, virtualization, containers and more. He also lectures at a major university in the Albany, New York, area. His book, “For Fun and Profit: A History of the Free and Open Source Software Revolution,” was published by MIT Press.
