Sign up

Delete Monoliths: the Service-Oriented Architecture

Maximize ROI as you implement SOA

Today, all software comprises complex systems of code working together in a series of operations to accomplish a wide range of tasks. The way developers define, choose, write, integrate and allow code to interact forms what we call software architecture. Architectures have repeating and distinct code patterns that solve specific tasks within certain constraints.

Think of each group of code that accomplishes a single task as a brick. Historically, each brick depends on those around it and especially those acting as its foundation, as you build up the code into your final masterpiece: the software.

The monolith

Photo by Chris Ried on Unsplash

This traditional approach is called monolithic architecture. In a monolith, each brick of code is tightly dependent on all the other bricks. Everything interconnects at the codebase level. It is a monolith in the most basic definition: hulking, stable, and difficult to change.

Monolithic application has a single code base with multiple modules. Modules are divided between business features and technical features. It’s all part of a single build system, which builds the entire application or dependency.

Unsurprisingly, in this traditional context, small changes to any code block can have a considerable impact on the system. The interactions between pieces of code compound the effects, making it virtually impossible to improve the software or make adjustments for clients quickly. The closer to the foundation, the more difficult code is to change.

That’s a problem. Good service = fast service. At least in most fields, but especially when it comes to technology. Software can’t be clunky and still do its job well.

What is a Service-Oriented Architecture (SOA)?

One solution? Service-oriented architecture.

Service-oriented architecture (SOA) breaks down the monolithic complexity into individual bricks that operate semi-independently. Each brick is called a service. These services are then loosely coupled to pass data or coordinate activities. Services can communicate — even when they don’t have directly related functions — but they aren’t dependent on each other to operate.

This interoperability is the critical feature of SOA. Apps and services can be quickly adjusted without tweaking the entire system. They can scale since easily each service is part of a greater decentralized yet coherent system.

Business value matters more than technology

The difference between monolith architecture and service-oriented architecture is more than technical; it’s philosophical. According to the SOA manifesto, service-oriented architecture values:

  • Business value over technical strategy
  • Strategic goals over project-specific benefits
  • Intrinsic interoperability over custom integration
  • Shared services over specific-purpose implementations
  • High flexibility over optimization
  • Evolutionary refinement over pursuit of initial perfection

In other words, SOA is all about maximizing value through automation and incremental change.

Photo by Adeolu Eletu on Unsplash

Switching to SOA for end-users and developers

I regularly discuss the importance of value over everything else. DataoptimizationautomationAI: all just tools that help us maximize value. SOA operates on that same assumption. Technology is essential, but the best code in the world means nothing if it doesn’t profitably achieve your goals.

Luckily, SOA makes that simpler with benefits for both end-users of the software and the developers. Service-oriented architecture:

  • Eases changes and maintenance: Services are independent, so they can be modified according to customer needs without affecting other services.
  • Increases reliability: Services are easier to debug than monolithic code, allowing developers to find and fix errors and be more responsive to client concerns.
  • Scales more easily: Services are reusable, which means they can develop into new applications and functions. Also, SOA allows services to run on different servers, which means that expansions are less constrained by disk availability and the level of interaction between clients and services.
  • Promotes interoperability: Services employ a standardized communication protocol, so platforms can easily transmit data between clients and services regardless of the languages they are built on.

These benefits reduce technological constraints while increasing service quality, maximizing the overall value delivered by software.

Photo by Fotis Fotopoulos on Unsplash

A case for moving to SOA: Evo Market Tracker

You might assume that my own company Evo used SOA from the get-go since its values line up so close to my own. Like most companies, however, we defaulted to tradition when building one of our tools: Evo Market Tracker.

Evo Market Tracker is a tool that allows you to monitor the historical and real-time evolution of the market. You can watch for trends in pricing, inventory, offers, etc., as well as monitor your competition. It is one of our more straightforward tools from a technical standpoint, so we didn’t initially worry too much about the interconnectedness of its code. We had built a high-quality tool that achieved its desired outcomes well, and it wasn’t our primary focus.

With the following architecture, we were able to achieve our goals without much difficulty:

However, in time, we realized that we could provide more value by adding additional functionalities and scaling our services. That’s when we ran into trouble. Making those changes became a much more significant undertaking than necessary due to the code’s interconnected nature. We had to make a change.

The biggest impact with the least disruption

We decided to migrate to SOA. We were not going to re-write the entire code of the tool from scratch, however. That would be incredibly costly with diminishing returns. The tech team had to identify the right piece of code to migrate to maximize the benefits without adding complexity and disrupting service continuity.

The best candidate seemed like the batch code as it:

  • Separates easily from the monolith
  • Does not face the application directly
  • Requires no data storage
  • Uses intensive resources for both data management and scheduling
  • Needs scaling capabilities

It was perfect — time to start the migration. Soon we had broken the batch code down from its monolithic underpinnings to services deployed inside workers (often virtual machines). Instead of a vast, interconnected disk, each function was siloed and then connected through a network.

When a request for that service is issued, the request gets routed to the first available service to be parsed. Workers are organised in clusters, but a tagging system can accommodate more than one service inside each worker. Because they are networked, these can be located anywhere, even in mixed environments. Workers can be physical machines or virtual machines. They can reside in different data centres — even in other countries! Merely switching to SOA makes the software better adapted to the era of cloud computing.

How you can maximize ROI as you implement SOA

Within days of deploy, Evo Market Tracker was faster, required less disk space, and provided better service. We could adjust our code more quickly, which has led to the development of new functions and applications. A previously minor tool in our stack increased in value and allowed us to serve our clients better.

It is easy to look at this as an isolated case rather than a lesson for all companies building software. That is a mistake. While there are times and places for monolithic applications (and architecture offshoots of SOA like microservices), the ideas that drive SOA are always valid. When you develop with service as the primary goal, you’ll consistently achieve a better outcome.

Still not on board? See the whole undertaking in action at Evo University. Our tech team walks you through the entire process of moving from monolithic architecture to SOA for Evo Market Tracker in the Software Architecture course. You can access the code we used and video tutorials that will show you how to complete the process from start to finish. It’s free, so why not enrol?

Even if you are not planning on building your own SOA-based software, it’s vital to understand and adhere to the theoretical underpinnings. Let business value drive the technology and move a little closer to optimal every day. You’ll never go wrong.

About the author

Fabrizio Fantini is the brain behind Evo. His 2009 PhD in Applied Mathematics, proving how simple algorithms can outperform even the most expensive commercial airline pricing software, is the basis for the core scientific research behind our solutions. He holds an MBA from Harvard Business School and has previously worked for 10 years at McKinsey & Company.

He is thrilled to help clients create value and loves creating powerful but simple to use solutions. His ideal software has no user manual but enables users to stand on the shoulders of giants.

Hey! Was this page helpful?

We’re always looking to make our docs better, please let us know if you have any
suggestions or advice about what’s working and what’s not!

Send Feedback