When designing infrastructure, a major hurdle is figuring out the optimal size and structure for stacks. Initially, you might think about using a single stack code project to manage your entire system. However, as your system grows, this approach becomes challenging to handle efficiently. In the upcoming section, I will present a thorough examination of suggested strategies and pitfalls to avoid when organizing and structuring infrastructure.
Next up, we're diving deep into the world of patterns, each with its own unique approach to bundling system components into one or more stacks.
First off, we've got the 'all-in-one' approach, the monolith stack. This bad boy wraps up your entire system into a single stack, no exceptions.
Then there's the service stack. This one's a bit more selective, bundling together multiple, interconnected parts of a system into their own stacks. It's all about flexibility and modularity.
Next in line is the application stack. This one's all about focus, taking all the infrastructure needed for a single application and putting it into one dedicated stack.
By exploring these patterns, we're aiming to give you a solid understanding of how different stack assembly strategies can be applied depending on your system's needs.
Antipattern - monolith
Why do folks gravitate towards monolithic stacks, you ask? Well, it's pretty straightforward. When you've got a new element to add to your system, the easiest route is to just toss it into the existing project. Sure, each new stack brings along its own set of moving parts that need to be orchestrated, integrated, and tested, but managing a single stack? That's a walk in the park.
Now, if you're dealing with a modestly sized bunch of infrastructure elements, a monolithic stack might just be your best bet. But here's the catch - more often than not, a monolithic stack starts to grow... and grow... and before you know it, you've got a behemoth on your hands that's spiraled out of control.
So, what happens when you try to change a large stack? Well, it's like playing with fire. The bigger the stack, the bigger the 'blast radius'. More things can go wrong, and if they do, the fallout can be widespread, affecting more services and applications within the stack.
And let's not forget, larger stacks move at a snail's pace. They're slower to provision and change, which makes them a real pain to manage. Because of this, people tend to tread lightly, making changes less often and taking their sweet time to do it. But this slow and steady approach has its own drawbacks. It creates friction, and this friction can pile up, leading to a mountain of technical debt.
Pattern - application
Think of a application stack as a dedicated manager for the infrastructure of each deployable application component, with each component having its own separate infrastructure stack.
This method ensures that the infrastructure aligns seamlessly with the software it supports, much like fitting puzzle pieces together. One of the key advantages of this is that it confines the 'blast radius' of any change to a single service, minimizing the impact on the entire system and streamlining the change management process.
The bonus? Service teams have full ownership and control over the infrastructure associated with their software, granting them greater autonomy and authority in their projects.
Application stacks are a great fit for microservice application architectures. They're like a dream team, working together to help organizations with autonomous teams take full ownership of their infrastructure.
But, as with anything, there's a flip side. If you have multiple applications, each with its own infrastructure stack, you might find yourself in a sea of duplicated code.However if you architect your setup with reusability and components in mind - this should be addressable by using small factor module components to build the stacks ( this of course is only one of possible approaches )
Pattern - functional
Functional stack emerges when you separate your platform into blocks that then further would be consumed by application/services.
This approach would usually be used as fundamental for creating underlying components which then go in tandem with application stacks
The gain here is it allows you to become your PaaS provider for your development teams and help them to build there apps.
There's always a dark side. If you make breaking changes these will affect every consumer ( potentially ) in the higher level of your stack. That is something you need to find a way based on your organisation needs.
