Adopting microservices can be a great way to split up existing monolithic legacy applications in order to gain some flexibility and accelerate the development of new features. But the learning curve is steep, and you may need to make some sacrifices. Andrew Phillips outlines the potential impact this implementation can have on architecture and operations in an enterprise environment.
When you build a large, complicated application that performs many different functions, it can be difficult to innovate and develop at speed. It’s an approach that sacrifices agility, leaving you with an application that’s unwieldy and resistant to change.
One way you might tackle this problem is to adopt microservices.
The idea behind microservices as an application architecture is very compelling. Why not split up the business logic behind your application into independent units, or microservices, that perform a single function? It gives you a great deal of flexibility, enabling you to change individual pieces without having to worry so much about all the ongoing development work in other, often unrelated parts of the system.
Thinking about Environments in a New Way
The transition to a fundamentally different application architecture is inevitably going to be challenging. The design process will be different. It’s very important to come up with a solid set of guidelines to help your developers understand what’s required to write good microservices.
Microservices allow you to make small, relatively isolated changes so that you can easily test whether those changes work as expected. Beyond automated validation, test and QA will still have to run functional tests, but this can be more challenging because, in order to apply a typical use case to a finished piece of functionality, they might need ten or fifteen different services correctly wired up and running in tandem, instead of simply having to start up one monolithic application.
Deployment shifts from delivering in a single shot to coordinating an army of small components that may be developed separately, potentially by a variety of different teams. Integrating these disparate services and ensuring the right versions are talking to each other and working harmoniously requires regular communication and careful planning. You can’t just update a service without considering dependencies.
An environment with so many more moving parts will also have an impact on operations, because monitoring all these different services is a real correlation and visualization challenge. Can you see all the components? Can you understand where the flows are going, which calls are being made, and which are fast or slow? Can you see where the errors are happening? You’ll need the right technology in place to maintain effective oversight.
Many organizations are embracing container-based deployments using technologies like Docker to help meet the challenges of deploying microservices. Containers are disruptive in that developers can work in an environment that closely mirrors production but also scales to meet peak demands.
In the right circumstances, their capabilities are significant and they can provide excellent support for deploying microservices. But many organizations have legacy systems that must be integrated smoothly, and it’s important to take the time to really assess the needs of your organization before adopting any new technology. Containers should only be used when appropriate, and your operations team must evolve to handle orchestration, which typically means managing swarms of these containers and monitoring their runtime behaviors.
Managing a Hybrid World
Many enterprises looking at adopting the microservices approach will be keen to split up existing monolithic legacy applications in order to gain some flexibility and accelerate the development of new features and other improvements.
But microservices won’t sweep everything away; in fact, you’ll have to ensure that your existing systems can talk to your new microservices-based systems and work in concert. Many of your currently running systems will still be using the same underlying platforms and technology for the foreseeable future.
Most organizations find it difficult to manage their legacy investment in large enterprise relational databases that cannot be easily converted to microservices. In some cases, development teams can switch to NoSQL databases that work well within the microservices architecture, but this isn’t always possible. Make sure you have some resources set aside for integration, and be careful you don’t lose popular features or important functions as you begin to make changes.
You’ll also have to assess what services you want to split out of the monolith. Where are you going to be able to realize the most benefit? Some applications will be better candidates than others. Consider that the transition to a microservices approach is going to negatively impact your ability to deliver new features in the short term. Does the business benefit justify that?
The eventual aim might be truly independent microservices that don’t need to worry about each other, or at least only have minimal API changes that will impact other services—but that’s not going to happen overnight. You need a solid mechanism for tracking your different pipelines, checking dependencies automatically, syncing up the right versions, and highlighting any bottlenecks. Think about visibility, automation, scalability, and control.
Keeping Your Configuration Options Open
There’s no standardized method for microservices. You can approach the problem from different angles and employ different technologies to help you in your quest. You may be able to realize significant benefits from stripping a few services out of a legacy application, or you could adopt microservices wholesale as a strategy for developing all future software.
The key is to find what works for your organization. It may be wise to keep your options open, rather than committing to specific implementation technologies in a landscape that’s still maturing. Done right, microservices will enable you to build better services and deliver them more quickly. But be prepared for a learning curve, especially when you need to consider the impact on architecture and operations in a hybrid enterprise environment.
