Microservices in a composable architecture explained

Microservices is an architecture style that emerged as digital ambitions began to outpace the capabilities of rigid, all-in-one software platforms. Over the past decade the approach has gained a lot of traction, with 49% of developers now working with microservices at their organization according to Stack Overflow’s 2023 developer survey.

Microservices have become an especially popular option to create scalable e-commerce systems and to support composable technology stacks that allow companies to mix-and-match capabilities from different best-of-breed tools instead of being locked into an inflexible set of features from a single software vendor.

#What is a microservice

Microservices are used to break business processes into discrete pieces, or services, that can be designed, improved, and scaled independently.

In other words, each microservice is:

• Autonomous: A service can use the logic, programming language, and data storage that makes sense for the task. APIs are used to standardize how information is communicated between services.
• Independently deployable: Changes to one service won’t impact the logic of another. Services can be updated continuously, and in parallel, without risking a cascade of errors across the system.
• Individually scalable: Resources can be given to just the services that need it, allowing for more precise scaling strategies.

#Microservices vs composable vs monolithic architecture

Monolithic architecture

In a monolithic application all processes and capabilities are highly dependent on one another with a shared language, logic, and database. Due to this dependency, a change in one part of the system can have unintended consequences in another part of the system so updates are typically made in large batches leading to distinct versions of the application.

Small applications with simple processes work great as a monolith. Where companies start to run into problems is when a monolith sits at the core of a key part of business, like the digital experience, and over time there is a build up of clunky extensions and “one-off” workarounds that make the monolith expensive to maintain and hard to adapt to new customer demands.

Microservice architecture

A microservice architecture is on the other end of the dependency spectrum, where software is designed as a collection of small services each responsible for a distinct piece of business functionality such as checkout, inventory, blog, or even parts of the front-end. Each microservice is responsible for its own processes, database, and API. Changes can be made to one microservice without disrupting others, as long as it still shares data in an agreed upon way, so updates can happen on a rolling basis without versioning.

In a microservice architecture, the team structure is just as important as the technology. Typically each microservice is owned by a dedicated, cross-functional team that is responsible for developing, maintaining, and continuously improving the service.

Composable architecture

Composable and microservice architecture can sometimes be perceived as the same thing, but while microservices are usually a key component of a composable approach they aren’t the only type of solution used. Composability is the idea of creating a tech stack of best-fit tools for different areas of business and connecting them via APIs so solutions can be easily added, changed, and removed as needed.

A fully microservice architecture might be the end-goal of composable for some organizations, but the majority of composable architectures will be a mix of homegrown services, vendor solutions built with MACH principles (microservices, API-first, cloud-native, headless), and even some applications that are better left as a monolith.

#When and how to use a microservices based architecture

There’s no clear-cut guidelines for when a company should make the shift to microservices. Even Sam Newman, the author of the defining book on microservices, doesn’t have a straight answer:

Microservices can bring a lot of benefits, but can also add complexity, and teams that adopt them should do so only if the approach can deliver a needed business outcome. Some common business drivers include:

• When you need your solution to evolve: Microservices have the flexibility to adapt to changing customer demands, diverse internal needs, and business pivots. Services can be composed in different ways to quickly spin up new ideas, and they make it easier to create a flexible tech stack that allows tools to be swapped in and out as business needs change.

• When you need high availability: Microservices support a continuous development (CI/CD) approach and don’t require downtime for updates. With small services that are independently deployable you reduce the “blast radius” of any errors.

• When you need to isolate data: With each microservice owning its own database there is more flexibility in separating data and the processes that touch it. This can be particularly useful for compliance standards such as the EU’s General Data Protection Regulation (GDPR).

• When you need to enable autonomous teams: When large teams are working on complex monoliths, there is a massive coordination effort needed to make even the smallest change. If teams are already embracing DevOps but are being held back by legacy technology, microservices can enable teams to make quick decisions for their domain and move at the pace they’re ready for.

Even more so that “when” to implement microservices, “how” to do it is determined on a case-by-case basis. Here are some of the leading voices in the microservice space talking about key scenarios organizations need to consider when making the move:

• How to get started with microservices: Martin Fowler, Microservices.

• How to organize teams to support microservices: James Lewis, Software Architecture, Team Topologies, and Complexity Science.

• How to move from monolith to microservice: Sam Newman, Monolith Decomposition Patterns.

• How to set up communication between microservices: Chris Richardson, Not Just Events: Developing Asynchronous Microservices.

#Architecture example: microservices in a composable approach

The Oetker Group is Germany’s largest family run business, selling food and beverages across the globe. The organizations wanted to move to a composable architecture to make it easier for local teams to manage the digital experience for their market while keeping the global brand experience consistent.

To do this, the company took a headless approach. This gives each team the freedom to create unique front-end experiences for their market while sharing a centralized tech stack on the back-end. Dr. Oetker’s composable tech stack includes Hygraph (headless content management), Next.js (front-end framework), Algolia (search and discovery), in-house built services, and legacy applications for product information management (PIM) and storing recipe data.

Hygraph and Algolia are both microservice-based solutions, and the strong API support of these two platforms was key to bringing all the data together so that teams could manage the experience from one place. For instance, editors can use Algolia’s product discovery service directly in the Hygraph user interface (UI) to select and combine recipes, products, and articles to create better search results for customers.

Dr. Oetker also uses Hygraph’s Content Federation capabilities to retrieve recipe and product data and let editors easily access it from one UI. Data still lives in the recipe database and PIM, so there’s no worry about duplication. When data is requested the Hygraph API grabs the right information based on localization and permissions. This allows over 100 users to manage unique experiences for 40 different markets out of the same content management platform.

#How does Hygraph support microservices

Hygraph is a certified MACH Alliance vendor and an advocate for a composable approach to software architecture where businesses are encouraged to pick the services and tools that best fit their needs.

Hygraph provides a next-generation content management platform with native GraphQL APIs that make it easy to integrate other tools in your stack. The platform’s novel approach to Content Federation also helps businesses solve the challenge of orchestrating data in a composable architecture.

The microservice structure of the platform gives businesses the flexibility to use Hygraph’s powerful functionality in different ways. Companies can leverage structured data models to unify data from their commerce stack into rich content, like the German craft-supplies company, Prym, does to create an e-commerce experience with over 100,000 unique products. Or can use Hygraph as a PIM and integrate it with fulfillment and payment solutions, like the American furniture company, Burrow, does to create highly complex data modeling structures to manage over 20,000 product variations.

#What’s next

Stop letting the limitations of your legacy monolith define your customer experience, and start designing a tech stack around the digital ambitions of your business. Learn more about a composable approach to Digital Experience Platforms in the DXP report.