This week we hosted our latest CIO Insight Call, around the transition to the multi-cloud enterprise stack, which, as a firm, we feel is a generational transition for IT. We were joined by Dave McJannet & Armon Dadgar, CEO & Co-Founder/CTO of HashiCorp, one of our most successful breakout portfolio companies in the space.
Right now, companies are in the process of shifting from largely dedicated servers in a private datacenter to a pool of compute capacity available on demand. The enterprise stack has been evolving from a static, dedicated hardware model to a dynamic cloud-first model for some time, but this transition directly impacts how applications are built and managed, how the network operates, how security and zero-trust goals are met, and the skills needed to support this new cloud operating model.
We invested in HashiCorp back in 2014, when they were designing a platform to help solve the enterprise IT journey. Fast forward to today, and they’ve been able to unlock a cloud operating model for thousands of enterprises around the globe. We believe the enterprise IT stack is underway in a tectonic shift that will remake the data center profoundly, impacting IT teams and the businesses they support. Please see below for a recording of the call, with time stamps and key takeaways.
[8:38] Moving from data centers to the cloud is a generational transition, the same way we moved from mainframes to large data centers thirty years ago. But the compute primitives of cloud are not the same as in the on-prem world
[12:32] Every time you go through a generational transition, you get a dislocation of vendors, and there’s a reconciliation people are doing as they step back right now. The future won’t be 30 vendors, it will be a much smaller number (a multi-cloud stack has emerged)
[15.06] Companies are going through “the stages of cloud grief:”
First: We’re not leaving the data center
Second: We’ll have a hybrid model with on-prem and a single cloud vendor solution
Third: Acknowledgement that there is a multi-cloud reality
[16.26] No one chooses multi-cloud, multi-cloud chooses you. This is driven by things like M&A (you’re all in on Azure, and you buy an AWS company), or you’re in a regulated industry and you need government cloud support, or you’re selling to Walmart and they insist your infrastructure is somewhere else, etc. If you’re a large enough business, at least some of these factors will apply to you
[18:02] Cloud is a process transformation, as much as it’s a tech transition. You don’t want to just add another step at the end and call it “cloud” – that is not success, you just added two more weeks on a three month delivery. When you zoom out it’s about a self-serve orientation, the dev team should own their destiny because what you really want is the agility of those dev teams. When you look at the traditional approach, your dev team or your ops team files a ticket, and you have to start to replace those points of coordination with systems of coordination, where you have a system intermediating between these different teams instead
[21.26] If you’re multi-cloud, how can you consolidate and have a consistent process and have the pipeline fundamentally support the notion of self-service? Break it down to four layers:
- The Provisioning Layer – This is the shift towards an ops focus: how do we manage the lifecycle of infrastructure from cradle to grave? (Low level hardware, IaaS, PaaS, SaaS)
- The Security Layer – Historically it was just the security teams thinking about this, increasingly it’s an ops concern as well. If you’re bringing up the environment in an automated way and deploying apps in an automated way, you don’t want to bring it up in an insecure way and then throw it over the wall, you want the security controls embedded in the automation – so environments are automatically hardened with the controls in place, which reduces or eliminates friction (low level infrastructure access, middleware, high-level data protection)
- The Connectivity Layer – How is networking modernizing? You’re no longer racking and stacking Cisco gear, so instead the networking is kind of part and parcel to how the application automation takes place
- The Runtime Layer – At the highest level is the runtime itself: how do apps get deployed? Ops is sort of the common thread through all of this. Kubernetes could be the platform, but HashiCorp’s version is Nomad
[28.41] The Cloud Operating Model – This is the idea that if you know you’re going to be spanning these multiple clouds, on-prem, AWS, Azure, etc. – what are you doing so that you have a consistent delivery pipeline of workflows to different clouds? What are the essential core pieces? How are you doing dev, test, lifecycle management, security, policy, networking, etc. HashiCorp is focused on the middle layers, but you still need a consistent pre-production and observability tool chain as well
[30.19] How can you balance transformation with the existing business? First, think about the IT org like a tree – you have a shared trunk, branches of common capability, and your applications sort of grow on it. Like a tree, IT orgs have evolved organically over the last 30-40 years, and over time you’re looking at this big beautiful redwood tree. Part of the challenge as companies shift to cloud and devOps is that you’re staring at a redwood tree and willing it to become a sequoia, when what you really need to be doing is planting a new tree and creating a line in the sand – this is where net new goes, this is where everything we’re modernizing goes. Then you can cap and shrink over time
[39.30] Start with the low-hanging fruit – Instead of starting with the most complicated system and moving it to cloud, figure out where the business value is (maybe it’s a net-new mobile app or API layer) and move those pieces instead, because they don’t have their own dependencies, and those areas have business value. They can still talk on-prem to the existing mainframe or SAP system, but having these successful migrations where you build velocity and success is important, Then, start to peel the onion outside-in, and the dependencies. Don’t fall into the trap of migrating a core SAP system first, and then 36 months later having nothing to show for it
[43.30] Cloud is a useful catalyst to re-think processes and technology because it’s greenfield, but there’s nothing fundamentally different about the data center that prevents you from bringing a lot of these technologies on-prem. You can re-orient many processes to work similar to a cloud environment (e.g. have Terraform talk to VMware and auto-provision a VM environment on-prem, so you still get that cloud-like self service). JPM and Adobe are great examples of this. Architect your 2.0 to assume you’re doing multi-cloud and on-prem in the future – pick the right set of tools
[47.13] How does HashiCorp play in a pure cloud-native world? Diversity across everything – consistent ways of driving developer workflow. They focus on the infrastructure/app lifecycle, and less data orchestration – but they play nice and integrate with all the folks on the data side of things. The tools still bring an elevated user experience, but also focus on how you can do some of this stuff at mega-scale: 50,000 nodes with console, etc.
[50.24] How does Vault support security rules and firewalls?
[53.03] Where should you do asset tagging for cost management and asset tracking across the stack?
[54.21] How do you respond to the question of “why so many different products”? Do you feel like all the choice makes it harder for tech leaders to assemble this versus the suite/fully integrated approach? You only make the problem worse by adding new tools. There’s a truth to this – what you need is less complexity not more. The reality for a lot of orgs is that they are siloed and they adopt these technologies independently and incrementally. There are always independent buying and decision centers that are all working on different problems. Having different products allows for focused, separate conversations and an incremental adoption path. However, companies are shifting from a self-managed model to a cloud-managed, cloud-delivered model. Through that they can start to become a little more opinionated and pre-integrated. If a company just trusts HashiCorp, and just wants to buy HashiCorp’s opinionated and integrated version of all their pieces, then that adoption path can make sense too
[58:07] Are you able to leverage your platform/cloud neutrality to provide aggregated spend management and dynamic workload migration based on performance and expense characteristics?
For further reading, HashiCorp has released an awesome state of the cloud survey which we highly recommend.