Do you manage multiple projects across multiple different environments? Are you an ISV or customer success team managing multiple customers on multiple cloud providers?

If so, then you need flexible deployment. In this article, I'll discuss what flexible deployment is, the various models for flexible deployment, and how TinyStacks can help you achieve it.

Flexible deployment vs. traditional deployment

Traditionally, software application deployment has been an all-hands-on-deck affair. Developers, system administrators, and support personnel all come together to get a software system working in production.

The effort is usually manual, painstaking, and error-prone. When it comes time to ship changes, the entire process is rinse-and-repeat.

Such a deployment process isn't anywhere near flexible. Indeed, it's rigid and brittle.

The first step towards a more flexible infrastructure is to create an automated DevOps pipeline that enables you to deploy into your customer's VPC on demand. This results in a multi-stage DevOps pipeline through which you can push and test all application changes before you deliver them to customers.

Getting to this stage for just a single customer and a cloud provider is an effort in itself. It involves creating a versioned Infrastructure-as-Code (IaC) architecture that can deploy to any stage on demand. Writing modular, reusable code and maintaining a DRY code base is key to success and long-term maintenance.

But for many software companies, the challenges don't stop there.

Traditionally, many of us are used to targeting a single hosting environment with our application deployments. Maybe we're deploying our apps on Amazon Web Services (AWS) because that's what the rest of our company uses. Or maybe we're deploying to an on-premises environment for legacy reasons.

In that case, the deployment strategy is simple: write something that works for the single target platform.

But many software teams need to support multiple customers who need their applications deployed into their own environments. And that's where things get complicated.

Some customers may run on AWS. Others run on Microsoft Azure, Google Cloud Platform (GCP), or more boutique offerings. You may even find yourself serving government intelligence agencies who require you to deploy into a "secret" air-gapped region.

Flexible deployment is the ability to deploy your application to multiple production deployment environments. It means modifying both your deployment pipeline and your application itself so that it can run for multiple customers, in multiple clouds.

The benefits of flexible deployment

Building out a flexible deployment system can take a lot of work. But it also brings a number of benefits:

Expanding your market. Your team may have built your app first on AWS. But then you land a major customer who's all-in on Azure. If you can't release your software where your customers need it, you could end up missing out on some big business opportunities.

Speed of delivery. Building flexible deployment into your DevOps pipeline means you can use the same processes you use for your "traditional" deployment to deploy to multiple customer environments.

Ease of maintenance. In the past, application teams have supported customer deployments outside of their "normal" deployment as one-offs. This means each environment needs to be maintained and upgraded manually. This essentially eliminates all of the benefits of building a mature DevOps release pipeline.

By moving to flexible deployments, you can make multi-customer, multi-cloud deployments part of your official release process. This preserves all of the efficiency and security benefits your team gained by moving to a DevOps model.

Flexible deployment levels

Not every application needs to support every type of deployment imaginable. Creating a new production deployment target is a heavy lift. Teams will generally only undertake this work if there's a demonstrable market.

With that in mind, let's take a look at the levels of flexible deployment - and what's involved in ascending the ladder.

Automated release

The first step is getting to the initial rung of a standard DevOps maturity model: enabling an automated release that targets a customer's VPC.

As discussed above, this in itself is a huge undertaking. If you're currently deploying manually into your customer's environment, you'll need to make major changes to your deployment process. These include:

• Driving a multi-stage deployment (dev, test, staging, prod) via configuration;
• Refactoring code according to the DRY principle to eliminate redundancies;
• Setting up sophisticated monitoring and alerting to detect any problems with new releases before they hit production.

Multi-Customer

From there, the challenge becomes supporting more than a single customer on a single cloud provider.

There are a few major considerations to consider when moving to a multi-customer model:

Account isolation. If you're targeting a customer's existing cloud account, then your customer's assets are already isolated. If you're managing cloud accounts on behalf of your customers, it's recommended that you create one account per customer.

Build and release customization. It's likely that each customer will have points where their installation must be custom-tailored to their environment. This could involve releasing only specific applications or services to customers who have licensed them. But it could also be involved as integrating with your customer's preferred authentication and authorization services (e.g., Microsoft Active Directory). Such options can be controlled via configuration as part of your automated DevOps release process.

Multi-Cloud

By far the most popular flexible deployment model these days is a multi-cloud model. This involves targeting your deployments for one or more cloud vendors.

There are three major considerations with multi-cloud deployment. The first is packaging your application so it can run on any cloud provider. Fortunately, Docker has made this process pretty easy. All major cloud providers have some features (in some cases, multiple features!) for running Docker containers.

The second is creating IaC deployments for multiple cloud vendors. Some teams accomplish this by using an IaC tool that can target multiple cloud providers, such as Terraform.

The third is designing your application's architecture so that it can work across multiple cloud providers. This means making decisions about handling fundamental issues like storage, authentication, monitoring, and real-time data processing. It also means building abstraction layers into your code to enable your app to work no matter what cloud it's sitting on.

Implementation challenges for flexible deployment

Flexible deployments can open up doors in terms of added customer reach and revenue. But they're not without their challenges.

The largest challenge is re-architecting your application so that it can work regardless of the environment. This can entail:

• Customizing your app to fit each customer's environment and service plan
• Authoring separate IaC deployments for each cloud provider you support
• Creating homespun implementations of certain services (e.g., authentication and authorization) rather than relying on a cloud-specific service
• Creating API layers that abstract out common cloud services (e.g., secret storage) so that they can be used in a provider-agnostic format

These new features all take time to create and maintain.

Another challenge is ensuring you retain a solid developer and DevOps experience. Managing multiple customers is hard. Managing multiple customers across multiple cloud environments is even harder. Having a single pane of glass through which to manage and monitor deployments and application runtime state is critical.

How TinyStacks can help

Building out a flexible deployment structure is hard work. It's heavy lifting that takes time that your development team could otherwise be spending on building new features.

We built TinyStacks to make flexible deployments easy. You can use TinyStacks to deploy your applications and any corresponding infrastructure into your customer's VPCs in days, not weeks. You can then manage all of your multi-customer, multi-cloud deployments through a single pane of glass. Customers can easily uptake application changes with a single button click.

Contact us today to learn how to onboard!