Creating, managing and provisioning a Cloud infrastructure is one of the main efforts of a Cloud Provider. Being able to automate this process can save time and money.
In order to do this, there are two different paths or approaches: DevOps and Platform Engineer.
For those who were in need of a clear explanation about their differences:
- With the term DevOps , we refer to a set of practices and tools that are useful in improving the ability to organise and deliver IT services and applications with greater speed than traditional development processes.
With such an approach, the Development Team and the Operational Team can work together effectively and continuously throughout the entire software lifecycle, from its development phase, through testing and deployment, to maintenance and upgrade operations. - With the term Platform Engineer, on the other hand, we refer to a "new" approach that intends to keep everything Dev-related separated from the operational and infrastructural branches.
The goal is to separate what the DevOps figure combines and allow the developer figure to specialise more, without knowing what's related to the on-going operations.
Since the last KubeCon North America, we've had confirmation of how DevOps oriented tools are increasingly distant from Platform Engineer oriented tools, and how the latters are gradually attracting the attention of the Cloud Native community.
To explore these, as well as additional topics related to the Cloud Native world that emerged in Detroit last October, we invite you to read KubeCon North America 2022: Highlights.
Coming back to us, in this article our intent is to focus on Terraform and Crossplane, two tools related to the infrastructure and its elements. One of these is relatable to the DevOps approach, whilst the other is more Platform Engineer Oriented. These two different tools present different potentials and functionalities.
First it must be said that behind the both of them, there is a whole world that needs to be studied and learnt. Before highlighting the differences, I'd like to delve into what they have in common:
- Both allow the IT infrastructure to be modeled through thedeclarative approach;
- Both support the management of a myriad of different infrastructures,as well as software using plug-ins and providers;
- Both are open source tools with strong communities.
With that being said, let us delve into the differences between the two.
Terraform for Infrastructure as a Code
Let's start with Terraform: Hashicorp's tool for IaaC (Infrastructure-as-a-Code).
It can be used to automatically create any cloud service, including networks, services, firewalls, databases etc. Among its capabilities, the fact that Terraform is not tied to any particular cloud provider and allows for multicloud strategies, whilst facilitating migrations definitely stands out.
The main advantage of using Terraform is the ability to manage any infrastructure with a DevOps philosophy. Based on a declarative approach, in which the entire infrastructure is described in a series of text files, Terraform performs the necessary actions that will lead to the deployment of each described element, without any additional concerns. In this way, the entire infrastructure is already documented and, more importantly, replicable at any time. This logic contrasts with the imperative model in which, previously, each component had to be installed and configured by hand, leaving ample room for errors and the impossibility of having a controlled environment.
Terraform allows to write a file in which the DevOps team can state what the infrastructure resource requirements are. For example, 3 Public Cloud instances on CloudFire provider with 4vCPU and 8GB RAM and 50GB of Scalable Storage each. In turn, Terraform proceeds to provision the instances using the API of the requested Public Cloud service.
Once the operations are completed and the system is brought to the desired state (i.e., the state declared in the file), Terraform saves the state of those resources.
This last process, i.e., saving the state of the newly provisioned resources, becomes useful should the infrastructure requirements any changes. This way if one needed to increase the number of instances to 4, by simply declaring it in the file, Terraform would proceed to create only the fourth instance, reading the state of the other 3 previously provisioned instances. Conversely, if the instances were to be changed manually, using the Public Cloud service dashboard, Terraform would be able to restore the state of the infrastructure to the state declared in the configuration file, hence modifying and/or deleting the externally created resources.
As with any tool, there are advantages and disadvantages:
- One advantage is certainly that the infrastructure finally becomes a set of resources that can always be provisioned in the same way, as if they were clones with a state associated to those resources;
- One disadvantage is related to the fact that, unless run manually, Terraform is not in-real-time-aware of the state of resources or changes made to the infrastructure's configuration file. This means that it is necessary to run Terraform periodically to ensure alignment between the desired state and the resources actually running.
- Albeit relative, another "flaw" is that Terraform uses its own language, HCL, for writing configuration files, which forces the user to learn it.
- Last but not least, Terraform is a tool created to declare the desired end state of resources and it's not too suitable to be used as a tool for generating templates or managing intermediate state transitions.
Crossplane for control plane cloud native
Born as a project in the "Incubating phase" within the CNCF Landscape, Crossplan instead extends the concept of IaaS by using the Kubernetes reconciliation engine so that the desired state, declared in the infrastructure's configuration file, gets continuously confronted with the current state. The necessary actions for resource reconciliation are performed in full autonomy.
The peculiarity of Crossplane is that it extends Kubernetes functionality by applying it to scenarios that differ from typical Kubernetes' resources, such as POD, Services, etc. It hence makes infrastructure resources "packaged" by the Operational department available to developers.
Of course, all that glitters is not gold. Crossplane also presents flaws. On the strength of a very large community, it provides integrations for many resources. However, the coverage is obviously not total. There can therefore be instances in which the users will have to write the integration for particular services themselves. It should also be mentioned that Crossplane can use Terraform as a conduit for action execution, a peculiarity that makes it suitable for gradual integration into infrastructures that already use Terraform.
Does one tool exclude the other?
In conclusion, we'd like to once again highlight the fact that Terraform is a DevOps oriented tool ♾️ . As such, it lends itself well to environments where Developers are also able to manage the infrastructure as a whole. Crossplane, on the other hand, is more Platform Engineer oriented ☸️, meaning that Developers are also able to instantiate parts of the infrastructure as if they were simple PODs or other Kubernetes components. This will provide the Operational team with controlled pools of resources that can be provisioned or modified without the danger of making destructive changes to sensitive parts of the infrastructure.
This does not detract from the fact that the two tools can be used together 💥 to better orchestrate an organisation's IT infrastructure. Such an approach would allow to manage sensitive parts less automatically using Terraform, whilst making resource pools available in a self-service manner to different departments with Crossplane.
I hope I was able to provide you with a good overview of Terraform and Crossplane with this article. Please keep in mind that the DevOps and Platform Engineer worlds don't simply end here 👀. As a matter of fact, within the infrastructural domain, there are other tools, such as FluxCD and Argo CD with different features. CloudFire's Team is constantly devoting time to these tools, as we'll get to know together later! ☁️🔥
