Monolithic vs. microservice architectures for innovation

0
348

Yesterday’s standards won’t support the health architecture of tomorrow — here’s what will.

Batch processing and offline maintenance are terms once feared as much as memory and computer power were yesterday. The eruption of microservices and similar technological advances has changed our perception of possible.

A trend has emerged, and it’s the opposite of what convention would tell us. Companies are first building out technical capabilities using a “monolith first” strategy for developing codebases. Monolith-first applications are made up of modules forming software applications that are not independent of the core application. This strategy is later followed by transitioning these monolithic structures into more scalable microservice architectures.

At the surface, it appears that every industry — including financial services, energy, and yes even real estate — has benefited from using the design principles of modularity. Informed technology leaders understand the benefits that microservices offer and are wrapping them around their business models.

Design by service using SOA

Modern programming languages such as Java, Python and C/C++ enabled the development of server-side applications. These languages decomposed complexity by adding abstractions. The language abstractions depended on sharing resources (memory, database, files) to create a single executable artifact, also called monoliths.

Uber followed the lead of Amazon, Netflix and Twitter in the movement to divide monolith application structures into chunks to form service-oriented architectures (SOA). The Uber stack was composed of three stagnant pillars, or monoliths:

  1. Users to products to background checks.
  2. Trips to cities to vehicles.
  3. Payments to documents to promos.

Nearly all of the functionality Uber provided riders and drivers was woven into this value stack. Stability and performance worked well: The ability to scale didn’t work. After expanding to 66 countries and building ecosystems across 545 cities worldwide, Uber was losing software agility. Flexibility, which was once a strength, quickly became a liability.

Flexibility and scale improve by decoupling messaging queues, UI layers, client adapters, databases and external integrated services from the core application.

Still trying to get your head around the value of a microservice? This example might be helpful. Microservices are designed around business capabilities: These independently deployable services have limited responsibilities and run as a suite of smaller services that together comprise a single application. Instead of running one single mega application, you run a suite or group of smaller applications.

Benefits of microservices

Like any architecture style, there are times when microservices offer value and situations when alternatives should be explored. Strong modularity boundaries, independent deployments and technology diversity are the core benefits of leveraging microservices architectures. Another benefit of microservices is the ability to deploy services by fully automated deployment machinery.

Thinking you might already be using microservices? Here are several questions to ask that will help you confirm whether microservices are used in your technology environment.

  1. Is functionality broken into business components, not technical service components?
  2. Are your communications stripped of business processing logic and only distributing messages between endpoints (smart endpoints and dumb pipes)?
  3. Are applications organized around business capabilities?
  4. Is there a central governance over the monolithic application, or is governance decentralized by service?
  5. Does your organization design and build systems or leverage more evolutionary system designs?
  6. Have infrastructure components been automated, enabling independent deployment capabilities by business functionality?

The benefits of the microservices architecture styles are many, including dynamism (splitting load), modularity and reuse (breaking complex services into simple ones), distributed development (distinct development teams working in parallel), and integration of heterogeneous and legacy systems (standard communication protocols).

Assessing your business needs and technical capabilities for the new year? Consider adopting advanced distributed architectures for improved scale.

Previous articleReactive healthcare microservices unleash business scale
Next articleThe dabbawala approach to healthcare delivery

Peter is a healthcare business and technology executive, recognized for Digital Innovation by CIO 100, MIT Sloan, Computerworld, and the Project Management Institute. As Managing Director at OROCA Innovations, Peter leads the CXO advisory services practice driving digital strategies.

Peter was honored as an MIT Sloan CIO Leadership Award Finalist in 2015 and is a regular contributor to CIO.com on innovation. As Head of Information Technology, Peter was responsible for Connecticut’s Health Insurance Exchange’s (HIX) industry-leading digital platform transforming consumerism and retail oriented services for the health insurance industry. Peter championed the Connecticut marketplace digital implementation with a transformational cloud-based SaaS platform and mobile application recognized as a 2014 PMI Project of the Year Award finalist, CIO 100, and awards for best digital services, API, and platform. He also received a lifetime achievement award for leadership and digital transformation, honored as a 2016 Computerworld Premier 100 IT Leader.

Peter has a B.S. in C.I.S from Bentley University and an MBA from Quinnipiac University, where he graduated Summa Cum Laude. He earned his PMP® in 2001 and is a certified Six Sigma Master Black Belt, Business Relationship Management Professional (BRMP) and Certified Scrum Master. As a Commercial Rated Aviation Pilot and Master Scuba Diver, Peter understands first hand, how to anticipate change and lead boldly.