Obstacles to overcome when deploying microservices
In this article we’re going to take a broad look at why you might move to implement microservices, and then discuss some of the challenges you’ll have to deal with.
The idea of breaking your application down into a set of services that can be developed, tested, and deployed independently is growing more popular. A microservices approach offers a range of potential benefits that fit neatly with the modern focus on speed and agility in application development. But, in practice, there are obstacles to be overcome for a successful implementation.
Microservices can really speed up development and, if you’re able to design them to be independent of each other, simplify your release schedule, making it possible to roll out new features more frequently. Because different services can be developed, tested, and deployed independently of each other, there’s less wasted time and the risks are smaller. You can deploy and, when necessary, you can roll back quickly and easily.
If you split your application into multiple, independent services it’s possible to scale a particular microservice. You might boost performance by running it on more powerful hardware, or by running multiple instances in parallel. A monolithic system with a bottleneck can’t easily be scaled in the same granular way.
There’s no need to commit to a particular technology stack long term. You can maintain agility with a modular framework that enables developers to pick the right tools for the job. Different teams should be free to choose what works best for them.
Having said all that, microservices do present some interesting challenges.
Configuration and dependencies
Microservices do not magically make your business process simpler, so in many cases you’ll be trading internal complexity for external complexity. You need a plan to deal with a complex network of distributed, comparatively simple components. It’s worth remembering that, just because a microservice may be independently deployable, it will still likely need to talk to many other services to carry out a complete business process. Everything has to work together, and you’ll want a single overview of your new deployment and runtime dependencies, and associated configuration.
With an increased set of delivery pipelines to handle, you’ll need to automate to reduce the chance of errors. If one service fails, you need the flexibility to be able to stop it going live without all the other changes in the pipeline – to other, related services – grinding to a halt. It’s vital to keep tracking environment and version compatibility. You have to consider the potential impact of new features on running services, and test new versions of components together.
Building a resilient system will require new tooling to master pipeline coordination. You need something that’s capable of moving beyond the heavily procedural approach of workflow-based deployment tools to a new, declarative delivery model purposely designed to handle dependencies. You need to be able to see the big picture, predict where the risk lies, and take action to mitigate it.
Overcoming the challenges and realizing the benefits of microservices is also going to take time, analysis, and careful planning. It’s not just about introducing new tools and technologies, it also necessitates new development practices, governance, and a commitment to organizational change. Working out whether the rewards outweigh the risks can be tough.
Are microservices right for you?
Microservices can really boost your Continuous Delivery efforts, enabling you to deliver more features at a faster rate without compromising quality. It’s an approach that dovetails neatly with Agile methodology and the DevOps trend towards empowered teams with end-to-end insight and responsibility. With the right microservices infrastructure in place, you can also factor in easier installation, configuration, deployment, updates, flexibility, and scalability.
Deploying microservices – how to handle complexity
But microservices are not for everyone, and like any other change to your application architecture, processes and organization, there are risks. You need to feel that the undoubted benefits that it can deliver are relevant for you. No approach, technology or architecture should ever be adopted for the sake of it.
If you’re in a situation where it’s practically impossible to make even small changes to your system, and there’s a business need to make changes more and more frequently, or if you’ve hit limits regarding the scalability of your monolithic applications and you know you’ll need to scale quite a lot further, then it really makes sense for you to consider microservices.