Part I – Introduction to Composable Architecture

In this article, I am excited to explore the captivating realm of composable architecture. Why? As I've been delving into composable architecture, I've found it to be an intriguing subject that I believe will pique your interest as well. Let's explore this promising trend together.

If you’re like me, as technology marches forward, you find yourself constantly seeking innovative solutions to tackle the ever-evolving challenges of scalability, flexibility, and maintainability in our software architectures.  

 

1. The Evolution of Software Architecture Styles 

Over my ten years in software engineering, I have seen some incredible changes unfold. Much like the tools I use to build, software architecture has undergone a fascinating evolution. It is the blueprint that guides the construction and organization of our applications, ensuring they function seamlessly.  

Let us inspect how these architectural styles have transformed over time, reflecting the ever-growing complexity of the software we create. 

1.1 Early Days: The Monolithic Playground

For starters, try to imagine building an epic structure using only one box of toys. That is pretty much how software development kicked off, at least for me, with the monolithic architecture taking the stage. Everything — from the flashy user interface to the behind-the-scenes business logic and data storage — was crammed into one big codebase. It was straightforward to develop and grasp, especially for smaller, clear-cut applications. 

 

1.2 The Rise of Microservices: A Modular Marketplace 

As software applications got more intricate, I began to observe the shortcomings of the monolithic approach. 

Then came microservices architecture, a whole new mindset influenced by the lively hustle and bustle of a marketplace. Instead of cramming everything into one giant box, I broke down applications into smaller, independent services, each doing its own thing like a pro. These microservices chat with each other through APIs, giving us way more flexibility and scalability to play with - and let me tell you, it blew my mind! 

 

1.3 Composable Architecture: Building with Blocks, Not Bricks 

I have to say, this was new for me, but man, it is game-changing!

The world of software development keeps changing, and let me tell you, composable architecture emerges as a promising contender. It is all about building apps from neat little building blocks that you can mix and match to make some seriously cool stuff. And guess what? It is like the best of both worlds — you get the flexibility of microservices without all the headaches of managing several separate services. 

 

2. Composable Architecture: Modular Design for Modern Applications 

If you have made it this far, I hope you are just as pumped as I am to unravel the new world of composable architecture. Composable architecture might not be brand-spanking new in software development, but it has been making waves lately. It takes concepts like modularity and reusability and gives them a shiny new spin. 

So, what's so fascinating about this new type of architecture? Read on to discover more! It is all about understanding its roots and the big problems it is here to tackle. 

 

2.1 What problem does it solve? 

Navigating the app world these days can feel like a bit of a maze, am I right? 

Now, picture this: you are juggling a bunch of different apps — I am talking about 100 averages for companies. And guess what? That number's only going up! Fortunately, I have only had to wrangle with about 50 services in my experience. But I have friends who have dealt with over 100 services, and they know what each of them does.  

 It is like trying to keep track of all your favorite snacks in a vending machine that keeps adding new options. 

Now, here's where things get tricky. With all these apps floating around, sometimes your data gets stuck in one place. It is like having your favorite pen stuck at the bottom of your backpack – you know it is there, but it is a pain to find when you need it. 

That is where composable architecture comes in to save the day. It is like having a magic wand that brings all your apps together. No more hunting for data or clashing workflows – it is all smooth sailing from here on out! 

I know it is tough to understand, so let me clarify it for you. Someone smarter than me once said that if I can explain it to a 5-year-old, then I have it down. I will do my best to simplify things for you! 

When I said, "Data stuck in one place," I meant when you have lots of apps, but the information you need is only in one of the services. Composable architecture allows data consolidation from various sources into a centralized repository or through standardized APIs. So, instead of each team storing data in separate storages, all relevant data is accessible from only one source (keep in mind that every microservice has its own database; we need just one aggregated database). As a result, teams no longer must waste time hunting for data across different services or struggling to access information locked in isolated systems. 

This is called "Unified Data Access." I like this term. 

 

2.2 Core principles: building blocks for flexibility 

As a fellow Lego enthusiast, I cannot help but draw parallels between composable architecture and those iconic plastic bricks. Like how we create masterpieces by piecing together different Lego blocks, composable architecture breaks down complex systems into smaller, more manageable parts. 

Think of it as building your favorite Lego puzzle – for me, it is that challenging "piano" set. Each piece has its place and purpose, just like each module or service in composable architecture. 

And just like how a piano's strings need to be tuned precisely right for beautiful music, the principles of composable architecture need to be spot on. Here are the key principles that make it sing: 

• Modularity → Like Lego pieces, each module or service serves a specific function, making building and maintaining complex systems easier. 

• Loose Coupling → Just as Legos connect easily, composable architecture components interact through clear, well-defined connections, allowing for seamless integration. 

• Scalability → Similar to how we can add more Lego pieces to expand our creations, composable architectures can scale up or down effortlessly to meet changing demands. 

• Flexibility → Much like picking the right Lego pieces for a project, composable architecture allows us to choose the best tools and technologies for each task, ensuring optimal performance and adaptability 

These principles are not just abstract concepts but the foundation for building smarter, more adaptable systems. These fundamental principles are not just for composable architecture – they are becoming the norm for all kinds of software design. 

Just as a well-tuned piano produces beautiful music, getting these principles right ensures that our software sings efficiently and effectively. 

 

3. Enough talking! Example Architecture Walkthrough 

Theory's fine, but seeing composable architecture in action? Now, that is where the real magic happens. And let me tell you, just reading about all this theory? It had me scratching my head, too. I kept getting stuck on microservices and could not figure out what made composable architecture different. But once I started getting my hands dirty with the design process. 

So, let us turn a regular old monolithic stock market app into a supercharged composable one. 

Now, I have a soft spot for economics, so diving into the stock market domain just feels right. It is like marrying my love for numbers with this new way of building software – talking about a match made in heaven!

While I will give you a sneak peek into how this transformation happens, remember I am not covering every little detail here. There is more to a stock market system than meets the eye. We will focus on the basics to show you how composable architecture works magic in this domain. 

 

3.1 Breaking down the system into small independent components 

All right, let us break it down. First things first, we are going to take our system and chop it up into smaller, independent pieces. We are talking about tiny, autonomous components here – like breaking a big project into smaller tasks to make it more manageable. 

Now, instead of cramming everything into one big lump of code like in those old-school monolithic setups, we will split things up into microservices. Each of these little guys has its own job to do, which makes it easier to keep track of and manage. 

We can update and improve each piece without messing with the others with microservices. It is like upgrading your phone's apps one at a time without rebooting the whole thing. 

Plus, this setup makes it a breeze to plug in other tools and services from outside. So, if we need to add some fancy new software or tap into existing systems, we can do it without breaking a sweat. 

Now, let us paint a picture. Imagine we are building a stock market app. Here is how we might lay out our collection of services: 

 

3.2 Service definitions and dependencies 

Now, let us delve into the specifics of each service within the stock market application, outlining their responsibilities and interconnections. 

 

1. User Service 

2. Order Service 

3. Market Data Service 

4. Notifications Service 

5. Alert Service 

 6. Reporting Service 

7. Fulfill Service 

 

Understanding these service definitions and dependencies is crucial for designing and implementing a robust and scalable architecture that meets the needs of users and stakeholders. 

 

3.3 Leveraging abstraction for microservices: introducing Message Bus Architecture 

All right, here is the deal with microservices architecture: it is incredible but not a one-size-fits-all solution. There are still some tricky bits we need to watch out for. 

See all these services we are dealing with? They are like a big, tangled web – they depend on each other in various ways. To keep things from getting too messy, we can add in something called a message bus or message queue. 

With this extra layer in place, our microservices can do their thing without stepping on each other's toes. They can shout out messages for transactions or errors, and other services can listen in and act as needed. 

Plus, it is not just about keeping things running smoothly now but about being ready for whatever the future throws at us. So even if we need to add new services or tweak stuff down the road, our system's all set to handle it like a champion. 

Let us put this into perspective with our stock market example. Here is how a system with a message bus might look: 

 

3.4 MACH principles 

MACH stands for Microservices, API-first, Cloud-native, and Headless. It is like the ultimate superhero squad for building modern digital experiences!  

So, how does MACH relate to composable architecture? Well, MACH is like a set of best practices and principles that align perfectly with the goals of composable architecture. 

• Microservices → Each piece, or microservice, does its own thing, making it easier to develop, deploy, and scale your applications. 

• API-first → With an API-first approach, you design your system around these interfaces from the get-go, making it super easy to connect and integrate different services. 

• Cloud-native → It means taking advantage of all the cool features and scalability that cloud platforms offer, like auto-scaling and easy deployment. 

• Headless → Headless architecture is all about separating the front end (the "head") from the back end (the "body"). This gives you more flexibility to deliver content to different devices and channels, like websites, mobile apps, and smart devices. 

Our example adheres to the MACH principles: 

 

 

3.5 Wrapping up Composable Architecture 

I might have failed to convince you that this is not just another microservices architecture, but these are the key differences.

All right, here is the game plan: 

First, we are cutting off direct access to all services except for the shiny new one, the Content service. This means we can switch up our services without worrying about messing up our direct connections. 

Next, we are adding some extra magic with data transformation. See, every team (like web and mobile) has its own way of serving their data. If we hook directly into the services, we change things every time the core API gets updated. By letting the Content Delivery layer handle the data transformation, each team can have its own setup without us having to tweak things constantly. Plus, it stops us from continually tweaking the core API every time someone wants to try something new. 

Lastly, some teams need lightning-fast responses or special requests. Using our Content Delivery layer to handle caching and extensions, we add some extra muscle to our system and give ourselves room to grow without everything falling apart. 

Now that we have this fancy Content API up and running, all our important data is in one easy-to-access place. No more hunting around for different services for what we need! 

About our Dynamic Query and Search: It is like having a super-powered search engine that can find anything you need, whenever you need it. 

With composable architecture, we are not stuck in our ways. We can keep our old monolith app around and use it as a service. Talk about flexibility, right? 

Our example: 

 

3.6 When to consider adopting composable architecture? 

Determining the optimal moment to embrace composable architecture hinges on your organization's unique needs and objectives. Several scenarios warrant careful consideration of this architectural approach: 

• Building a New System from Scratch → Embarking on developing a brand-new system presents an opportune moment for adopting composable architecture. Breaking down the system into small, independent components facilitates the creation of a flexible and adaptable framework that can be easily modified and updated as requirements evolve. 

• Significant Modifications to an Existing System → When planning substantial alterations to an existing system, composable architecture offers a streamlined approach to implementation. By decomposing the system into smaller, autonomous components, modifications to individual elements can be executed efficiently without disrupting the overall system's functionality. 

• Integration of Multiple Systems → The need to seamlessly integrate multiple systems and facilitate the exchange of data and functionality underscores the relevance of composable architecture. Leveraging APIs and other interoperability tools to define system interfaces fosters a cohesive and efficient integration process. 

Conversely, transitioning to composable architecture may not be warranted if the scope of changes involves minor updates or enhancements to an existing system. In such instances, the associated costs and complexities of adopting this architectural paradigm may outweigh the potential benefits. In such cases, maintaining the existing architecture while implementing necessary changes may prove more pragmatic." 

Still not convinced about using composable architecture? Stay tuned for part two, where we will discuss a more practical example that might change your mind! 

 

4. Conclusion: The Future of Flexible Software Development 

Software architecture styles are not static; they adapt to the needs of developers and the ever-growing complexity of modern applications. Monolithic architecture remains a valuable tool for more straightforward projects. Microservices offer agility and scalability for large, evolving applications, while Composable Architecture holds promise for building flexible and maintainable systems. 

The future of software architecture will likely see a continued emphasis on modularity, reusability, and the ability to integrate diverse components seamlessly. Understanding these architectural styles and their evolution empowers developers to choose the best approach for their projects, ensuring their applications are built to thrive in the ever-changing digital landscape. 

"Building evolvable software systems is a strategy, not a religion. And revisiting your architectures with an open mind is necessary."  Werner Vogels, CTO, Amazon.