August 1, 2022
How DIY Kills Your Deployment Reliability
Written by: Michael Levan
Reliable deployments are the make or break between you and your competitor going to market faster. Not only is this a problem for leadership teams, but it ends up becoming a major headache for App Developers and DevOps Engineers.
Instead of architecting value-driven work, engineers and developers are stuck putting out fires 24/7. To address this situation, businesses should invest in giving engineers the time to create reliable deployment methodologies across the entire SDLC.
In this blog post, you're going to learn about current DIY methods that organizations typically use for deployments and how CloudTruth can help manage those headaches.
Parameters and Variables
At the forefront of every automated deployment or application configuration is:
- Parameters that you're passing in at runtime
The problem with DIY is those parameters and variables are sitting in some file somewhere, some secrets manager, or maybe even in the secrets manager embedded in a CICD platform. The problem is there are different locations, which leads to major configuration sprawl and headaches when it comes to deploying anything. Whether it's a Terraform configuration, building a container image with a Dockerfile, or deploying a Helm Chart, there are a ton of configurations all over the place.
In a standard environment, you'll have environment variables that are sitting in source control with parameter and variable values. That means you have to manage not only a bunch of files but all of the values inside of those files. If you have multiple stages like Development, Staging/UAT, and Production, there will be a lot of data you have to manage, and it'll live in different locations inside of source control. For example, if you have four microservices, that's four different locations for all of your configuration data. Then, inside each of those locations, you have multiple stages to manage (dev, staging, prod).
Instead of going through all that trouble, you can use a solution to manage all the parameter and variable files per project. That solution is CloudTruth.
Centrally Managed Configurations and Secrets
Without secrets, whether they're DB connections, passwords, API keys, or authentication strings, most applications won't work. Apps won't be able to authenticate to other APIs or to databases for storing stateful data.
From a DevOps perspective, if you're, for example, deploying a Terraform configuration to your preferred cloud provider, you need to authenticate to the cloud provider. Once you're authenticated, you can then deploy the Terraform configuration.
You need secrets in each scenario from an App developer and DevOps engineer perspective.
The problem with secrets is that it's Yet Another Place To Manage.
Whether secrets are sitting inside your CICD platform, a secrets manager separate from how you're managing other configuration data, or some built-in solution like Kubernetes Secrets, you have to manage another location to store secrets.
With CloudTruth, you can manage plain-text configuration data and also manage secrets in the same way. The only difference is a click on a checkbox that tells CloudTruth that the value is a secret and just like that, your data is encrypted and ready to be used.
The CloudTruth way allows you to have configuration data that's both plain text and secrets in one location, so you don't have to worry about configuration sprawl.
Deployment Reliability and Consistency
Reliable deployments are the difference between engineers being happy at work versus being woken at 2:00 AM to put duct tape on an issue.
Reliable deployments are the difference between a business succeeding and being taken over by its competitors.
In today's engineering-led world, successful deployments and consistent deployments are literally what drive a business forward.
With configuration data stored in multiple different locations, whether it's parameters in plain text, secrets, Kubernetes Manifests, or Terraform configurations, there's no tried and true way to have a reliable deployment. There are far too many moving parts and different places that you have to worry about managing.
CloudTruth aims to fix this. CloudTruth is literally one location to manage any type of data you can think of. If all of your data is in one place, and deployments are using that one place to deploy workloads, you can't get much more reliable than that.
Expanding on the previous section, Deployment Reliability and Consistency, one of the biggest components to ensure the success of reliable deployments is repeatable deployments.
For example, if you are deploying via CICD to a cloud environment. The CICD pipeline will pull parameters, variables, secrets, and other configuration data from multiple locations. That means a lot of API calls and a lot of different steps in your CICD pipeline. If your secrets are in Vault, parameters/variables are in some environment file, and your Kubernetes Manifests are in source control, that are three different locations that you have to not only manage but ensure that the CICD pipeline has access to. Not to mention that a CICD pipeline calling out to three different locations will slow down your deployments.
With CloudTruth, you have one location to pull every piece of config data you need. Parameters, variables, secrets, Kubernetes Manifests, Terraform configuration files, and anything else that can be stored centrally.
Deployments are becoming not only a headache for DevOps Engineers and developers but for leadership teams. Business leaders want to move faster, and engineers want to avoid constantly putting out fires. One of the most impactful ways to make progress is to use a centrally managed configuration hub that integrates with existing systems such as AWS Secrets Manager, Vault, GitHub, etc.
CloudTruth decouples the management of your configuration from how the configuration is consumed.
Tag(s): Kubernetes , Configuration Management