Terraform is about simplicity

The success of Terraform in the Ops community is not surprising. Ops can manage easily IaaS resources and their dependencies in a simple file and bring “infra as code” benefits to the company, such as composability, reuse and standardization.

Terraform is also Open-Source and comes with a rich library of reusable and verified modules to ease and accelerate the deployment of infrastructures. So in just a few commands it becomes possible to install and configure complex infrastructures on different clouds providers (Aws, Azure, Google Cloud…) and PaaS (Heroku, Docker Cloud…).

But wait, nowadays terraform is mostly used and managed by Sys Admins/Ops.
This implies that in a majority of cases, when developers or application managers want to deploy an app, they still need to create a request in a ticketing system for the Ops.
Or even train themselves on the tool to provision the infrastructure by themselves, which might be sensitive regarding secrets, usually not shared easily across the organization, and kepts at Ops level.

Can we go further ? Can we bring Terraform to DevOps at the company scale?

From Terraform to Terraform as a service

So Terraform is originally an Ops tool. This is where Alien4cloud comes in to bring Terraform benefits to the different profiles in IT teams across the enterprise.

Alien4cloud is a collaborative platform facilitating DevOps as it allows Dev and Ops to collaborate on the design and deployment of an application.
To design portable applications developers can reuse components, such as Application, Middleware or Infrastructure components. As for Terraform, all theses components are described in a simple file and are reusable to speed up the design phase. To go further with composability, reusability and collaboration, components are stored in the Alien4cloud catalog and developers from different teams can share the components to design the application Blueprint even faster. As a result, the entire application lifecycle is described in a TOSCA blueprint!

Note that TOSCA is a descriptive language. By leveraging TOSCA and the structure it induces, we describe the life cycle of the component and its possible relationships with other components. The implementation must then follow the logic of the description. This implicitly favors best practices and reinforces standardization throughout the organization.

Download our free white paper to learn more about how TOSCA ease DevOps adoption

Now that the blueprint is ready, developers need to deploy the app and nobody wants to wait or to create a ticket. We just want to click deploy. Self- Service deployment is a major challenge of DevOps and Alien4cloud offers a unique solution.

How does it work?

Ops can configure resources up-front for the different infrastructures, Iaas, PaaS, CaaS and can also leverage various configuration tools such as Ansible, Chef, Puppet, Terraform… Each infrastructure resources can be configured independently and precisely thanks to a management system with fine-grained parameters and access rights. This is how Ops are able to provide the resources in self-service for developers to deploy their application in full autonomy, while ensuring security and control.

 

Terraform for Ops Vs Terraform as self-service

 

If your Ops teams is already using terraform and the plan is to go DevOps, start with the Alien4cloud open-source version:
https://alien4cloud.github.io/#/documentation/1.4.0/getting_started/new_getting_started.html

Here is an example to provision a Compute and a Security Group on Openstack using Terraform:
https://github.com/alien4cloud/csar-public-library/blob/develop/org/alien4cloud/terraform/openstack/readme.md

Contact us for more information:
https://alien4cloud.github.io/community/index.html

Leave a Reply