Some notes about "coding" infrastructure instead of using markup-like yaml, json or low-level cloud-provider template languages. This becomes more and more interesting since 2019, especially with AWS Cloud Development Kit, Pulumi etc.
Purpose: Learn to create Multi-Cloud native applications including their infrastructure with one preferred programming language.
Do not learn markup languages changing over the years, do not lock yourself into cloud-provider specific languages (even one can't avoid cloud-provider specific SDKs), just use your or your team's preferred programming language for everything. Using a "regular" programming language allows using "natural" logic, unit-testing, modularization... all the cool clean-code stuff we learned as best practice can be applied.
You may need to learn a new SDK/API and live with lack of completeness concerning the cloud provider's new hot stuff, and your "preferred" programming language for everything needs to be one of these depending on toolkit and time: .NET Core Languages (C#, F#...) Go, Java, Python, Typescript/Javascript (alphabetical order, not weighted by value). There may also be "other" types of erroneous behaviour compared to a pure descriptive template language. Your modularization concept may not match the "programmed" one.
Infrastructure as Code examples demonstrating Terraform, Cloudformation and higher level development kits (frameworks and tools) to avoid handwritten IaC descriptors.
The following list raises no claims on completeness (please open an issue or a pull request for enhancements).
Writing Cloudformation Templates for complex infrastructure is well known and works like a charm... and it can be configuration hell depending on the complexity of your infrastructure.
Beside the template language for Cloudformation driven Infrastructure, AWS offers the Cloud Development Kit (CDK) with Typescript as the default language with full AWS SDK support.
Handwritten Cloudformation templates is classified as HOLD on the Thoughtworks Tech Radar for good reasons.
In the end, one may state: "We want Infrastructure as Code, not Infrastructure as Text" (Thanks to Jack for this one).
The following tools finally produce Cloudformation Templates, provide (structural) shortcuts to Cloudformation and offer high-level development capabilities.
If you focus on serverless computing, use Serverless. This simplifies a lot, but may not be enough. If it's not enough for your use-case, DO NOT mix this, instead use a higher level toolkit.
This is the "official" Amazon way to use modern programming languages for convenient infrastructure deployment.
It has a developer friendly CLI and comes with support for several programming languages: By default TypeScript resp. JavaScript, Python, Java, .NET/C#.
To get familiar with it, visit the CDK Workshop for Typescript or Python-based introduction.
With a clear demand for using AWS this may be a preferred way to work with IaC.
Similar to Terraform then project CFN Modules provides a way to work with modularization within Cloudformation.
See the CFN Introduction for details.
Being familiar with Terraform this project may have the lowest conceptual obstacle.
This is a Python-based tool being around for quite some time and good reputation.
If you are familiar with Python, this mature tool may be a good option.
Sceptre is another tool to drive CloudFormation, also being around since 2017.
It has a Python background and provides support for templates written in JSON, YAML, Jinja2 or Python DSLs such as Troposphere.
Stack Deployment Tool is another option to simplify the work with Cloudformation templates.
This is part of the Open Source projects of Capital One
Terraform may be rated as some incumbent of IaC tools.
It has been the best tool for infrastructure for years now, is widely adopted, written with the Hashicorp Language (HCL), offers understandable modularization, supports multiple cloud providers, and the descriptors appear tidier than e.g. pure Cloudformation templates.
Terraform is a well-known good practice to work on infrastructure and widely integrated with other tools and cloud environments, see for example the Pulumi Terraform Bridge.
Multi Cloud, Hybrid and Private Cloud approaches address the need to deploy infrastructure not only on dedicated hardware, your own on-premise datacenters etc. but also to any cloud provider environments (maybe due to policy to avoid Vendor Lock-in or simply global operative requirements).
The Pulumi Homepage describe itself as
Modern Infrastructure as Code. Declare cloud infrastructure using real languages. Enable developers and operators to work better together.
This in short summarizes today's developer orientation concerning cloud native company strategies.
See Github to get started.
See Heise about Pulumi 1.0 (2019-09)
This is an Open Source Could platform, coming as an extraction from the IBM Cloud universe.
See Apache OpenWhisk for details.
See IBM Cloud Functions to get started.
A (non-curated) list of classic Infrastructure as Code tools and discussion about IaC can be found in a Thorntech article.
Another approach and alternative platform is Cloudfoundry (Node.js Sample):
Cloud Foundry is an open source, multi-cloud application platform as a service governed by the Cloud Foundry Foundation.
Also see:
In case of not using Docker or browser based tools:
brew update && brew install azure-cliTest:
az account listIn case of not using Docker or Google Cloud Shell:
brew cask install gcloudAt the time of writing Python 2 is required to use the complete feature stack of Google Cloud.
Use Pyenv for multiple Python versions, install at least one LTS Python 2 and Python 3 version and select the required version locally: e.g.
pyenv local 2.7.16If this version is installed using pyenv, the command creates
a file .python-version in the local filesystem. Ensure either
an appropriate development guide or commit it to your SCM.
Test:
gcloud infoKubernetes is a container-orchestration tool and widely used especially on cloud infrastructures.
See Kubernetes.io for details.
The team around AWS CDK derived another toolkit following the idea of writing infrastructure as code in different regular programming languages instead of text (yaml).
It is called CDK8s and can be used to deploy on any Kubernetes Cluster, not only the cloud provider solutions like Amazon EKS or Google GKE.
Follow the docs and samples on the CDK8s website to create Kubernetes pods.