AOTP Dev

In my new role on the Portworx team here at Pure, I spend a lot of time building up and tearing down Kubernetes deployments in different cloud environments. We actually have a tool developed in house that does this for our demo environments. It’s an amazing tool that lets me automatically spin up an environment based on what I need to show to customers. I’m never content with the tools I have and wonder if I could build something myself.

There are a bunch of solutions in the infrastructure space to help with provisioning – Ansible, Terraform, Salt, Pulumi to name a few. A lot of the customers and peers I work with have their own catalog of assets to help them deploy infrastructure that then gets K8s layered on afterwards. I find though that increasingly the DSLs for each of these solutions are too heavy and complicated. They are built for a more general case than I need, which makes the abstractions not as useful. Generally, I need to:

• deploy a VPC, in a region of my choosing
• create a subnet to host VMs
• build routing from the internet to the subnet
• create security rules to allow the right traffic
• build VMs & add tools
• install Kubernetes
• install Portworx

For the last few weeks I’ve been testing out the SDKs from AWS, Azure and GCP to see if it makes sense to just use a library from each hyperscaler to build what I want.

Disclaimer: I am not a career developer. I have dabbled in all of the primary languages these SDKs support, but I am not a trained professional. Don’t try this at home. Or if you do, be aware your results may vary. Also, it’s important to note that your bills with these public cloud environments will vary as well! Take care before you run arbitrary code to deploy cloud infrastructure.

With that PSA out of the way, I thought I’d start with a comparison of the languages supported by each of Azure, AWS, and GCP. I found myself flipping between the three frequently to compare and thought it would be useful to put this out there so anyone else with the same idea has a resource to see in one place. The SDK pages for each are here:

AWS SDK list can be found here.
The Azure SDK list can be found here.
Google Cloud’s list of SDKs are here.

Complicating this analysis is the fact that from the perspective of these public cloud providers, when they talk about an SDK for interacting with their services, they see the infrastructure pieces as only one service. For Infrastructure Nerds like myself, it’s hard to wrap your head around that. Aren’t the infrastructure blocks the most important pieces? No. Not anymore. Many, MANY customers of these platforms use the higher order services to support their business, and they are not interested in starting with deploying a set of VMs and plumbing them together. So the infrastructure capabilities and APIs are really just one of many.

Here’s a quick table with the languages supported by each, all in one place.

Provider	C++	Go	Java	JS	.NET	Node.js	PHP	Python	Ruby
AWS	✅	✅	✅	✅	✅	✅	✅	✅	✅
Azure		✅	✅	✅	✅			✅
GCP		✅	✅			✅		✅

These are the list of languages listed on the main pages. GCP also has a link on their page to “additional languages” which lists C#, PHP and Ruby. It’s not super clear why these are seperate. The Azure page lists C++, C, Android and iOS on their page that links to traditional github repos with the SDKs, but the other langugages have a dedicated Azure SDK page for them. I consider the languages with dedicated pages a sign of kind of “first party support”.

If you’re looking for languages that can cover all of the providers – it looks like the main contenders are Go, Java, Python and to a certain extend JavaScript – if you include Node.js as a subset of JS.

The next chapter here will be evaluating how to use each of these languages to deploy infrastructure.