Unhappy developers are all alike, all happy developers are happy in their own way.
So it was a joy to hear Guillaume Berche, Software Architect at Orange, and Mevan Samaratunga, Head of Platform Architecture MEA at VMware, describe their happiness with the ongoing integration of Cloud Foundry with the still-revolutionary concept of Infrastructure as Code (IaC) during Cloud Foundry Summit Europe in Basel, Switzerland.
Specifically, Guillaume and Mevan discussed Terraform during the Basel conference, presenting the ongoing work of a team of developers and architects from Orange, VMware, and SAP.
The Case for IaC
IaC is still not for everyone, but with the use of Terraform and Cloud Foundry, it is mature enough to be effective in a range of CI/CD (continuous integration and development) environments and their related DevOps cultures.
The popular question “Why?” surely applies to the Terraform-Cloud Foundry integration, and Guillaume addressed it by noting his role an administrator of developer requests. The challenge of multiple requests for Cloud Foundry spaces leads to challenges in provisioning all of them, and the task becomes ever more complicated with requests for microservices-based apps in modern CI/CD (continuous integration and development) environments.
Integrating Cloud Foundry with an IaC environment thus seems like a promising way to meet high numbers of provisioning requests while enabling developers to get closer to the actual infrastructure in a way that appeals to them.
The Case for Terraform IaC
Terraform is open source software developed by San Francisco-based (and globally dispersed) HashiCorp. It works with OpenStack, all the major public clouds, and VMware vSphere. Infrastructure is defined within its own syntax or in JSON.
The idea of being able to treat infrastructure as code, that is, to view it in the same way developers view apps and services, brings new levels of comfort to developers, Guillaume explained. Best practices can be replicated as the apps and services, platform, and infrastructure become one single environment from the developer’s point of view.
“We can substitute apps and services for infrastructure,and since it’s all code, it’s predictable.”
Terraform takes a declarative approach, in that developers can be (and must be) very explicit in defining precisely what they need. The idea is to imagine (or declare) what the configuration should be, then create a system that does what’s needed. Terraform also pushes its needs to the actual infrastructure environment (thus defining and declaring it along the way), rather than pulling it from a pre-existing setup.
Everybody and Everything Gets Closer
The obvious appeal of IaC to DevOps teams is to draw developers closer to actual operations and get operations a closer, better view of what developers are declaring they need. Automation is virtuous to IaC environments, as it is to Cloud Foundry. Automation is also an answer to reducing the complexity that today’s vast, open-source development and operations toolset can create, thus leading to the throughput and cost efficiencies enterprises expect from cloud computing and reducing errors.
Guillaume and Mevan outlined a Write-Plan-Create process in which Terraform permits “dry runs” and ensures a safe workflow across CFCR and CFAR (Cloud Foundry Container Runtime and Application Runtime), CredHub, and the UAA (User Account and Authentication) process.
Guillaume noted that there are several areas in which the Cloud Foundry/Terraform integration could use more development, including support for blue/green deployments, network policy, and the acceptance test environment.
Yet as a novelist may have written, in this happy world, we can thus see the future, like the sun, even without looking.
Readers who are interested in the technical details of how to configure, deploy, and manage this happy, virtual world can view the Basel presentation on YouTube:
