pst

The article lost me at making pods mutable.

Terraform certainly has its fair share of quirks, but that's no different from any other language.

However, I think it's fair to say that the infrastructure as code ecosystem is still much younger and therefore less mature. And there are various things that are standard in application development toolchains that don't exist for IaC yet.

Take my focus, use-case specific frameworks for example. If I'm building a web application, I don't write my own request routing or authentication. But for Terraform, the majority of teams have to start from scratch, even for common use-cases. Yes, there are re-usable modules, but they're comparable to libraries and integrating various modules is still a lot of effort.

If my use-case is building a Jamstack website, doing so using Gatsby gets me started faster, gives me a modern developer experience and means I can re-use community tested and maintained components to reduce the bespoke code I have to write and maintain.

I'm trying to do the exact same thing for Iac with Kubestack.

Kubestack is an open-source Terraform framework for managed Kubernetes. If your use-case is provisioning and maintaining EKS, AKS or GKE using Terraform, Kubestack may be worth trying. In my obviously creator-biased opinion.

It helps you with the typical framework like workflow to get started faster and scaffold a repository with one command, then bring up a local development environment with the next.

Yes, the long feedback cycles of IaC can be annoying. That's why I'm trying to improve the developer experience by providing an auto updating local development environment.

For all modules (EKS, AKS, GKE) I maintain as part of the Kubestack framework, I also maintain a local variant. These accept the same input variables, but instead of provisioning cloud resources, provisions "mock" clusters locally using Docker containers as the cluster nodes.

The kbst CLI watches for changes in the repository, and then runs Terraform locally and dynamically replaces the module source of the real cluster module with the local variant. Here's a video showing that in action: https://youtu.be/_VtakP6AdCs

Similarly, I provide a Docker image for each framework release to provide a tested combination of versions of Terraform, it's providers and the cloud CLI (aws, gcloud, az). The images are used to bootstrap, for CI/CD runs and for the occasionally required manual tasks (state mv, etc.) or disaster recovery.

Just to name two examples from the discussion here where the developer experience of Terraform lacks behind the equivalent application development tooling.

Many people underestimate IaC, probably because of all the 5 minute Terraform tutorials and demos out there. But what these miss is that the real work only starts when you have to get your automation ready for day-2 operations.

This is where I'm trying to provide a better developer experience through re-usable use-case specific modules, inheritance based environment configuration to avoid drift, and integration into a convenient but reliable GitOps workflows for teams from local development all the way to production.

Kubestack's code is open-source for two years in December. But I only got around writing documentation after leaving the DevOps consulting job that inspired the framework.

Anyone interested can give it a try: https://www.kubestack.com/ The site has links to the Slack channel (#kubestack on the Kubernetes Slack) and also the source on Github.

I ran for quite a while without any analytics after removing GA. I've now settled on Fathom for Kubestack.

It was important to me to be mindful about the privacy of my visitors but at the same time I need some data to see if I'm on the right track. Fathom seemed like a good compromise.

Thank you, and naturally I agree. That's why I am building a GitOps framework. If there is value in building an application on top of a high-level framework like Spring Boot, Ruby on Rails or Django - and there is - then teams should not build the infrastructure and automation from scratch either.

I needed a way to mock the trigger that would usually be sent from e.g. Github to your CI/CD system. This is what I use the Git hooks for.

The way it works is: To get the post-update hook to trigger, you have to push because post-update is triggered by git-receive-pack after a push. So this is why you create a local remote and push to it. This also mirrors the workflow when using the Kubestack framework for real infrastructure.

The goal for the local development environment was to mirror the real workflow. So that people can also use it to try the framework without having to create real cloud infrastructure.

So the hook also needs to trigger a pipeline. Because the best practice is to have the pipeline live with the code, the post-update script will checkout the pushed commit-hash to a third repository and will call the mock-pipeline shell script that's part of the checkout.

You will then see the terraform plan/apply output as part of the remote output coming from the Git push.

My framework does GitOps for infrastructure automation. It includes the managed K8s and supporting cloud resources. Not just workloads on the clusters.

Only the development environment is local.

OKRs aren't supposed to fix communication. They are supposed to guide your team to make day to day decisions that support the agreed goal.

What people call production nowadays...

Prices are stated per 30 days to make them easier to evaluate. Since actual pricing is per use and even pro-rated to the second the numbers would be really small and not really helpful otherwise.

Hi Ewout, we'd love to have you guys in for a visit. Send me an email to pst@cloudcontrol.de to discuss the details. Best Philipp

Have you considered using one of the PHP PaaS solutions like dotcloud, phpfog, pagodabox or cloudControl?

We build this since January 2009 and already had some great feedback from our developer community. We are a small Startup based in Europe and would love to hear your feedback.

I'm around to answer any questions you might have. Feel free to vote up. ;)