Composable Architecture: all the flexibility your software needs

Today's market is constantly evolving: driven by the potential of the digital world, new services are being launched every day. Some of these newly formed services are so disruptive in the market that they force others to adapt quickly to survive. An example of this in Italy is what happened with Scalapay, the startup that recently became a unicorn: the deferred payment method has forced players such as Apple and Google to quickly develop a similar alternative to avoid an exodus of customers to the startup.

To react so quickly and effectively to these stimuli from the market, it is necessary to have an agile and flexible software architecture. In fact, technology should be a factor that helps innovation. However, there are cases where legacy systems, typically consisting of monolithic software, are a real technical limitation that directly impacts the ability to capture and create business opportunities.

Modernization of legacy systems is certainly the important first step in overcoming these limitations, but if not done properly, it may not be enough. The type of architecture selected can be critical to the success of the company. One of the patterns that provide the flexibility and speed needed to add, reuse and scale new services with reduced time‑to‑market is that of Composable Architecture.

In this blog post, we will outline the main features of Composable Architecture, the benefits it brings to those who adopt this approach, the challenges to watch out for, and how to overcome them.

What is the Composable Architecture

According to the Composable Architecture pattern, the final software architecture is the result of the composition of several independent software modules. Hence, Composable Architecture evolves continuously and rapidly by its very nature. New modules can be added, existing ones can be updated without compromising the rest of the system, and features that have become obsolete can be removed, all with ease.

The individual modules underlying the Composable Architecture are called by Gartner Packaged Business Capability (PBC). A PBC is itself a set of components that share the same goal and thus fulfill given tasks or business functionalities. PBCs can be developed internally within the organization, purchased from third‑party vendors, or can be open‑source components.

Features of the Composable Architecture

The Composable Architecture paradigm does not define in detail how PBCs should be developed, nor the final architecture. Nevertheless, in order to realize a Composable Architecture, it is necessary to pay attention to some features and requirements from a technical point of view.

First, it is necessary for PBCs to be developed using cloud‑native technologies, as they “leverage cloud computing benefits to their fullest” [source]. Cloud computing is now an indispensable resource for ensuring stability and access to services even as the load of requests changes, which legacy systems can no longer support.

As mentioned above, the Composable Architecture is defined by the combination of several software modules, i.e., microservices. Each is developed independently and serves a specific function. The advantage is that potentially each microservice can be developed in a different language, choosing the one best suited to perform its precise function. In addition, each microservice can be scaled, replaced, or removed individually with very little impact on the rest of the architecture, as by their very nature microservices are loosely coupled together.

To communicate with each other, microservices use APIs, which have now become the de‑facto standard for communication. Indeed, APIs allow information to be shared between services and systems without the need to know the underlying technology; microservices written using different languages can thus easily communicate with each other. Another major advantage of APIs is the ability to offer responses in different formats: potentially, the same endpoint could return data in JSON, XML, and YAML formats, thus increasing the services that can use that data. The most popular API models at present are REST and GraphQL, but SOAP has also been widely used in the past.

Benefits of Composable Architecture

The adoption of a Composable Architecture provides several benefits, both in the short and long term. According to Gartner, by 2024 the adoption of composition (combined with a holistic approach to hyperautomation) will reduce the costs associated with individual initiatives by 40%.

In addition to the above, the other advantages of Composable Architecture are:

• Speed: Because each microservice has only one specific function, its size is quite small and it can be developed faster than a monolith;
• Reuse: thanks to solutions such as Service Catalogs, all microservices, both those developed internally and those purchased from third parties, can be collected in one place and made available to all development teams so that they can be reused in other components;
• Standardization: reusing the same elements and communicating via predefined APIs helps create shared standards;
• Flexibility: by being able to easily add, replace and remove individual microservices with minimal impact on the rest of the architecture, it is very flexible;
• Scalability: each microservice can be scaled independently as needed, creating an architecture capable of responding quickly to traffic.

Challenges of Composable Architecture

Composable Architecture brings obvious advantages on the one hand, but on the other hand, it also presents challenges that are worth keeping in mind. Failing to consider, or underestimating these aspects could negate the efforts and benefits that would come with proper implementation.

Below we collect the main caveats and challenges posed by Composable Architecture:

• Increased complexity: as the number of individual modules increases, so does the management complexity, as the number of dependencies and API routes available grows;
• Preliminary standardization: having components as standardized as possible helps improve governance, but it requires a lot of preliminary work to map all the elements;
• Complex orchestration: in order to work and communicate with each other, individual modules must be orchestrated and configured correctly;
• Need for a marketplace: a Service Catalog is needed to expose your own and third-party PBCs, but this becomes an additional asset to manage and maintain.

These challenges are not insignificant, but by relying on Mia‑Platform you have a tool that allows you to easily overcome them and enjoy only the benefits of Composable Architecture. Mia‑Platform Console in fact simplifies the orchestration and management of complex microservice architectures, while Mia‑Platform Marketplace provides ready‑to‑use templates and plugins to speed up development.

Conclusion

Market demands require organizations to seize opportunities quickly, in order to do this agile and flexible software architectures are needed. One of the software architecture patterns that provide great flexibility is Composable Architecture, in which the final architecture is given by the composition of modules that are independent of each other. Composable Architectures provide development speed, component reuse, standardization, flexibility, and scalability, but it is advisable to rely on platforms such as Mia‑Platform to overcome the complexities they introduce.

A Composable Architecture combined with a 360‑degree composable approach (also called Composable Thinking) allows the entire enterprise to be transformed into a Composable Enterprise capable of reacting quickly to the changes demanded by the market.

This article was written by Michel Murabito, Developer Advocate at Mia‑Platform.