When you hear the phrase “cloud native,” is Kubernetes the first thing that comes to your mind? It is for me, and I expect I’m not alone. Kubernetes is now the second-largest open source project after Linux, and it’s the big fish in the cloud native pond. But there are many other projects in the CNCF landscape and the broader cloud native community.
So, I thought I’d list some cloud native tools that can be very useful for teams that aren’t using Kubernetes or aren’t using it for every workload. Here are 7 of them that I like a lot.
1. Nomad
Did you know there are container orchestrators besides Kubernetes? One of them is Nomad, made by the folks at HashiCorp.
I have yet to use Nomad in anger, but it’s a project that I’ve been interested in since it came out. It has a simpler architecture than Kubernetes, and it could be an excellent choice when you’d like something more scalable than Docker Swarm but not as involved as Kubernetes. You don’t have to choose between Kubernetes and Nomad though; some teams use them both for different workloads. One popular use case for Nomad is running batch jobs.
Nomad integrates very well with other HashiCorp tools, and it’s very fast. Also, you can use Cilium as a CNI with Nomad, which is very cool.
If you need to orchestrate some containers and Kubernetes seems like overkill, you might want to have a look at Nomad.
2. Pulumi
I spent some years pretty deep in the Infrastructure as Code world (I worked as an SRE at Puppet and was a Puppet user before that), and it’s a topic that still interests me quite a bit. For a while I thought Terraform had won the cloud provisioning tools space, and maybe it still has, but Pulumi is a newer alternative with some pretty cool aspects.
If you’re familiar with Terraform, you know it uses the HashiCorp Configuration Language (HCL). I don’t have anything against HCL, but it’s a Domain-specific language (DSL), not a full-blown programming language. One of the issues with custom DSLs is that they put an extra burden on users to learn the DSL and what patterns are useful.
Pulumi takes a different approach. With Pulumi, you can use languages that you already know, and you use the Pulumi SDK to pull in the specific Pulumi bits you need. It’s basically a library that adds the ability to provision cloud resources to your code. The supported languages are Python, Go, JavaScript, TypeScript, and C#. This means you also have access to the whole ecosystem of your language of choice while writing Pulimi code, including testing tools.
While I think that letting users work in the languages they want is generally the best approach, one of the advantages of a declarative DSL like HCL is that you can ensure the code people write will be idempotent. With procedural languages, there’s a possibility that a logic error in your code will cause very unexpected results. That’s the big tradeoff here.
Overall I really like Pulimi’s approach. I think it’s better to meet users where they’re at than to ask them to learn a DSL. The fact that HashiCorp recently built the Cloud Development Kit for Terraform (currently in beta), which allows you to write code for Terraform using the same languages that work with Pulumi, is another vote for Pulumi’s approach.
I love Terraform too, and if your shop is heavily invested in it, it may not be worth switching tools. But Pulimi is pretty dope and fun to play with.
3. Thanos
Everyone loves them some Prometheus, am I right? It’s definitely one of the most popular observability tools for working with Kubernetes and other cloud native apps. But how do you set up Prometheus so it’s highly available and scalable? And how do you deal with all the data?
That’s where Thanos comes in. As the GitHub README states, “Thanos is a set of components that can be composed into a highly available metric system with unlimited storage capacity, which can be added seamlessly on top of existing Prometheus deployments.” Managing storage is often a big pain point with metrics collection, so unlimited storage capacity sounds fantastic, and Thanos also adds high availability to Prometheus.
I love the Thanos design philosophy:
- Each subcommand should do one thing and do it well
- Write components that work together
- Make it easy to read, write, and, run components
Thanos is a CNCF Incubating project, and if you are collecting/storing metrics you should check it out.
4. etcd
I can already hear someone saying, “Wait, I thought this list wasn’t about Kubernetes, so why is etcd on it?” Well, while etcd is best known as the data store for Kubernetes clusters, you can do a lot more with it.
etcd is a distributed key-value store and can be used in some use cases often covered by tools like Zookeeper and Consul, like service discovery and storing configuration data. It uses the Raft consensus algorithm (Consul’s consensus protocol is also based on Raft), and there’s an easy-to-use CLI and API.
If you'd like to compare etcd and other key-value stores, there's a helpful page about that in the docs.
Depending on your use case, something like Consul or Vault might be a better fit, but keep etcd in mind when evaluating options for key-value stores.
5. Kuma
Remember virtual machines? Those were good times, right? It turns out that a lot of people are still using them, and teams that are not running containerized workloads have had a tougher time using service meshes like Istio and Linkerd.
Kuma is a service mesh that was designed to not only work with Kubernetes but also with VMs. Kuma is built on Envoy, and it allows teams to configure policies for things like Mutal TLS, health checks, circuit breakers, and distributed tracing with Zipkin or Datadog. I expect you could roll many of these features yourself with Envoy, but Kuma gives you a central place to manage them, and it abstracts away some of Envoy’s complexity.
The list of policy types that Kuma supports is very impressive. Kuma even supports some basic fault injection if you’d like to throw some chaos engineering into your service meshes.
Kuma was created by the team at Kong, and it integrates with the open source Kong Gateway. Kuma was donated to the CNCF and it’s currently a CNCF Sandbox project.
6. sigstore
If you follow me on Twitter or saw my previous post about companies I’m watching in 2022, you probably already know that I’m a bit of a sigstore fanboy. But for those of you who haven’t heard me rant about it, here’s why.
Software supply chain security has become a massive concern in the industry since the Solarwinds hack. It’s something that many software projects need to address, and that’s often more challenging for open source projects that have fewer resources. Sigstore is a set of open source tools that allow project maintainers to easily cryptographically sign their artifacts while allowing everyone else to verify and even monitor those signatures. There’s a high-level look at the sigstore toolset on the website.
So why am I so excited about new tooling for people signing software? I saw a great talk at KubeCon Los Angeles by Bob Callaway and Dan Lorenc that showed how difficult it would be to do those same processes without sigstore. I was extremely impressed by how easy they’ve made the whole process, and I love the amount of transparency the sigstore tools bring.
If you’re either building software releases or consuming them (which is probably most of you), it’s worth spending some time learning about sigstore. With support from The Linux Foundation and companies like Google, Red Hat, and VMware, sigstore is almost certain to become an industry standard.
7. OpenTelemetry
OpenTelemetry is a standard for distributed tracing that was created when the OpenTracing and OpenCensus projects merged. That merger reduced a lot of confusion in the tracing space, and OpenTelemetry has since been adopted by major vendors like Honeycomb, Datadog, New Relic, and Dynatrace.
I almost didn’t include OpenTelemetry in this list as I thought of it more as a specification than a tool. But tracing is a vital concern for teams operating distributed systems, and OpenTelemetry has significantly impacted the observability space by providing a common specification that’s now widely used. This helps reduce vendor lock-in, which is a big concern with observability tools. The OpenTelemetry project contains APIs and SDKs, the Open Telemetry Collector, and much more, so I feel comfortable arguing that it at least contains some tools. You can see what’s available at the OpenTelemetry Registry.
The OpenTelemetry specification recently hit version 1.0, which is fantastic. Congratulations and thanks to all of the folks who have contributed to its success.
Conclusion
There are many more exciting cloud native tools out there. When I create lists like this, there are almost always folks who have ideas for other tools that I should have included. If you have a tool that you’d like to mention, feel free to join the discussion on Reddit, or send me a tweet.
Photo by Jametlene Reskp on Unsplash
Top comments (0)