Managing cloud services and resources is a hard task if you are doing it by hand, especially on an multi cloud architecture. With multiple accounts over cloud providers, it gets hard to visualize all services that are being used, for example one application can have components spread over several cloud providers. Another pain point is making sure that all the services and resources are always in the desired state, for example if a developer has access to the account and changes some configuration that was not expected, that could cause an assortment of problems.
How do we solve that?
The first problem here is that when the resources are being managed by a human, so we’ll be using IaC (infrastructure as code), which means now the services and resources will be declared as code by a human and managed by a tool. With IaC we can ensure that:
- the same services / resources will be created every time needed
- previous versions could be restored, since the code will be version controlled
- the developer doesn’t need to have full access to the cloud provider account, since we can put infrastructure management on CI/CD pipeline
Here are some examples of IaC tools
Pulumi
- Pros
- Large community using it
- Support for most cloud providers
AWS CDK
- Pros
- Support for all AWS resources and services
- Maintained by Amazon
- Cons
- Can only be used for AWS
- Community using it is not as big as the other tools
Terraform
- Pros
- Most used tool
- Tested and maintained for a long time
- Support for most cloud providers
- Cons
- Uses Hashicorp’s specific configuration language (HCL)
- Needs a storage to sync state
- Decentralizes task execution, making it hard to audit
Crossplane
- Pros
- Uses a Kubernetes operator
- Supported by CNCF
- Is recent but already has attracted a big community
- Is the only tool that synchronizes state automatically
- Cons
- Requires Kubernetes knowledge
Which did I choose?
After using Terraform for a while, I came across Cossplane and decided to give it a try. The thing that caught my attention was the ability to synchronize state automatically, that means that if some developer changes a setting on the cloud provider, Crossplane will make sure it gets back to the desired state. The other thing, not as relevant as the first, is that Crossplane uses Kubernetes CRDs (custom resource definitions), which means that everyone familiar with yaml and Kubernetes can easily use it.
My first fear was that Crossplane is relatively new, compared to Terraform, but most cloud providers and resources are supported already, check out the list of available providers here. The second thing that worried me was that I needed one Crossplane to deal with multiple accounts for multiple providers, that also is easy to solve using provider configurations.
At the end of the day it doesn’t really matter what you choose, as long as it gets the job done!