Easily restore your project to a previous version with our new Instant One-click Backup Recovery

Microservices in a composable architecture explained

We will detail what microservices are, how they differ from monolithic and composable architectures, when to use microservices, and examples of microservices in a composable approach.
Katie Lawson

Katie Lawson

Jun 28, 2023
Mobile image

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.

An example of a microservice in a metaphor would be:

Let’s say you have a birdhouse business. Making each house takes four steps: take the order, cut the wood, build the house, paint the house. At first, you hire one person to do all four steps and this works incredibly efficiently. As the business starts to grow, you simply scale up birdhouse production by hiring a small team where each person is responsible for the whole process.

Then things start to get more complex. Customers want birdhouses in different sizes and shapes, you find a more efficient way to cut wood or store tools, new paints hit the market, but updating the process to include these new things means retraining the whole team. So you bundle updates into a monthly training day when you close the store and get the team up to speed. Changing the process becomes such a hassle that you begin to settle for “good enough” birdhouses and when you have ideas for new offerings, like bird feeders or bird baths, the thought of expanding the process to include them is so daunting that you never even try.

So you decide to break up the process into those four distinct steps. You assign one person to take orders, one to cut wood, one to build houses, and one to paint. Each person can work autonomously, the person taking the order can just announce it and doesn’t need to wait for the woodcutter to respond before taking the next one, the carpenter can build the house without knowing how to paint it, and the painter can store art supplies in a completely different way than the carpenter stores nails.

This separation also means that each person can continuously make small improvements to their own ways of working without disrupting everyone else, so no more need to shut down the store for an all-company training. It also means you can scale up production more precisely, for instance to make 100 birdhouses a day you may only need one person to take orders but four people painting.

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:

If you want one quick answer for when you should use microservices, it’s when you’ve got a really good reason.
Even Sam NewmanAuthor at Building Microservices

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:

#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.

Blog Author

Katie Lawson

Katie Lawson

Content Writer

Katie is a freelance writer based in Amsterdam who talks a lot about B2B SaaS and MACH technologies. She’s always looking for good book recommendations.