When it comes to Kubernetes, there are multiple sides of the spectrum, but primarily around development, operations, and security. Kubernetes isn't just a platform where you click a few buttons, write some code, and you're up and running. It takes time, shifting scope, and teamwork to really make it possible.
One of the many problems that teams run into is configuration data and how to solve for the problem of data being all over the place throughout multiple stages and code bases.
In this blog post, you'll learn about solving the Dev and Ops problem along with how CloudTruth can assist
Many organizations in today's world are trying to figure out how to keep up with the ever-growing change of shifting to a more cloud-based and hybrid model. Funny enough, the buzz words that we all hear like "cloud-native", "Day Two Operations", and "single pane of glass" are actually starting to become true. Engineers are now living in a world where because of the push to the cloud, they have to start designing architecture and deployments around things like Kubernetes and containers. Because of the shift to the cloud and platforms like Kubernetes, specing out hard drives and ordering servers aren't as relevant, which ultimately means engineers are now more focused on Day Two operations. Finally, with all of the tools and different pieces of the cloud that makes all of this possible, you need one, single place to manage it all.
When all of the pieces come together, you also have to think about the insane amount of configuration data, environment variables, and secrets. Authentication to the cloud from Kubernetes alone is a huge lift. RBAC policies, authentication, authorization, and a lot more go into it. Configuration data and environment variables for plain-text data that spans across multiple stages like Dev, Staging, and Prod are crucial for ensuring that what's being deployed is as expected.
Let's dive in a bit more.
In the previous section, The Kubernetes Lift, we touched on the shift in many aspects of engineering. Notice how you didn't read that the engineers specified were in Operations or Development. That's because, at this point in the technology space, they're doing one in the same thing. Sure, Developers are writing more application code and Operations are thinking more about architecture, but at the end of the day, it ends up all blending together at the end. That's because platforms like Kubernetes and other cloud-native platforms aren't geared towards one silo because those silos cannot exist in today's technology world. Instead, application developers and infrastructure engineers need to work together for one common goal; to deploy good software.
When deploying good software and containerized applications to Kubernetes, there's a lot that goes into it behind the scenes. This topic can take up literally an entire book, but a few things that come to mind are:
All of the points above are what application developers, infrastructure engineers, and DevOps professionals are thinking about. The truth of the matter is, there's way too much configuration data out in source control, stored in .env files, and spanned across multiple environments that aren't managed in one centralized location.
That's where CloudTruth comes into play.
Having the ability to store configuration data, secrets, environment variables, and any other environment-specific configuration in one location is crucial. What typically happens in organizations is as a solution starts to be used, it doesn't seem like a big deal to have a little environment variable file or some config data stored here and there. It's low-hanging fruit, so people think. Then, 6 months, 1 year, 5 years down the line, it's madness. You have configuration data in multiple locations, multiple .env files that span tens of hundreds of lines, and spotty attempts to store secrets that are encrypted at rest and in transit.
That's where CloudTruth comes into play. Now, before thinking "uh oh, here comes the sales pitch", give us 2 minutes and read on…
Let's say you have three containerized applications, a frontend, some middleware, and a backend. Those applications most likely have multiple Kubernetes Manifests including:
and perhaps even a few others. So right there, you have four Kubernetes Manifests. For each of those Manifests, you'll have configuration data spread across them. Things like the container image, the container image version, how many replicas, what secrets are used, etc… So you have to figure out where to store it all, how to store it, and who has access to what to update the data when needed.
Once you have all of that figured out, now you have to do it for every single environment; development, staging, QA, and production. Not only do you begin to use multiple tools and platforms to help you with all of this, but you have to use those tools and platforms throughout multiple environments.
This is where CloudTruth comes into play. With CloudTruth, you can store:
and literally, any other type of data, including Kubernetes Manifests, inside of the platform. For example, below is a screenshot of a Kubernetes Manifest template. Notice on the left side that there's a parameter called . Then, on the right side of the Production environment, the imagePullPolicyis defined and you can see the value. With that, engineers can use the same exact Kubernetes Manifest and simply swap out values based on environments. No more having to manage multiple .env files, parameters, or Kubernetes Manifests.
In today's cloud and the microservices-driven world, there are a lot of tools to choose from. There are a lot of platforms, a lot of data, and a lot of headaches for engineers making architecture decisions. Our goal is to help mitigate as much of that as possible.
If you’d like to give CloudTruth a shot, you don't have to talk to any sales professionals to sign up for a trial. In fact, we won't even try to sell it to you. There is a free forever version right here.