The Primary Reason for Moving to Microservices Should Be Non-Technical

This is part of a blog series of Improvement Interactive’s journeys in enterprise application development. Improvement Interactive develops large, complex systems for a variety of clients. Today’s installment chronicles our experience working with a large, multi-national company handling over 21 Billion in transactions per year.


As microservices architectures gain more attention in the software development industry, development teams are cautiously weighing the pros and cons, as we at Improvement Interactive have recently experienced. It turns out that after many conversations about how to best clean up a legacy system for one of our clients, our primary reason for moving to microservices was not technical at all.


Transitioning from Monolithic Application

Our clients’ current legacy system is a traditional monolithic application, where each deployment is a release of large batch changes made by the development team. To make significant improvements to the legacy system, we created an updated application that would run in tandem with the old, with users transitioning over to the updated application when complete. A sync server was created to sync data from the monolithic application to the new application running in the cloud.

Using our internally created cloud platform, Cycligent to manage the continuous delivery pipeline, we automated the testing, build, and deployment processes. Our developers are able to automatically deploy code to test environments whenever they push code changes to the repository. Major releases are pushed to production on a regular basis with automated promotion from QA to production, reducing the risk associated with each release.


Monolithic Bottlenecks

While our continuous delivery system was working efficiently, the biggest bottleneck was planning for our major releases for the updated application. When new features or bug fixes were ready to deploy, our development team could not implement those new changes because of other projects already in progress. Due to the lack of segmentation in our application, it was difficult to separate the changes that were still in progress from the changes that were finished and ready to be pushed. Also, in the event that we needed to implement a hotfix, our current infrastructure and process required a full release of the application instead of just the segment that needed to be changed.

High priority changes were having to wait for lower priority changes to be done, but without microservices we could only do what we call “whole hog” releases. Production and momentum were constantly impeded.


Team Production and Momentum

The primary reason we adopted a microservices architecture was about increasing the production and momentum of the development team. We realized that we could provide more value for our client with a microservices architecture because we could develop higher priority components faster. Eliminating the bottleneck and deploying changes quickly let our client see the value of what we were creating sooner.  Our team production increased significantly; by segmenting the application into functioning, isolated components, each team was able to push changes when they were ready.

We quickly adapted Cycligent to orchestrate our microservices infrastructures for all of our clients, saving us significant time when transitioning and managing microservices applications.


1452055847_twitterThe Primary Reason for Moving to Microservices Should Be Non-Technical #microservices #agile via @iicorporate


The Microservices Trade-Off

The main trade-off that developers will point to when discussing microservices is the increased distributed systems requirements. In theory, it’s more difficult to manage and no efficiencies are gained.

In our experience, having a well-designed continuous delivery pipeline scales with a microservices architecture and only causes a nominal amount of oversight when functioning properly. Although work was required in the beginning to set up the automated systems, tests, and infrastructure, our continuous delivery system using Cycligent did not cause an added burden.


The Drive Toward Customer Satisfaction

The end goal for our team was to increase the value that we gave our client. We saw an opportunity for microservices to increase the speed in which we could deliver results.

“Customer satisfaction by early and continuous delivery of useful software.”

It is important to understand that not all decisions are solely technical decisions. It is also important to weigh the non-technical benefits when making a final decision. Will microservices increase the speed and agility of the development team? If so, will this increase in agility lead to better business efficiencies? Do the technical burdens outweigh the non-technical business benefits?

The answers to these questions will vary from project to project. It is important to understand all of the benefits and potential pitfalls. In the end, however, we found that it was most important to consider what value the customer may gain when making the transition to microservices.


About Improvement Interactive

The core Improvement Interactive team has worked together for over 20 years. We have a proven track record of delivering enterprise software solutions to our customers. Improvement Interactive combines software development and process improvement to provide solutions to your business. Improvement Interactive stays with you for the long-haul, helping you to manage change and achieve success. We integrate scalable, secure technology into your processes and existing IT environment.

One client manages more than 14,000 units and more than $20 billion in transactions annually with an Improvement Interactive built system. For another, we built a worldwide training management system spanning 40 countries and six continents.

Improvement Interactive is about business. We use technology to help you improve your business.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>