Good things come in small packages: how a microservices architecture helps continuous integration and continuous delivery

If there are two life lessons that I have learned from my experience with long distance running, they are this:

• If you find yourself doing something that is painful but necessary, do it more
• Trade long term debilitating painful events for more frequent, but shorter and less debilitating painful events

Of course, these lessons aren’t unique to running. In fact, both of these tenets are driving two of the most popular trends in software development today: continuous integration (CI) and continuous delivery (CD).

Continuous integration, as defined by Wikipedia, is the practice of “merging all developer working copies to a shared mainline several times a day.” The idea behind this best practice is for a developer to develop, build, and test code as often as possible to avoid major integration issues with other developers’ code down the road.

Along similar lines, continuous delivery is the notion that new features and functionalities should be in a state of deployment readiness so that the actual deployment process does not require bringing the system down or disrupting users.

Together, CI and CD promise to make software development a lot faster, more resilient, and, in general, a much better experience for everyone, especially the end customer/user.

So what does a microservices architecture have to do with CI and CD?

Well, imagine you and your team are responsible for a cloud-based application that has been built on a classic monolithic architecture. And that in the last five years or so, the code base for your platform/application has grown to hundreds of thousands of lines of code.

Continuing with this scenario, a very big and very important customer is now requesting a small new feature. After writing, building, and testing the code, you push your changes out to a new build that—you guessed it—promptly breaks due to mismatched code integration or incompatibilities with existing libraries. So you painfully retrace your steps and, several weeks later, you finally fix all issues and generate a successful build.

It’s not over yet though. Once you deploy this new build to production, you now have to bring down the entire system to make it available to everyone, causing massive disruptions. This whole process has become of those long term debilitating painful events I mentioned above—all for a small new feature!

Now imagine your application is built on a microservices architecture: a loosely connected platform where the majority of features are built as independent and modular applications running in their own containers. In this scenario, you would have small teams developing, building, and testing—independent of all previous written code in a far more efficient fashion. Even better, because these features are written as microservices running in individual containers, you could deploy them independently without bringing down the main application. You test frequently (CI) and deploy continuously (CD) and, while there may be a few snags here and there (if you’re counting, these would be the more frequent, but less debilitating painful events), but overall, everyone is much happier.

We built the Liaison ALLOY™ Platform on a microservices platform because we understand the importance of responding to ever-changing requirements in the EAI and B2B integration space in an agile way. When one of our customers requests a new feature or a protocol that is specific to them, we’re able to leverage our CI and CD best practices to meet their needs in the shortest possible time. Can your integration platform do that? If you’d like to learn more about ALLOY and its use of microservices, I invite you to check out our recent brief titled Leap Into Adaptive Integration with Microservices.