What is composable architecture? An in-depth overview


What is composable architecture? An Overview Author Scott Reed Date 27 February 2024 Read time 6 Minutes CONTENTS The importance of composable architecture elements Composable architecture: Advantages Composable architecture: Challenges Designing a composable architecture Lessons learned CONTENTS The importance of composable architecture elements Composable architecture: Advantages Composable architecture: Challenges Designing a composable architecture Lessons learned Like 2 Share Subscribe to our newsletter subscribe Composable architecture refers to an architectural design approach where complex systems are developed by combining small, loosely-coupled components to create digital experiences.  It is based on the idea of composing a software system from independent components, which can be added, removed or replaced as needed. It allows for greater flexibility, agility, scalability and efficiency in development. It also enables rapid delivery of new functionality, whilst minimizing disruptions to existing systems during such delivery. This design approach is typically comprised of the following elements:   Microservices: An architectural pattern that defines a collection of services that are organized around specific business or technical capabilities. API first: All functionality is exposed via APIs which connect the business functionality through a well-defined set of contracts, allowing multiple systems to interact whilst reducing interdependency. Cloud Native: It leverages a cloud computing model to take advantage of modern software development methodologies such as agile, devops, continuous integration/delivery, microservices and containerization. This results in apps and services that are flexible, scalable and resilient. Headless: This denotes API-first services (both in-house and external) where applications can be created completely decoupled from the back end. The importance of composable architecture elements The role of Microservices Microservices are a way of designing software applications as a collection of small, independent services that communicate with each other using well-defined APIs. Each service should have its own purpose (i.e. business domain), technology stack and associated data storage - ensuring it is a standalone entity. Benefits include: Simplification of development and deployment of new features and updates Reduced complexity and coupling of application code Flexibility with different technologies and approaches Improved fault tolerance and isolation Scalability and optimization opportunities Challenges: Increased operational complexity due to managing multiple services As the number of individual components increases, management complexity increases Additional complexity in testing of multi-layered systems Isolation contributes to this complexity Higher security risks due to larger attack surface To combat this, access to microservices should be strictly governed The best path is to apply the principle of least privilege The role of API First The API-first design principle ensures that all component elements of a system communicate solely through well-defined and documented interfaces. The approach prioritizes definition and documentation of APIs prior to the implementation of backend logic. It ensures that APIs are consistent, clear and easy to use by other components or third-party systems.   The role of Cloud Native Leveraging cloud technologies (such as Azure/AWS/GCP) has changed how web development is done. Cloud-native applications are designed to make best use of the services and tools provided, such as containers (and associated orchestration) or serverless computing and enables continuous deployment and delivery through these deployment pipelines. Each provider offers multiple services and tools, and choosing the right one for your particular application requirements needs serious consideration. The role of Headless Headless is an architectural pattern that decouples the front end and the back end of the application. The front end (or presentation layer) is responsible for delivering the user experience. The back end (or logic layer) is responsible for processing the data and business logic - which may include integration with third party services. If we look at a typical marketing site, it may contain the following elements: Content management Headless content management is a way of managing your web content separately from the presentation layer, allowing you to store and edit your content in isolation. The content can then be delivered to any platform or device via an API. There are many headless content management providers in the market. The capabilities of these services can differ significantly and should be reviewed against business requirements before you choose the one for you. Cost management is an issue, as some providers license based on usage. This can become costly as your content grows. Sound architectural approaches can alleviate this to some degree. Given the likely limited frequency of change in the underlying data, implementing a caching layer will reduce API calls to the source system and will also reduce latency. Commerce Headless commerce provides a way of managing your product catalogue in isolation from other layers of your application. The different capabilities amongst the many vendors in this sector are vast and can be daunting. Again, supplier selection should be weighed carefully against your business requirements and your roadmap. Consider the flexibility of the platform under selection before you commit to a choice. Digital Asset Management Most CMS and Commerce suppliers include their own digital asset management (DAM) system. These typically include optimization capabilities that can be leveraged in your presentation layer (such as dynamic image resizing) and Content Delivery Network (CDN)-based delivery. You may wish to introduce an independent asset management system, and many CMS and Commerce suppliers provide connectors to popular DAM systems. Composable architecture: Advantages The benefits of composable architecture are many. Performance: Individual components are built to focus solely on their limited functionality, and you can optimize part of any component for its particular needs. Flexibility: You can select the best tools and technologies for each individual component. Time to market: Implementing change is quicker. Changes are limited to affected services (and consumers) and can be done in isolation to the rest of the system, and tested independently. Scalability: Each component can be scaled independently according to its own needs. Team autonomy: You can organize teams around the components they own and empower them to make decisions and deliver value independently. Composable architecture: Challenges Composable architecture is not a silver bullet, and each project varies in terms of its goals and functionality. This is a strategic choice that requires careful planning, design and governance. There are a number of challenges that should be considered before opting for a composable architecture approach: Increased complexity: As the number of individual components increases, so does the complexity of the application and its management. Design complexity: It is important to ensure that APIs are well designed, documented and versioned. Poorly designed APIs can lead to integration issues, data inconsistency and security vulnerabilities. Security: As you are delivering multiple components, the potential attack surface increases. Your design should consider which elements are publicly exposed and implement appropriate security principles to avoid misuse or attack. Designing a composable architecture There is no definitive way to design a composable architecture, as the requirements and constraints will vary between projects. However, there are some general principles that you might want to follow to guide your design: Determine your goals What are you trying to achieve? What are the key features to be delivered? Identify Identify the services to be delivered - small, domain-focused services should be the guiding principle Identify the third-party services to be used and how to integrate - are external services being used, will your front-end application integrate directly or through your services? Define Define the services to be delivered Define the APIs for each service Select your technology: Ensuring you select the appropriate cloud technologies can be key. There are many cloud services that can be leveraged, but each comes with its own management and cost implications. Choose your team structure: Define a team structure that aligns with your service design. Lessons learned Having delivered many composable projects, here are some lessons I have learned: Technology selection: Making the wrong choice can be costly. Platforms such as Kubernetes provide significant advantages, but the learning curve is very steep. Consider the basic needs of your services and choose the least risky option available. Team structure Choosing the right structure will help with the long-term success of the project. Giving teams ownership over their services promotes flexibility and innovation. Design pattern Your service 'mesh' may be very complex, exposing each directly can become cumbersome and costly. In previous projects, I selected the gateway principle for APIs, where the front end communicates with a single API to deliver the data required for front-end presentation. This approach can optimize the data required for a particular channel for best performance - and limit the API exposure (and with it, security concerns). Promote a collaborative culture Promote a collaborative culture among your team, as their knowledge and experience are an invaluable asset. They may even produce options that you hadn't considered. Don’t be afraid to be challenged, and take their ideas on board. Like 2 Share Subscribe to our newsletter subscribe Architecture Best practices AUTHOR Scott Reed Having worked in digital agencies for over a decade, Scott has spent his time building large complex solutions on the top .NET digital content platforms. He has worked with clients driving change and allowing product owners to fulfil their digital strategy goals. As an Episerver/Optimizely MVP since 2018 he is engaged heavily with the community helping people with the in all aspects of platform, attending events and speaking where possible about the platform. × Subscribe to our newsletter Get the latest job openings and news delivered directly to your inbox subscribe Looking for a partner to transform your business and drive results? Let's Get In Touch Related Articles The 4 web performance test tools you should be using How-to 15 February 2024 6 Min Read Why website performance matters and how to improve website speed How-to 19 January 2024 9 Min Read 9 most effective ways to drive organic traffic to your website How-to 26 December 2023 14 Min Read

Composable architecture refers to an architectural design approach where complex systems are developed by combining small, loosely-coupled components to create digital experiences.  It is based on the idea of composing a software system from independent components, which can be added, removed or replaced as needed. It allows for greater flexibility, agility, scalability and efficiency in development. It also enables rapid delivery of new functionality, whilst minimizing disruptions to existing systems during such delivery.

This design approach is typically comprised of the following elements:  

Microservices: An architectural pattern that defines a collection of services that are organized around specific business or technical capabilities.
API first: All functionality is exposed via APIs which connect the business functionality through a well-defined set of contracts, allowing multiple systems to interact whilst reducing interdependency.
Cloud Native: It leverages a cloud computing model to take advantage of modern software development methodologies such as agile, devops, continuous integration/delivery, microservices and containerization. This results in apps and services that are flexible, scalable and resilient.
Headless: This denotes API-first services (both in-house and external) where applications can be created completely decoupled from the back end.

The importance of composable architecture elements

The role of Microservices

Microservices are a way of designing software applications as a collection of small, independent services that communicate with each other using well-defined APIs. Each service should have its own purpose (i.e. business domain), technology stack and associated data storage - ensuring it is a standalone entity.

Benefits include:

Simplification of development and deployment of new features and updates
Reduced complexity and coupling of application code
Flexibility with different technologies and approaches
Improved fault tolerance and isolation
Scalability and optimization opportunities

Challenges:

Increased operational complexity due to managing multiple services
As the number of individual components increases, management complexity increases
Additional complexity in testing of multi-layered systems
Isolation contributes to this complexity
Higher security risks due to larger attack surface
To combat this, access to microservices should be strictly governed
The best path is to apply the principle of least privilege

The role of API First

The API-first design principle ensures that all component elements of a system communicate solely through well-defined and documented interfaces. The approach prioritizes definition and documentation of APIs prior to the implementation of backend logic. It ensures that APIs are consistent, clear and easy to use by other components or third-party systems.  

The role of Cloud Native

Leveraging cloud technologies (such as Azure/AWS/GCP) has changed how web development is done. Cloud-native applications are designed to make best use of the services and tools provided, such as containers (and associated orchestration) or serverless computing and enables continuous deployment and delivery through these deployment pipelines.

Each provider offers multiple services and tools, and choosing the right one for your particular application requirements needs serious consideration.

The role of Headless

Headless is an architectural pattern that decouples the front end and the back end of the application. The front end (or presentation layer) is responsible for delivering the user experience. The back end (or logic layer) is responsible for processing the data and business logic - which may include integration with third party services.

If we look at a typical marketing site, it may contain the following elements:

Content management

Headless content management is a way of managing your web content separately from the presentation layer, allowing you to store and edit your content in isolation. The content can then be delivered to any platform or device via an API.
There are many headless content management providers in the market. The capabilities of these services can differ significantly and should be reviewed against business requirements before you choose the one for you.
Cost management is an issue, as some providers license based on usage. This can become costly as your content grows.
Sound architectural approaches can alleviate this to some degree. Given the likely limited frequency of change in the underlying data, implementing a caching layer will reduce API calls to the source system and will also reduce latency.

Commerce

Headless commerce provides a way of managing your product catalogue in isolation from other layers of your application.
The different capabilities amongst the many vendors in this sector are vast and can be daunting. Again, supplier selection should be weighed carefully against your business requirements and your roadmap.
Consider the flexibility of the platform under selection before you commit to a choice.

Digital Asset Management

Most CMS and Commerce suppliers include their own digital asset management (DAM) system. These typically include optimization capabilities that can be leveraged in your presentation layer (such as dynamic image resizing) and Content Delivery Network (CDN)-based delivery.
You may wish to introduce an independent asset management system, and many CMS and Commerce suppliers provide connectors to popular DAM systems.

Composable architecture: Advantages

The benefits of composable architecture are many.

Performance: Individual components are built to focus solely on their limited functionality, and you can optimize part of any component for its particular needs.
Flexibility: You can select the best tools and technologies for each individual component.
Time to market: Implementing change is quicker. Changes are limited to affected services (and consumers) and can be done in isolation to the rest of the system, and tested independently.
Scalability: Each component can be scaled independently according to its own needs.
Team autonomy: You can organize teams around the components they own and empower them to make decisions and deliver value independently.

Composable architecture: Challenges

Composable architecture is not a silver bullet, and each project varies in terms of its goals and functionality. This is a strategic choice that requires careful planning, design and governance.

There are a number of challenges that should be considered before opting for a composable architecture approach:

Increased complexity: As the number of individual components increases, so does the complexity of the application and its management.
Design complexity: It is important to ensure that APIs are well designed, documented and versioned. Poorly designed APIs can lead to integration issues, data inconsistency and security vulnerabilities.
Security: As you are delivering multiple components, the potential attack surface increases. Your design should consider which elements are publicly exposed and implement appropriate security principles to avoid misuse or attack.

Designing a composable architecture

There is no definitive way to design a composable architecture, as the requirements and constraints will vary between projects. However, there are some general principles that you might want to follow to guide your design:

Determine your goals

What are you trying to achieve?
What are the key features to be delivered?

Identify

Identify the services to be delivered - small, domain-focused services should be the guiding principle
Identify the third-party services to be used and how to integrate - are external services being used, will your front-end application integrate directly or through your services?

Define

Define the services to be delivered
Define the APIs for each service
Select your technology: Ensuring you select the appropriate cloud technologies can be key. There are many cloud services that can be leveraged, but each comes with its own management and cost implications.
Choose your team structure: Define a team structure that aligns with your service design.

Lessons learned

Having delivered many composable projects, here are some lessons I have learned:

Technology selection: Making the wrong choice can be costly.

Platforms such as Kubernetes provide significant advantages, but the learning curve is very steep.
Consider the basic needs of your services and choose the least risky option available.

Team structure

Choosing the right structure will help with the long-term success of the project.
Giving teams ownership over their services promotes flexibility and innovation.

Design pattern

Your service 'mesh' may be very complex, exposing each directly can become cumbersome and costly.
In previous projects, I selected the gateway principle for APIs, where the front end communicates with a single API to deliver the data required for front-end presentation. This approach can optimize the data required for a particular channel for best performance - and limit the API exposure (and with it, security concerns).

Promote a collaborative culture

Promote a collaborative culture among your team, as their knowledge and experience are an invaluable asset. They may even produce options that you hadn't considered. Don’t be afraid to be challenged, and take their ideas on board.

Architecture

Best practices

AUTHOR

Scott Reed

Having worked in digital agencies for over a decade, Scott has spent his time building large complex solutions on the top .NET digital content platforms. He has worked with clients driving change and allowing product owners to fulfil their digital strategy goals. As an Episerver/Optimizely MVP since 2018 he is engaged heavily with the community helping people with the in all aspects of platform, attending events and speaking where possible about the platform.

What is composable architecture? An Overview