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:
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.
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.
Blog Author
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.