$ Stack Pickers Guide

A technical guide for cloud-agnostic, open-source technology stacks that prioritize freedom, flexibility, and future-proofing your infrastructure.

~/introduction The Freedom Stack

In a world dominated by vendor-specific cloud solutions and proprietary ecosystems, this guide advocates for a fundamentally different approach: the freedom stack.

FREEDOM_STACK = "cloud_agnostic" # Avoid vendor-specific dependencies
DEPLOYMENT_MODEL = "containerized" # Everything runs in portable containers
INFRASTRUCTURE_AS = "code" # Full automation, no manual configuration
DEFAULT_LICENSE = "open_source" # Prioritize inspectable, modifiable tools
CORE_PHILOSOPHY = "portability" # Move anywhere without rewriting

This isn't merely a technical preference—it's a strategic position on how organizations should approach their technology infrastructure in an era of rapid change and increasing consolidation. The freedom stack represents both a technical architecture and a philosophical stance on technological sovereignty.

~/philosophy Core Principles of the Freedom Stack

Open Source Foundation

The freedom stack begins with a commitment to open-source tools and frameworks. This isn't about cost-saving (though that's often a benefit) but about transparency, community support, and the ability to inspect and modify your tools when necessary.

Key advantages include:

Inspection rights: When systems behave unexpectedly, you can examine the actual code rather than waiting for vendor support.

Modification freedom: Critical bugs or missing features can be addressed directly rather than hoping they make it onto a vendor's roadmap.

Community intelligence: Open-source projects benefit from the collective expertise of global communities, often identifying and fixing security issues faster than proprietary alternatives.

While not every component in your stack needs to be open source, critical infrastructure and security-sensitive components should prioritize transparency and community oversight.

Containerized Everything

Containerization represents the single most important advancement in achieving true infrastructure portability. By packaging applications with their dependencies and running them in isolated environments, containers solve the "it works on my machine" problem once and for all.

The freedom stack takes this principle to its logical conclusion: everything runs in containers. This includes:

Application code: Your custom applications and services

Data stores: Databases, caches, and other persistence layers

Infrastructure services: Monitoring, logging, and other operational tools

Development environments: Consistent tooling across all developer machines

This approach ensures that your entire stack can be moved between environments—from a developer's laptop to staging to production, or from one cloud provider to another—with minimal friction.

Linux-Centric Workflows

The freedom stack embraces Linux as the universal substrate for computing. While developers may use various operating systems on their personal machines, the deployment target is always Linux-based containers.

This creates several advantages:

Consistency: Development, testing, and production environments share the same underlying OS characteristics.

Efficiency: Linux containers have less overhead than alternatives, maximizing resource utilization.

Tooling: The rich ecosystem of Linux command-line tools enables powerful automation and observability.

CoreOS and similar minimalist distributions take this philosophy further by treating the operating system itself as an immutable, containerized component that can be updated atomically, improving security and reliability.

Infrastructure as Code

Manual configuration of infrastructure creates snowflake environments that cannot be easily reproduced or understood. The freedom stack mandates that all infrastructure be defined as code, using tools like Terraform, Pulumi, or CloudFormation.

This approach delivers several benefits:

Reproducibility: Environments can be recreated exactly from source code.

Version control: Infrastructure changes are tracked alongside application code.

Documentation: The code itself serves as living documentation of your infrastructure.

Testing: Infrastructure definitions can be validated before deployment.

When combined with containerization, infrastructure as code enables the ultimate freedom: the ability to recreate your entire production environment in minutes, on any compatible infrastructure provider.

Freedom Stack Benefits

Organizations adopting the freedom stack approach consistently report three primary benefits:

Security improvements: Containerization creates natural isolation boundaries, while infrastructure as code reduces configuration drift and human error.

Deployment velocity: Fully automated, containerized deployments can reduce release cycles from days to minutes.

Vendor leverage: The ability to migrate between providers creates negotiating power and reduces the risk of predatory pricing.

The most overlooked benefit is psychological: teams work differently when they know they aren't trapped.

~/implementation Practical Adoption Strategies

Transitioning to a freedom stack isn't an all-or-nothing proposition. Most organizations benefit from an incremental approach that prioritizes the highest-value, lowest-risk components first.

01: Containerize development environments
02: Implement infrastructure as code for non-critical systems
03: Migrate stateless services to containerized deployments
04: Containerize stateful services with appropriate volume management
05: Implement multi-environment deployment pipelines
06: Develop cloud-agnostic infrastructure abstractions
07: Test provider migration with non-critical workloads

Case Study: E-commerce Platform Migration

A mid-sized e-commerce company found itself locked into a single cloud provider with rapidly escalating costs. Their journey to a freedom stack illustrates both the challenges and benefits of this approach:

Initial state: Monolithic application deployed on provider-specific virtual machines, using managed database and object storage services.

Phase 1: Decomposed monolith into containerized microservices, still running on the original provider but using Kubernetes instead of proprietary orchestration.

Phase 2: Implemented infrastructure as code for all components, including networking, security groups, and load balancers.

Phase 3: Created abstraction layers for provider-specific services (e.g., object storage) that could target different implementations.

Phase 4: Migrated development and staging environments to a different cloud provider to validate portability.

Phase 5: Used the credible threat of migration to negotiate a 42% reduction in cloud costs with the original provider.

The entire process took 8 months and required significant engineering effort, but resulted in both immediate cost savings and long-term strategic flexibility.

~/analysis Comparative Trade-offs

Learning Curves & Switching Costs

Adopting a freedom stack approach involves significant up-front investment in learning and implementation. These costs must be weighed against the long-term benefits:

Kubernetes learning curve: Container orchestration platforms like Kubernetes have steep learning curves compared to proprietary PaaS offerings. Teams need time to develop expertise in areas like networking, storage management, and observability.

Infrastructure complexity: Managing your own infrastructure stack requires broader expertise than using fully-managed services. This may necessitate hiring specialists or investing in team training.

Development velocity impact: Initially, development velocity may decrease as teams adapt to new tools and workflows. This typically recovers and improves over time as automation increases.

Organizations should consider these factors when deciding whether the freedom stack approach aligns with their strategic priorities and team capabilities.

When Freedom Outweighs Convenience

The freedom stack isn't the right choice for every organization or workload. Here are scenarios where its benefits most clearly outweigh the costs:

Long-lived applications: Systems expected to operate for many years benefit most from avoiding lock-in, as they'll likely outlive current cloud offerings.

Cost-sensitive workloads: Applications with predictable, high-volume resource needs often benefit from the ability to shop for the most cost-effective infrastructure.

Multi-cloud requirements: Organizations with regulatory or redundancy requirements that mandate multi-cloud deployments need the portability the freedom stack provides.

Strategic applications: Systems that provide core business value and competitive differentiation warrant investment in infrastructure independence.

Conversely, short-lived projects, rapid prototypes, and non-critical applications may benefit more from the convenience of managed, provider-specific services.

Security & Speed Benefits

Beyond portability, the freedom stack approach offers tangible benefits in security posture and deployment velocity:

Security improvements:

Immutable infrastructure: Containerized deployments are replaced rather than modified, eliminating configuration drift and reducing attack surface.

Consistent environments: Development, testing, and production environments share the same container images, reducing "works in dev but not in prod" security issues.

Automated scanning: Container images can be automatically scanned for vulnerabilities before deployment.

Reduced privilege: Properly configured containers run with minimal privileges, limiting the impact of compromises.

Deployment velocity:

Automated pipelines: Infrastructure as code enables fully automated deployment pipelines.

Parallel environments: Teams can easily spin up isolated environments for testing and development.

Incremental updates: Containerization facilitates rolling updates with zero downtime.

Rapid rollbacks: Failed deployments can be instantly rolled back by reverting to previous container images.

These benefits compound over time, as teams develop expertise and automation around their containerized infrastructure.

~/conclusion The Path Forward

The freedom stack represents more than just a collection of technologies—it's a strategic approach to infrastructure that prioritizes long-term flexibility over short-term convenience. By embracing containerization, infrastructure as code, and open-source tools, organizations can build systems that remain adaptable in the face of changing technology landscapes and business requirements.

The key insights from this guide include:

Containerization is fundamental: Packaging applications and their dependencies into portable containers is the foundation of infrastructure freedom.

Infrastructure must be code: Manual configuration creates snowflake environments that cannot be easily reproduced or understood. All infrastructure should be defined as code and version-controlled.

Open source reduces risk: Critical infrastructure components should prioritize open-source solutions that can be inspected, modified, and supported by communities rather than single vendors.

Freedom has costs: The flexibility of the freedom stack comes with increased complexity and learning requirements. These costs must be weighed against the strategic benefits.

As cloud providers continue to innovate with proprietary services that promise convenience at the cost of lock-in, the freedom stack approach becomes increasingly important for organizations that value technological sovereignty and long-term flexibility.

~/footnotes Extended Thoughts & References

[1] The True Cost of Vendor Lock-in

Vendor lock-in costs extend far beyond the obvious pricing concerns:

Innovation constraints: When your infrastructure is tightly coupled to a specific vendor's services, your ability to adopt new technologies is limited by that vendor's roadmap and priorities.

Negotiation leverage: Without credible alternatives, organizations lose bargaining power in contract negotiations, often resulting in unfavorable terms and pricing.

Organizational psychology: Teams working within locked-in environments develop learned helplessness, accepting limitations rather than seeking creative solutions.

Exit costs: The longer an organization remains with a single vendor, the more expensive and disruptive a potential migration becomes, creating a self-reinforcing cycle of dependency.

These hidden costs rarely appear in ROI calculations but can significantly impact an organization's agility and competitive position over time.

[2] The Containerization Revolution

Containerization represents one of the most significant paradigm shifts in software deployment since virtualization:

Historical context: Before containers, applications were deployed directly to operating systems, creating complex dependency management challenges and "works on my machine" problems.

Docker's impact: Docker popularized Linux containers by making them accessible to developers, creating a standard format for packaging and distributing applications.

Kubernetes' role: Google's open-sourcing of Kubernetes provided a standardized API for container orchestration, enabling portable deployments across different infrastructure providers.

Cloud native ecosystem: The Cloud Native Computing Foundation (CNCF) has fostered a rich ecosystem of tools and practices around containerization, from service meshes to observability platforms.

This revolution has fundamentally changed how software is built, deployed, and operated, enabling the freedom stack approach described in this guide.

More from Brad

Ready to put these ideas to work? See all advisory offerings →