Managing Cloud Services via Kubernetes CRDs
All three major cloud providers (AWS/Azure/GCP) now support a way to provision and manage cloud services from Kubernetes via custom resource definitions (CRDs). AWS has AWS Controllers for Kubernetes (ACK) in developer preview; Azure recently launched Azure Service Operator (deprecating Open Service Broker for Azure); GCP has Config Connector as an add-on to GKE. While Infrastructure-as-Code (IaC) tools such as Terraform, Ansible, and Puppet are still widely used to manage cloud infrastructure, the support for Kubernetes-managed cloud services suggests a huge shift towards organizations making Kubernetes the focal point of their cloud infrastructure. The upside here is that developers can now use the same tools to manage Kubernetes applications and other cloud services using the Kubernetes APIs, potentially simplifying the workflow. However, this tight coupling of Kubernetes and the rest of your cloud workloads may not be desired depending on your current infrastructure workflow or Kubernetes expertise.
Pulumi
Speaking of IaC tools, Pulumi recently announced its $37.5 million Series B funding to challenge Terraform’s dominance in this space. Unlike traditional IaC products, Pulumi opted to enable developers to write infrastructure code in their favorite languages (e.g. Go, Python, Javascript) instead of pushing yet-another JSON/YAML-based domain-specific language. This choice allows Pulumi to be more flexible than Terraform and enables developers to make use of existing testing frameworks to validate their infrastructure. However, given its nascency, Pulumi’s community is quite small compared to Terraform.
Terragrunt & TFSEC
Unlike Pulumi, Terraform addresses some of its deficiencies through its open-source community. Terragrunt is a thin wrapper around Terraform to help teams manage large Terraform projects by organizing configurations into versioned modules. Terragrunt implements some best practices laid out by Gruntwork co-founder Yevgeniy Brikman. While Terragrunt is fully open-source, Gruntwork recently announced commercial support for enterprises looking for more production-ready services. TFSEC is another open-source tool that complements Terraform projects. It uses static analysis to flag potential security threats to infrastructure code. As security bakes more into the DevSecOps movement, tools like tfsec will become more important in the future.
Tekton
The CI/CD market is saturated with established tools like Jenkins and Spinnaker as well as emergent cloud-native tools like ArgoCD. Tekton is a new player in this space, focused on Kubernetes workloads. Tekton started as part of the Knative project and was later donated to the Continuous Delivery Foundation (CDF). The differentiating factor for Tekton is that it defines the pipelines via Kubernetes CRDs. This allows pipelines to inherit native Kubernetes features (e.g. rollbacks) and also integrate with existing tools such as Jenkins X or ArgoCD to support complex, end-to-end CI/CD pipelines.
Trivy
Vulnerability scanning for containers is becoming an important part of any CI/CD pipelines. Like the CI/CD market, there are plenty of open-source and commercial tools including Docker Bench for Security, Clair, Cilium, Anchore Engine, and Falco. Trivy is a tool from Aqua Security that not only scans the container but also the underlying packages in the code. Combined with Aqua Security’s kube-bench, organizations can more easily bake security into the application development workflow.
ShellCheck
Despite tremendous improvements in the infrastructure tooling space, shell scripts remain in various workflows to get simple tasks done. ShellCheck is a static analysis tool to lint shell scripts for syntax and common mistakes. ShellCheck can run from the web, terminal/CI, as well as in your favorite text editor (e.g. Vim, Sublime, Atom, VS Code).
Pitest/Stryker
Pitest (Java) and Stryker (Javascript, C#, Scala) both implement mutation testing in their respective languages. Mutation testing gauges the quality of tests by injecting faults to tests and checking if the tests still pass even with the mutation. A good unit test should fail when a mutation occurs in the test case. Mutation testing complement test coverage to detect both untested and inadequately tested code.
Litmus
Back in 2011, Netflix popularized chaos engineering with Chaos Monkey as part of the Simian Army suite of tools. In the Kubernetes world, there are plenty of chaos engineering tools such as chaoskube, kube-monkey, and PowerfulSeal as well as commercial platforms like Gremlin. I want to highlight Litmus as a mature chaos engineering solution that is extensible and easy to use. Litmus is a lightweight Kubernetes operator consisting of ChaosEngine, ChaosExperiment, and ChaosResult. Litmus supports fine-grained experiments that go beyond simply killing random pods in a namespace and displays the results via ChaosResult CRD instead of leaving observability up to the users.
There are other technologies and trends that I’m watching (e.g. zero-trust architecture, micro-frontends, service-mesh tools) but left out due to inexperience. If there are other tools or trends that I missed, feel free to comment below.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
