Microservice architecture: A future-proof composable alternative to monoliths

Coined in 2014 by software development thought leaders Martin Fowler and James Lewis, the term “microservices architecture” describes the framework for developing applications that combine several autonomous, cloud-native tools to build out a loosely coupled tech stack. Each tool or “microservice” serves a single function and handles its own data storage. This architecture enables DevOps teams to combine leading tools from various vendors as well as those that are self-built. The end result is a high-performing stack that enhances business capabilities to a level that monolithic architectures struggle to provide.

Microservice architecture is also referred to as composable architecture, modular architecture, MACH architecture (microservices-based, API-first, cloud-native, and headless), and best-of-breed architecture. In many ways, microservice architectures are a more modern evolution of service-oriented architectures (SOAs) and layered architectures, which include the following layers: data sources, business logic managed by digital platforms, and a user interface/presentation layer that creates the customer experience.

Common components of microservice architectures:

All-in-one monolithic architectures attempt to serve all business needs with one solution. This forces teams to work with the functionality available rather than the best tools for the job. Microservice architecture allows teams to integrate the technology most appropriate for their needs. For instance, Contentful’s App Marketplace includes a library of function-specific microservices that can be added to your tech stack with the click of a button.

To view specific tools within each category, simply click on the category name. Once you’ve explored the Marketplace, you can create a free Contentful account to begin building out your architecture.

Analytics	Artificial intelligence	Collaboration	Commerce
Delivery and deployment	Developer productivity	Digital asset management	Editor Productivity
Optimization and personalization	Search	Translation	Video

The independent tools, modules, and components that make up a microservice architecture communicate and share information with one another via application programming interfaces (APIs). This information sharing occurs through either synchronous or asynchronous messaging.

How APIs work in Contentful

To better illustrate how APIs work, let's look at Contentful’s core APIs, each of which connects Contentful to tools and services across a user’s tech stack. The Content Delivery API allows content within the platform to be accessed and displayed within other applications. The Content Preview API fulfills a similar role but specifically addresses unpublished content. It displays drafted or recently published but not yet deployed content in its frontend format for review. The Content Management API and the Images API share content updates across applications and manage digital asset delivery and transformation, respectively.

To learn more about Contentful’s core APIs, watch this short demo in The Contentful Learning Center.

Types of APIs

In general, APIs fall into four categories: open, partner, internal, and composite. What differentiates an API in one category from that of another is its accessibility and use case. While APIs can have different architectures, representational state transfer (REST) over the years has become preferential to more antiquated alternatives such as simple object access protocol (SOAP) and remote procedural call (RPC). APIs following this architecture are called RESTful APIs or RESTful web services.

While RESTful APIs are still extremely popular for their reliability and security, developers are beginning to adopt GraphQL, a query language and API runtime, at impressive rates. With GraphQL, developers can create multiple custom requests at once. This shrinks total API calls which often promotes efficiency.

It's not uncommon for companies using microservice architectures to utilize a serverless API gateway. An API gateway eliminates API call complexities and ensures each request is routing to the right backend service.

Over the last ten years, microservice architectures have become increasingly adopted over monolithic architectures for their scalability, “future-proof” flexibility, and the speed at which they enable applications to be added or augmented within a tech stack. A microservice architecture is the ideal architecture pattern for remaining competitive and relevant to consumers in the digital-first world. According to Gartner: “By 2023, organizations that have adopted an intelligent composable approach will outpace the competition by 80% in the speed of new feature implementation.”1

Attributes of microservice architectures

Agile

With the ability to easily connect different services and tools, teams no longer have to build high-value functionalities from scratch. Nor do they have to be managed or launched in tandem. Microservices can be deployed individually. In this way, a single page, site, or experience enters a continuous delivery pipeline where load speed isn’t affected by latency that other tools in the technology stack might be experiencing. Asynchronous load times support better customer experiences by serving content at the exact moment it’s available.

Autonomous

Because these tools are loosely coupled, it’s possible (although perhaps not always strategic) to use different programming languages and frameworks for each one. For development teams with varying preferences and skill sets, this can enhance efficiency and employee satisfaction.

Easy to manage

Instead of managing a huge piece of software at the enterprise level, different teams within the organization can manage the individual services they use most frequently. This is possible because each tool has its own codebase and database. Theoretically, each small team managing a service doesn’t have to consult or get approval from another team to make changes. They can make decisions to alter, scale, or remove services almost instantaneously.

Flexible

Microservice architectures can mirror the ebb and flow of a company, its competition, and the industry it's situated in. Should technology needs change, rendering a single service obsolete or requiring the addition of a new one, it’s possible to swap microservices with little disruption to other tools or the final product.

Reusable

As digital landscapes evolve to meet advances in technology and changing customer preferences, microservice applications prove invaluable. With the option to reuse these applications and the content they use, it's easier to expand to new channels and support additional projects. With microservices paving the way for scalability, teams can reuse and iterate on existing components, limiting additional coding and shrinking development time and costs.

Risk-averse

When one tool fails in this setup, it doesn’t disrupt the entire system. The larger digital experience is still delivered — only the part of the application disrupted is unavailable to users. When APIs are connected to services strategically — a load balancer is introduced to reroute calls at high traffic times and applications are given unique error identifiers — figuring out which tool is at fault within the entire system is straightforward.

Speedy and secure

This architectural style accelerates an organization's speed to market by supporting parallel workflows and continuous integration, continuous delivery pipelines. With this type of pipeline, code is automatically tested before it’s pushed live. Open-source orchestration platform Kubernetes, when paired with Docker for runtime, is often used to manage and deploy applications.

While both monolithic architectures and microservice architectures support application development, they have several defining differences.

Structure

In a monolithic architecture, a single application with a relational code base aggregates all the functionalities needed to create the application. In microservice architectures, multiple applications with different functions and code bases work together to support the creation of an application.

Deployment

When it comes to getting an application up and running, monolithic architectures present more difficulties and have longer cycles than their microservice counterparts. Because monolithic applications are so large, continuous development isn’t usually an option, and improvements must be made in one large, scheduled motion. Scheduling deployments strategically is important with monoliths as it requires downtime. The length of this downtime varies based on how large the monolith is. Because lengthy downtimes during high-traffic times can wreak havoc on user experiences, microservices — and their CI/CD pipelines — support scalable delivery.

Scalability

Because monolithic applications are supported by a single vendor, they are slower to scale than microservice applications. The vendor behind them likely doesn’t have the bandwidth or resources to build and launch high-performing tools and functionalities to support business needs as they quickly arise. Rather than having the option to integrate a purpose-built tool from another vendor — as can be done in a microservice architecture — monolithic platforms leave few options: 1. Wait for the vendor to add the tool or functionality that meets their needs 2. Create a workaround. The latter demands developer time and resources and often presents issues of security.

Flexibility

With monolithic architectures, processes are tightly coupled, which means scaling or adjusting will impact the entire architecture. This rigidity extends to workflows. Monolithic architectures lock teams into waterfall processes where each stage of an update must progress systematically from one team or contributor to the next. Teams don’t have the option to tailor processes to their unique preferences, which can slow time to market significantly.

From a development perspective, monolithic applications are more rigid than microservices as they require users to adopt a single programming language across the entire suite. This restricts which tools teams can integrate, limiting capabilities or forcing workarounds. It can also impact team productivity and employee retention should internal developers prefer a different coding language.

Configuration

Where monolithic applications have an advantage over microservices is their ability to be used out of the box with little configuration or development. This is a strong selling point for companies creating basic applications and those with little developer resources. With microservice architectures, knowledge of how to properly connect and set up each tool — either from in-house developers or third-party digital agencies — is needed.

Key differences between monoliths and microservices

When it comes to building microservices, the applications introduced will vary from company to company and are based on business needs, projects, and industry. The common thread is that all digital experiences and applications need content.

Content — not just text but images, videos, and other media — truly connects companies with the customers at the experience layer of their microservice architecture. Content contextualizes the outputs of independent services within the tech stack and a content platform ensures that content is consistent across a brand’s entire digital footprint. Check out our “Content reusability workbook” to see how content modeling lays the foundation for consistency.

As an API-first content platform, Contentful delivers extensibility, flexibility, and speed. It easily unites third-party and custom-built tools and streamlines their orchestration. With content and tools in a single, easily accessible location and no silos in sight, Contentful users across all roles — developer, content creators, strategists — can spend less time on redundant, managerial tasks and troubleshooting, and zero in on creating, iterating, and launching engaging experiences instead.

Contentful features that extend microservice architecture benefits:

• App Framework Contentful’s App Framework allows you to integrate a content platform into your existing tech stack and add new third-party or custom-built services as needed. The framework’s extensive tooling also allows developers to customize Contentful’s UI to optimize editorial experiences for content creators, tailor workflows, and launch one-of-a-kind apps that address unique business needs.

• Reliable APIs With Contentful’s well-documented APIs — which extend beyond the core APIs outlined previously to include the following: Content Delivery API, Content Management API, Content Preview API, Images API, GraphQL Content API, User Management API, and SCIM API — everything stored in the platform is secure and just an API call away. Our extensive documentation on these APIs and other elements of our content platform serves to further speed up app development processes and developer efficiency.

• Open-source Forma 36 design system Half of the battle of working with a headless, microservice architecture is customizing it so that it looks great to not just end users but non-technical team members working within the tools. Contentful’s Forma 36 design system makes quick work of this by reducing the developmental overhead associated with creating the UI of custom-built apps or extending functionalities within Contentful.

See what it's like to work in a content platform built to support modern microservice architectures. Try out Contentful for free today.

Global service providers, technology companies, and corporations including Amazon, Netflix, Spotify, and Uber, have made their preference for MACH architectures well-known. Still, many startups, small, and mid-sized companies have had success refactoring to microservices architectures.

Here are a few companies that have transitioned from monolithic to microservice architectures with help from Contentful and, in some cases, a digital agency.

• VR Group Pre-microservice architecture, Finish railway company VR Group grappled with a disjointed ticketing system and website, which offered a poor user experience for internal team members and commuters. To modernize and unify its stack, the company swapped out its ecommerce monolith and web service for a microservice architecture that ropes in Contentful, Mapbox, and other tools. Its developers are taking full advantage of the architectures’ flexibility in frameworks and languages. They utilize Gatsby for static sites, React for web apps, React Native for mobile, Java on the backend, in addition to GraphQL and TypeScript. The fluidity and flexibility of its new architecture inspire continuous optimization and has led to a 50% increase in the app’s net promoter score. Read the full case study >

• Staples Canada In 2019, Staples Canada’s business began to exceed the targeted capabilities of its Shopify-powered ecommerce platform. Its growing blog demanded more agile publishing capabilities and time-sensitive campaigns begged for scheduling options. Staples Canada didn’t leave Shopify behind, but rather it made the tool the pinnacle of its new microservice architecture. The change is enabling Staples Canada to stay competitive by shipping perfectly timed campaigns during big holidays and creating content that’s fully optimized and localized with support from choice integrations. Read the full case study >

• Costa Coffee When acquired by Coca-Cola, U.K.-favorite Costa Coffee decided ownership wasn’t the only thing that would be changed. It re-platformed from its legacy CMS to a microservice architecture in just five weeks. The stack, which relies on JavaScript, GraphQL, and Netlify, includes the following microservices: Akamai, Buddy, Google Maps, Google Translate, Adobe Target, Adobe Data, and Storybook. With a technology stack so robust and agile, Costa Coffee can launch localized sites in just fifteen minutes. Today, they’ve launched more than a dozen and are also using their new architecture to power Costa Club, the Costa Coffee customer rewards app. Read the full case study >

When adopting a technology, framework, or approach, like a microservice architecture, it’s important to consider how you’ll measure and share its success to promote continued use down the road. Check out our framework for assessing the performance of new architectures for guidance in this area.

1. Gartner Research, “Adopt a Composable DXP Strategy to Future-Proof YourTech Stack,” by Irina Guseva, Yefim Natis, Mick MacComascaigh, Mike Lowndes, Gene Phifer, December 16, 2020