Microservices / Contributed

Reality Check: 6 Cost-Benefit Considerations When Adopting Microservices

14 Oct 2019 12:48pm, by
Hans Otharsson
As Customer Success Officer, Hans is responsible for the successful global deployment of OpenLegacy and ensuring the highest levels of customer satisfaction. Hans brings over 30 years of experience in legacy modernization to OpenLegacy.

When considering any IT infrastructure changes, the most critical consideration is “Do the benefits and value of a new technology solution override its costs?”

In the case of adopting microservices, the answer is definitely yes, especially as they accelerate time to market of new applications for demanding customers while leveraging the stability of legacy systems.

For those who want to better enable legacy applications to be assets  — rather than speed bumps — in your digital journey, the idea of adopting microservices can be exciting and sobering simultaneously. Adopting a microservices architecture is similar to embracing any other new technology or software discipline: you need the appropriate environment and staff. Adopting microservices does present some unique cost-benefit considerations. Here are six to keep in mind:

1. The Cost of Getting Started

Here are a few of the “getting started” expenses that might be incurred:

  • Personnel: Not all developers will be familiar with microservices architecture.
  • Organizational expenses: Microservices architecture benefits are best realized when administered by small, cross-functional teams.
  • Tools: Containerization and other supporting technologies.

Rule of thumb: Depending on where you are starting from, the “Getting Started” costs might be a budget concern, but the investment is negligible when compared to the downstream benefits, which will be significant. Adopting a microservices architecture quickly defray those costs by returning large amounts of business and technical value.

2. The Cost of Maintenance

Let’s assume that you’re running application monoliths, as opposed to green-field development. Maintaining these applications takes time, because they have interlocking dependencies.

Imagine the login manager fails in a monolithic application. Every other part of the application relies on the login manager, so when it is down, it’s all down. You cannot support a growing number of customers with an application that crashes frequently; while there are workarounds — such as failover services and instancing — they tend to be expensive.

The time it takes to test and update application monoliths means that maintenance has already become a huge part of the traditional IT budget. A sample healthcare IT budget from Gartner shows that 70% of budget expenditures come from simply running the business — increasing to 73% in 2017. This leaves little left over for innovation.

As for adopting microservices, the first part of value generation comes in the form of maintenance advantages.

Rule of thumb: A microservices architecture, with fewer application dependencies and simple APIs, will immediately reduce the time and money spent on application maintenance. Savings on application maintenance have proven to be more than enough to cover the “getting started” costs within a few years.

3. The Cost of Marrying Quality and Speed

The dependencies inherent in any monolithic application will inhibit innovation. Application monoliths don’t tend to play well with newer development techniques — such as Agile and DevOps — that emphasize speed. Any update that’s made to one part of the application affects other parts, so any update will need to be tested thoroughly.

Rule of thumb: Microservices help developers increase the speed of their development without sacrificing quality. This results in a competitive advantage: They will be able to refine their applications faster than those who haven’t yet adopted a microservices strategy. External customers and vendors will build up loyalty to these applications, while internal end-users will become more productive.

4. The Cost of Quality

Here’s how it works: DevOps, Agile, and other modern development practices rely heavily on automated testing. The idea is to give developers or QA personnel the ability to set up several test environments in just a few clicks and let an automated testing program handle most of the effort. DevOps practices expect to rebuild and test quickly, without hassle.

Thereby reducing the need for continuous automated testing of the legacy application and the significant time it takes to rebuild the monolith”

Done correctly, microservices should require zero change to your legacy applications, thereby reducing both the need for continuous automated testing of the legacy application and the significant time it takes to rebuild a monolith.

Rule of thumb: Microservices make for a much cleaner testing process. They’re built simpler, so it’s easier to review their code. As a result, it’s also simpler to perform unit tests. By definition, microservices are small, simple and quick and easy to write; therefore they are equally easy to test.

5. The Cost of Speed

The value of speed is different for every organization, but one can easily appreciate the benefit of a 90% increase in delivered services per year or being able to push out 20 new services every five weeks.

Rule of thumb: Speed of development + Quality of Development = Competitive Advantage.

For example:

  • An insurance organization that leverages microservices to compete in the large insurance quote comparison engines can now be part of a fast-growing digital channel used by millions of shoppers.
  • A bank that offers mobile bill-pay and mobile deposits as a result of microservices can now capture younger generations of new banking clients who can provide lifelong value and add millions in deposits.

6. The Total Cost of Ownership

If you use software that creates microservice directly from the legacy or on-premise system, you can bypass complex ESB/SOA layers that were previously used for legacy integrations. Depending on your architectural strategy and if you are focusing on a few microservices or an entire microservice architecture, your savings can be quite significant — easily in the millions for large organizations.

Rule of thumb: When you decommission ESB/SOA and replace it with independent, directly connected microservice-based APIs, you will always achieve exponential savings by comparison. Since microservice-based APIs are direct, they can perform five times faster; therefore, you may be able to free up hardware processing power as well.

Considering Adopting Microservices? Find a Partner

Find an innovative company that will work with you on a pressing and compelling business use case, where a microservice architecture can bring immediate value. Define the success criteria of a low-risk proof of concept that will give you the ability to envision “what is possible” and the data points to confidently assess the potential and cost/value benchmarks necessary for you to begin your digital journey.

You can read the Open Legacy microservices ebook here.

Feature image provided by Open Legacy.