Microservice architecture: A future-proof composable alternative to monoliths
Updated: April 12, 2022
Looking to build a modern application? A supportive microservice architecture lays the foundation for flexibility and scalability, helping you to better prepare for the evolving customer expectations and marketplace changes that arise today and well into the future.
What is a microservice architecture?
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:
What are some common types of microservices?
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.
Delivery and deployment
Digital asset management
Optimization and personalization
How do microservice applications connect with one another?
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.
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.
What are the benefits of a microservice architecture?
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
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.
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.
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.
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.
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.
What are the key differences between microservices architectures and monolithic architectures?
While both monolithic architectures and microservice architectures support application development, they have several defining differences.
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.
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.
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.
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.
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
|All-in-one suite supported by a single vendor.||An ecosystem of third-party and house-built tools.|
|Uses a single language and framework.||Language- and framework-agnostic.|
|Utilizes a single database.||Each microservice has its own database.|
|Requires little development out of the box.||Requires developer support and resources to set up.|
|Updates and new features are dependent on vendor release schedules.||New tools can be added, reconfigured, and removed anytime.|
|Deployment errors and bugs affect the entire application.||Deployment errors and bugs are isolated to the portion of the experience supported by the tool at fault.|
|New builds and iterations are tied to long release cycles.||Builds and iterations can be deployed quickly and at will.|
How does Contentful support microservices architectures?
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.
Real-world examples of microservice architectures in use
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.
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 >
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.
- 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