This is part of a series of posts I’m writing as I prepare to attend Cloud Field Day 6. There are a total of eight presenters planned for CFD6, and I am going to cover two vendors per post. My goal is to have a basic understanding of each vendor’s product portfolio with a focus on cloud related products. Some of these vendors I am already familiar with, and others are new to me. In this post I am going to take a look at Morpheus Data and HashiCorp.
Morpheus Data presented at my first Cloud Field Day, CFD3. That was actually my first Tech Field Day event, and Morpheus was the first presenter on the first day. I think I spent half the presentation trying to figure out the logistics of being a CFD delegate, and missed half of what they said.
If I remember correctly, Morpheus Data was trying to become an orchestrator of automators. The concept is that you already have a bunch of automation and cloud platforms, and you are unlikely to standardize on a single one. Morpheus is proposing that you use their platform to act as an orchestrator of all of these other platforms. At the time I felt that was a tall order, given the number of automation tools out there and the need for abstraction.
What I mean by abstraction is that an application that tries to provide an overlay for a bunch of other platforms has to make a fundamental decision. Do you abstract away the differences in the platforms to provide a consistent set of constructs, at the risk of losing the specialization of each platform? Or do you embrace the specialization of each platform, but attempt to build a unified interface for administrators?
I think the second approach makes the most sense, it means that you aren’t reducing the platforms down to the lowest common feature set, but it also requires more of your development team to integrate with each platform and keep those integrations fresh. Terraform has adopted this model for infrastructure automation, but they have enlisted the help of the vendors to write their own providers for the platform. They are able to do this because they have achieved critical mass with practitioners, so vendors are willing to devote development cycles to assist.
Based on my reading of the website, Morpheus has chosen to pivot a bit and talk about being a Cloud Management Platform. They are trying to appeal to DevOps (read Developers), IT Ops, and Business Analysts. They are focusing on on their 100% agnostic platform as a way to appeal to all persons within the stack. By being agnostic, they are claiming you can managed 20+ cloud providers and avoid lock-in. Aside from the lock-in with Morpheus, since if you lean hard into their product you are basically locked into it.
I am not a fan of the lock-in argument. Any decision that is made at the technology level implies some amount of lock-in. Wrote your application in Java? You’re “locked-in” to Java. Deployed your application with AWS Lambda? You’re “locked-in” to Lambda. Lock-in is really just a measure of how difficult it would be to move some portion of the application to a different platform. Locking into a technology allows you to exploit its unique features to the fullest - remember the abstraction argument I made before, the trade-off being that it makes it more difficult to replace that technology with a different one.
This is more of a philosophical debate than a comment on Morpheus’ approach, but I think its a valuable perspective as I go into their presentation at CFD6.
Which approach has Morpheus taken? And have vendors begun to devote resources to assist with development? Those are some of the questions I have in my brain. When I saw them present in spring of 2018 they were still evolving their approach, and I’m curious to see if they have pivoted the product in any way based on market feedback.
If there is one vendor on the list that I am intimately familiar with, it’s HashiCorp. I have been using HashiCorp products since 2013, starting with Vargrant and then moving into Packer, Terraform, and Vault. In fact, I have four courses on Pluralsight around HashiCorp products, two on Terraform and two on Vault. When it comes to core products, HashiCorp has four that they focus on for their product messaging: Terraform, Vault, Consul, and Nomad. These four products correspond to their vision on of building, secure, connect, and run.
Terraform is acloud agnostic infrastructure automation platform. It is meant to build and maintain the underlying infrastructure that supports an application. When HashiCorp is talking about build they are talking about building up infrastructure to support applications.
Vault is a secrets management platform. When you think about all the sensitive information that is needed to build infrastructure and deploy an application - things like access keys, API keys, database passwords, certificates, etc - that information needs to be stored securely somewhere. Vault provides a place to not only store those secrets, but also manage their lifecycle from creation to retirement.
Consul is a distributed key value store and service discovery platform. The key value store can be used as a storage backend for Vault, or leveraged by other products. It can also act as a service discovery and service mesh type of platform, providing secure by default communications between applications using mutual TLS. As you can tell by the connect title, HashiCorp is leaning heavily into the network and service discovery portions of Consul.
Nomad is a platform used to deploy and manage the lifecycle of an application. The format of the application can take many forms, but ultimately needs to be describe in a Nomad deployment file. Nomad is responsible for taking the described application, deploying it to a target environment, and then maintaining the application through updates and alterations.
HashiCorp has given no hint what their presentation is going to be about at CFD6. If I had to guess, I think they are going to focus on their Nomad and Consul. Terraform and Vault and hugely popular and well known in the industry. But Consul and especially Nomad are less well known. In many respects, Consul and Nomad could be considered competitors to the Kubernetes ecosystem. HashiCorp has been trying to reposition both applications as complimentary or supplementary to Kubernetes. I think they are probably right, and Nomad in particular addresses applications that do not run entirely in Kubernetes. Nomad supports the Cloud Native Application Bundle (CNAB) format, which is meant for applications that are cloud-native, but not fully K8s.
Cloud Field Day 6 is happening September 25-27. There will be live-streamed presentations from both of these vendors. If you’d like to join in with the conversation just use the #CFD6 hashtag on Twitter. All of the delegates will be watching that tag and asking questions on your behalf!
October 18, 2024
What's New in the AzureRM Provider Version 4?
August 27, 2024
Debugging the AzureRM Provider with VSCode
August 20, 2024
State Encryption with OpenTofu
August 1, 2024
