Monolithic vs. Microservices: a guide to application architecture

Businesses today use a host of SaaS applications — the average business uses 137, according to Blissfully’s 2020 SaaS Trends report. Those applications generate terabytes of data. Oftentimes the data in multiple platforms can be related — such as an address on a credit card used for an ecommerce purchase, which is also useful as an address for a shipping platform — and that ecommerce transaction itself can be tracked by a company’s analytics platform. 

Businesses have two broad choices when it comes to rolling out technology stacks: deploy a single platform that combines many functions, or take a best-of-breed approach that uses microsystems to integrate discrete services from different vendors. What are the pros and cons of each approach? 

What is monolithic architecture?

Monolithic applications are designed to handle multiple related tasks. They’re typically complex applications that encompass several tightly coupled functions. 

For example, consider a monolithic ecommerce SaaS application. It might contain a web server, a load balancer, a catalogue service that services up product images, an ordering system, a payment function, and a shipping component.

As you can imagine, given their broad scope, monolithic tools tend to have huge code bases. Making a small change in a single function can require compiling and testing the entire platform, which goes against the agile approach today’s developers favour.

What are microservices?

In contrast to the monolithic approach, a microservices architecture involves smaller applications deployed independently as loosely coupled services, tied together through application integration. With microservice applications, the business logic may encompass multiple platforms, including software as a service, on-premises databases, and in-house-developed applications that meet needs that no SaaS application handles. 

From a software engineering perspective, microservices can be simpler to develop. They’re smaller in scope and therefore smaller in size, which makes it easier for developers to improve them through continuous integration and continuous delivery (CI/CD). They can be written in any programming language. And they can communicate with other microservices through APIs.

An application programming interface (API) is a set of programming calls that expose the functionality of an application to developers. APIs make it simpler to develop integrated applications by offering an easy way to pass credentials and data between applications.

Monolith vs. microservices 

So which architecture is better? The answer depends on the needs of each individual organisation. Businesses should consider several criteria:

• Ease of implementation — You might think that monolithic systems would be easier to implement, since the software comes from a single vendor. That’s not always the case. Because monolithic systems tend to be complex, they may be as difficult to roll out as multiple individual platforms. One area where they can have an advantage is that monolithic systems are a one-stop shop for support — but that’s only an advantage if the vendor has a reputation for good support.
• Vendor lock-in — Typically, monolithic systems attempt to cover a broad set of related functions. A monolithic web hosting platform, for instance, might include not just a web server that handles HTTP requests on the server side but also firewalls, load balancing, and a content distribution network. But because they’re designed to “do it all,” monolithic systems typically don’t work well with other systems. Which ties into the next point ... 
• Control and ownership of their data — Monolithic systems don’t make it easy for organisations to integrate the data from their systems. You typically can use your data only within the monolith. For example, a monolithic analytics system that includes data integration, ETL data pipelines, a data warehouse, and analytics software may not provide tools that permit organisations to access their own data to integrate it with other systems, or run analytics using different software.
• Return on investment (ROI) — There’s no point in rolling out any application without a positive ROI. Whether you’re developing your own applications or deploying SaaS solutions, your software engineering team can create microservices relatively quickly, roll them out as they’re ready, and let customers (external or internal, depending on the application) begin using them. You can get a faster time to market and a positive ROI from your services incrementally as you deploy them.

The industry seems to be moving from monolith to microservice, because it’s hard to combine in a single platform all of the capabilities that businesses need and want, and that work the way they already run their businesses. Most businesses have a better overall experience by deploying the best or most suitable solution for specific needs, and tying them together via application integration.

Application integration is something Talend knows a lot about. Our software can help your organisation implement point-to-point SaaS integrations and build scalable modular APIs as part of an event-driven architecture. Learn more about how Talend can help you with application integration.