HomeOperationsAutomated OperationsWhat does HashiCorp's Series E of $175 million mean for cloud-native?

What does HashiCorp’s Series E of $175 million mean for cloud-native?

Hashicorp has raised $175 Million US in funding to aid them in their stage of growth. HashiCorp’s Series E positions them to take advantage of their multi-cloud messaging. The money will go to improving their field, support and customer success organizations worldwide. According to Johnathon Curtis, VP at Franklin Templeton the leaders in the conglomerate providing the investment capital, who stated that

As organizations shift to a multi-cloud operating model, HashiCorp is well-positioned to partner with and enable enterprises to realize the full benefits of their multi-cloud strategy, This is why we believe HashiCorp has the opportunity to become a foundational infrastructure company, defining and enabling the needs of the largest enterprises as they adopt cloud.

Alan Tu – Portfolio manager T Row Price solidifies that position:

HashiCorp has distinguished itself as a leader in cloud infrastructure automation and is well-positioned as enterprises modernize their traditional IT environments to be cloud-native. We are impressed by the team and the traction of HashiCorp’s products that help customers provision, secure, connect and run applications across their multi-cloud infrastructure in a consistent and automated way. We are excited about the opportunity ahead for the company.

Hashicorp as a company provides many of the tools that enable a joined-together Infrastructure-as-Code deployment strategy.

Infrastructure is Changing

Hashicorp Change

Infrastructure is changing, Cloud (be that Public, Hybrid or Private) is now the first place new infrastructure is placed. But different clouds have different strengths and weaknesses. AWS, long the leader in cloud technology, now has real competition in Azure, GCP and to a lesser extent IBM and Oracle. The ability to build infrastructure with a common tool across multiple cloud vendors and the ability to integrate that into your on-site infrastructure is critical in building out new distributed platforms to optimally use the strengths of different cloud providers. The ability to deploy your Kubernetes clusters seamlessly across multiple vendors and locations will increase your availability.

One of the major tenants for data availability the 3-2-1 rule, which states: keep at least three copies of your data. Store two backup copies on different storage media, with one of them located offsite. For the cloud, this means to use at least three availability zones, across at least two cloud technology providers. This protects against lockout from your data if your provider has a catastrophic failure.

Also, data sovereignty is another concern. Many countries just do not have sufficient public cloud presence from a major vendor. The UK, for instance, has only one region (London) with three availability zones.

The Netherlands is on the same boat too, with no dedicated AWS regions in Amsterdam and a single Azure region. From a data sovereignty perspective, this means that AWS stores data from Dutch customers in Germany.

But what has that to do with Hashicorp receiving $175 Million and why should I care?

Hashicorp Jackpot

In short, Hashicorp’s Series E is a validation of the multi-cloud reality. Organizations use multiple cloud vendors, and need ways to manage that operational complexity.

Hashicorp has a very joined-up product set for providing as structured and stable CI/CD deployment method for your infrastructure as code environments. With a common lexicon and code format for multiple vendors. It is not perfect but let us take a quick look at deploying a virtual instance in AWS. We would use the AWS provider and at its base the following code.

resource "aws_instance" "web"
  ami           = "${data.aws_ami.ubuntu.id}"  
  instance_type = "t2.micro"   
  tags = {
    Name = "HelloWorld"

Note that we are defining a resource of the type AWS_RESOURCE and giving it the name of “WEB” to identify it. We then define the AMI Instance used as the template for the machine together with the t-shirt size, in this case, a t2.micro.

Now let us compare this to the Azure method of deploying a virtual machine via terraform

resource "azure_instance" "web"
  name                 = "terraform-test"
  hosted_service_name  = "${azure_hosted_service.terraform-service.name}"
  image                = "Ubuntu Server 14.04 LTS"
  size                 = "Basic_A1"
  storage_service_name = "yourstorage"
  location             = "West US"
  username             = "terraform"
  password             = "Pass!admin123"
  domain_name          = "contoso.com"
  domain_ou            = "OU=Servers,DC=contoso.com,DC=Contoso,DC=com"
  domain_username      = "Administrator"
  domain_password      = "Pa$$word123"
   endpoint {
    name         = "SSH"
    protocol     = "tcp"
    public_port  = 22
    private_port = 22

We have a common resource type coupled once again with a unique naming identifier. There appears to be a lot more in this stanza than in the AWS one this is due to the architectural differences between how AWS and Azure define their Virtual Machines, you can see the image file “image = “Ubuntu Server 14.04 LTS” and the size “size = Basic_A1”.

Finally, let us have a look at the VMware provider.

resource "vsphere_virtual_machine" "test2" {
  name             = "test2"
  resource_pool_id = "${data.vsphere_resource_pool.pool.id}"
  datastore_id     = "${data.vsphere_datastore.datastore.id}" 
  num_cpus   = 1
  memory     = 2048
  wait_for_guest_net_timeout = 0
  guest_id = "centos7_64Guest"
  nested_hv_enabled =true
  network_interface {
   network_id     = "${data.vsphere_network.mgmt_lan.id}"
   adapter_type   = "vmxnet3"

Again, slightly different but recognizable, so we have a common look and feel. And this is all you need to understand the architectural differences between the clouds. The logical layout of the terraform files is similar too. This is the benefit of the declarative nature of the HCL language; the beauty of Terraform and this is the vision that the VC’s have bought into.



It is a compelling argument on the success of a company. Hashicorp’s Series E helps them to stay private rather than taking an IPO. Terraform Enterprise is Hashicorp’s ESXi, it is their potential cash-cow. It is their self-hosted version of Terraform Cloud and offers functions like audit logging and SAML-based single sign-on capabilities.

If, and it is a big if, the industry does not fully embrace Multi-Cloud, a major benefit of Terraform will be lost. All of the big Cloud vendors provide their version of IaC (AWS with Cloud formation, Azure with Azure Resource Manager API and to a lesser extent VMware with vRealize Automation). These are however all vendor dependent. In the Multi-Cloud arena Terraform as an IaC enabler, only has one competitor and that is Pulumi who has very little market penetration compared to Terraform and a completely different approach to how IaC works in that you also need to understand other languages such as JavaScript or Ruby together with learning Pulumi methodology, further they have little integration with other enabler tools although to be fair this may be due to their immature position in the market as a recent arrival.

Dependent on the Battle of the Multi-Cloud, Hashicorp’s positioning to win the battle of multi-cloud management with Terraform is great. And this does not even take in to account the other arms in their battalion.


Receive our top stories directly in your inbox!

Sign up for our Newsletters