A business case for microservices

Business need is the true arbiter of technology choices. We can use less than perfect tech if we can get it to market and make money with it. In fact, many arguments about Java vs. .NET, monolith vs. microservices, agile vs. waterfall, ultimately resolve down to which tools can our effectively use to meet our business goals.

Mike Amundsen of API Academy recently posted an article by hyperscalability.com on the pros and cons of Monolith vs. Microservice architectures. I had been pulling together an article that would have basically duplicating that article, but I didn't see value in repeating the topic. So I would like to focus on a different aspect of this architectural choice.

Monolith is familiar, well understood, easy to find and hire tech skills for, and proven over years of product development, so from a business perspective: low short term risk. The problem with monolith is that it is beautifully sculpted from marble: making significant changes eventually requires starting over. As hyperscalability.com suggested, the weakness is in the totality of change - if we want to improve one concern, such as security, or scale, we have to change it for the entire monolith.

Microservices comes along to solve many of the issues of upgrading monolithic architectures. On a microservice architecture, any part of the system can be independently upgraded without causing damage, change, or regression to the other parts of the system. Microservices can eliminate the frustration of ruling out pursuit of certain business opportunities because the cost of rewriting the monolith is too high. In short, the loose coupling of system elements helps us future-proof our tech stack, making it easy to change, scale and add completely unrelated services, supporting an ever larger business model.

The fallacy of a discussion of monolith and microservice is that from a business perspective, it should never be an either/or decision.

The Internet of Things (IoT) has given us a mobile first world. Most devices need small discreet data services. We surface those either as microservices built in Node, Python, Java/Spring, or ASP.NET Core; or we build RESTful services on top of our monolith to provide small discreet interfaces that look like microservices, taste like microservices... From a business perspective, the requirement is met whether we use monolith or microservice.

Most implementations of microservices today end up relying upon on non-microservice components. - mostly because of the cross-cutting concerns. Cross-cutting concerns include security, operational scale, and most importantly, data processing.

• Security: Almost every effective security implementation in enterprise architectures today is monolithic, so implementing security for microservices is costly, as we require either a microservice implementation of security (see the weakness for operational costs), or we need an interface to the monolithic security implementation.
• Operational scale: how do we cost effectively manage dozens, or hundreds, of independent code bases and deployment infrastructures? If we need 50 people to manage one monolith, how many do we need to manage dozens of microservices? How do we release, operate, monitor and configure so many infrastructures?
• Data Processing: RDBMS, whether SQL Server, MySQL, Oracle, PostgreSQL, etc, are, by design and business requirement, monolithic. We could implement our own Repositories in Java/Spring, Sqlite or EntityFramework, but expedience will almost always drive us to use an RDBMS. First, why roll our own repository when an RDBMS can already do everything we need? Second, we need the data in the microservice in other forms to effectively process analytics, machine learning, AI.

So from the business perspective, monolith will get us going now with little risk and known costs. Microservices will future-proof our architecture so new business opportunities don't require massive reinvestment. Can we have both?

One of the accepted design patterns for microservices is shared data microservices. In this pattern, we do indeed use a single RDBMS for the data platform. Using the Repository approach, the Java/Spring or ASP.NET EntityFramework treat the persistent data store as a Data Service, and isolates to only the data for the microservice. But the RDBMS is also available to the other parts of our tech stack, so we can easily build the data pipes between our microservices and our data lake, analytics, and machine learning platforms.

Extending the principles of a shared data microservice a bit further, we can treat each of the cross-concerns as a service. As we have often done in the past, we can put an API on top of our monolithic security solution, our monolithic logging solution, our monolithic reporting solution, and our monolithic FP&A solution, and allow each microsevice to invoke those concerns as a service. Further, leveraging a modern framework, we can now inject our security, logging, audit and reporting without having to write code more than once. We end up with all the advantages of loose coupling across our enterprise, without reinvestment in our cross-concerns. Eventually we might wish our other solutions were internally loosely coupled, but our CFO will appreciate breaking reinvestment into smaller bites.

But John, you say, this isn't microservice. And I say, business needs are the ultimate arbiter of technology choices. Do we care if we are monolith or microservices oriented, or do we really care that we have all the advantages of monolith in time-to-value and reduced business risk, and all the advantages of microservices in future proofing our implementation to extend product life expectancy and minimized reinvestment requirements?