Monolithic vs. microservice architectures for innovation

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.