Uncover the 5-Steps to Multi-Cloud and Hybrid IT Mastery
Transcript
>> All right, hey everybody, it's Brad Parks with Morpheus Data. I wanted to thank Keith and the CTO Advisor team for puttin' on this virtual conference. Welcome to our session. We've titled it "5 Steps to Multi-Cloud Mastery", so what I'd like to do is run ya through a little bit of the lessons learned that Morpheus' has seen over the last four or five years. We've helped large enterprises as well as service providers automate their multi-cloud infrastructure. We've got about 400000 total application work loads under management right now, so we've learned a thing or two.
So I thought I'd share a little bit of what we've learned along the way and hopefully help you as you're trying to get your hands around multi-cloud, hybrid-cloud and everything that that means. So, first I think we've all kind of seen the shift away from pure cost-based IT decision making, and today, if you're a large enterprise, you've noticed that the barriers to entry into new markets has really gone down. Largely because public cloud has made infrastructure provisioning so fast. As a result, traditional enterprises have really focused on overcoming some of that with investing in speed and agility.
However, a few things that have come up as barriers to that investment plan, this is from some recent Gartner research with their CIO Forum, but pickier analysts of choice, I'm sure Keith would agree, these are things that we see from customers all the time. Now one of the first big gaps is just technical debt. As a established enterprise, you don't have the luxury of everything being a green field deployment like some newly funded startup that's just going to go straight up into the public cloud.
So how do you deal with all of those legacy processes? The people, the tools, the technology, all of that tends to weigh down this goal of agility. Second, there's a massive skills gap if you look at what it took for an IT center five, 10 years ago, to manage a highly virtualized environment. That's very different when you're wrestling with both the migration from VM based applications to containers and past services, as well as dealing with some of the skills that are required to manage on premises infrastructure, as well as the public cloud.
Third, and I think this is really a reflection of those first two, is just this insufficient capacity to absorb change. People are at a breaking point and that's really been driven home even more over the last handful of weeks as we've all been trapped at home. We've seen a massive increase in the interest around automation and around self-service because people are just having to do more with less physical touch on every infrastructure component. So, what does that look like from a customer perspective?
This is a visual I actually stole from one of our big enterprise accounts. They had this printed up on a large format print out, on the side of a war room and underneath it they had the 300 steps that it took from the time an application team provisioned a stack, or when they requested that stack, to when it was actually available to them in a production ready state. Right? It's not just as simple as adding a new node to your hyper conversion infrastructure, or clone it in Veeam.
If you look at it from an application centric view, this process can take weeks. You've got development teams on one hand, trying to get to deployments-per-day, yet when they get to production release cycles we're still seeing three week lead times often times because of all of the manual touch that happens across these different infrastructure components. So, service gets requested. It has to go to a maybe a platform team, who configures the base-level infrastructure, the Veeam stack. It has to go then to a OS team maybe that ties it into config manage.
You end up having to also put requests out to the networking team to get an IP. Configure a DNS, join this application into the domain, and then maybe an operational team that's configuring the logging, the monitoring, the backup. All of that is what is taking too much time for modern enterprises and its honestly this is a lot of what the public cloud hides, and why its taken off so much over the last five, 10 years. So what are some of the problems that we see coming out of that for the enterprises that we're dealing with?
Number one is just cutting costs is a problem, and when I think about costs, its not just a public cloud cost, its also the cost or the inefficient utilization of on-premises infrastructure. Second, security is still top of mind. So, how do you wrap governance around such a massive hybrid landscape? Third, talked about it just a second ago, provisioning time just takes too long. And then lastly, you have teams that not only need access to provision infrastructure, they also need access to all those operational tools to the scaling, the logging, the monitoring, and IT is hesitant to just turn over the keys to all of those operational tools to a set of developers without the right governance in place.
So when we look at the customers that we're dealing with, we see them land in a few different buckets depending on their maturity on this curve. And often times they're in all three of these phases at any one time depending on the application library, or the team that we may be working with. For a lot of folks who are earlier in this journey, they're very focused on re-hosting sets of applications. Sometimes code left in shift. For the most part, people have realized this is not an ideal mechanism, but they are still trying to deal with costs.
And as part of that plug some of the government holes to address shadow IT. Second, large class of customers that we're talking to are trying to standardize how they're interfacing with clouds. So getting a consistent self-service experience on premises as well as standardizing across multiple public clouds, and then third, there are an awful lot of advanced development groups who really have embraced continuous delivery, are picking up things like infrastructure as code, and trying to kind of bridge that gap between DEV and OPS.
From a tooling perspective, tools and technology are only part of the answer. A lot of this does come down to people and process, but when you look at the tools, I think one of the challenges for a lot of the enterprises that we deal with today is just the massive breadth of ways you can attack this problem. Its not easy. I wouldn't want to insinuate it is. You've got technology providers that are going to attack this from the OPS side of the house, who may generally focus on cost optimization as an example.
You've got others who are going to address this from a very platform or infrastructure centric view. How do you make VMware hum with things like you realize? How do you make Nutanix hum with things like calm? You've got development teams who are embracing technologies like CloudFormation or Terraform. Again, very great tool for a very narrow slice of this equation. On and on and on what we see is when you look at this in aggregate across an enterprise, all of these tools and technologies have their place, however there is a need to abstract this complexity and try and simplify so that you can scale your hybrid-cloud, your multi-cloud automation initiatives.
So when we're talking to customers we are looking at how can you unify this? How can you bring DEV and OPS a little bit closer together, and there are sets of abstractions you can put in place to make this journey a little bit simpler. Its never going to be easy, it is a lot to bite off, but by attacking it in aggregate, and thinking about this journey from start to finish you might save yourself some pain down the road. As some examples, we've had customers who've been struggling with self-service and may have spent a year or two trying to deploy a self-service cloud, but when they take a step back and re-tool, they're able to not do it from a narrow infrastructure focus view, but do it in a way that gives them the delivery speed they need while also addressing some of these adjacent domains.
So now maybe I'd like to pivot and tell you a little bit about Morpheus. You may or may not of heard of us. We haven't been out in the market for a handful of years. We've had some good success. Leaders in the magic quadrant for the last two years, so hopefully this isn't brand new to you, but why do we have a unique perspective on this market? Part of that has to do with our design center. Where did we get our start?
Unlike a lot of tools that may have stemmed from a hypervisor technology stack or a public cloud stack, our tool set was really born not to be a publicly consumable software tool. It was actually developed by a pool of DEV OPS engineers who lived within a one and a half billion dollar private equity company. Their job, within this PE portfolio, was to go into companies that the portfolio was acquiring, inject technology into them to help them transform very quickly and ultimately increase the valuation of those companies.
So, nine years ago when Bertram Capital sput up this Bertram Labs group, they looked at what tools were available and they just didn't find the combination of tool sets that they needed. So over the course of about five years, tens of thousands of application deployments, they built a set of intellectual property to come into very complex brown field environments and assess what was going on, set up governance across multiple tenants and teams, deploy application stacks very very quickly, and then run them with an incredibly lean operating team.
So if you fast forward from that original genesis, about four years ago Morpheus sprang out of that collection of intellectual property. We packaged it up and we've been going to market quite successfully over the last couple of years helping large enterprises address that same set of challenges. When we think about what customers are trying to do to unify that landscape I touched on earlier, the core of the problem to me really starts with self-service. How do you get different constituency's access to what they need without getting in each others way?
And there are really three key consumers we see around hybrid IT and multi-cloud. First is the traditional OPS function, what now is being referred to as CloudOps for a lot of companies. This is the group that is trying to turn that on-premises into a public cloud style of provisioning experience for their consumers. But at the same time, they're also the team that has inherited public cloud accounts, so they're trying to control that mess. Second is the development communities, so DevOps teams that just want to provision their application tiers very very quickly without having to wait and without being told what tools they can use.
And then third is the business itself. How does the business derive value from hybrid IT? How do they maintain compliance? How do they maintain cost control? If you can't hit on all three of these as an IT team, you're ultimately going to fall short of expectations for your business. So step one when you're thinking about multi-cloud is designing for self-service and designing for those multiple personas. When we talk to customers about the Morpheus stack, we hit kind of four other key points, but these are points that you're going to have to address whether you're looking at Morpheus or not.
So probably worth highlighting. So once you establish that self-service design center, the next key piece is to think about how do you get your house in order. You've got to very quickly attach to brown field environments in just the instances, the work loads that are there, and address the cost concern, cause it is still a concern even though its not a primary market today. Its becoming more of an attribute of a full stack conversation. So, first, quickly integrate and optimize what you already have with the goal of moving to governance.
So, establishing very fine grain approaches to role-based access. Its not enough to just have two or three roles. You may have five or six different teams with different sets of policies. Life-cycle management in place to address different needs in a holistic way. These first couple really do tackle the OPS side of the equation, so getting your house in order, establishing governance so it doesn't become a problem again but where we see a need for tooling to really modernize is to treat both DEV and OPS as first class citizens.
So, next step for us is addressing the need for continuous delivery and automation in a DEV centric way. So letting teams bring their own tools, but unifying those as part of continuous delivery processes that are standardized across bare metal apps, virtualized apps, containers, as well as public live services. And then lastly, the reason you're designing and deploying these applications in the first place is to put them into production. So how do you manage day two operations in a similar self-service way? So this is how we think about multi-cloud, about hybrid-cloud, is doing it in a systematic way.
It's what we bring to the table, and digging into the Morpheus framework a little bit further we've actually built out a native set of services for just about every phase of this continuous automation life cycle. So from how do you trigger an application provisioning event to BV a GUI, could be API/CLI, could be coming in from an ITSM tool like a service now on the way around this circle. So what's a little bit unique about Morpheus is we've actually built a native service for every stage of this life cycle.
We're not just aggregating a bunch of API's, so for example, we had our own blueprinting infrastructure as code DLS. We have our own state management engine. We have our own archive service, our own IPAM, our own monitoring, logging and backup, and that's not to say we're trying to replace every tool that you've already purchased and acquired, but the reason we did that is it has given us a very unique appreciation for how to integrate with these very complex sets of tools that most of our enterprise customers already have.
So Morpheus is actually built out over 80 native integrations into most of the tooling that is required to stand up a new application. So it helps us bring those together into a self-service framework. So when you're needing to provision an application you're able to very quickly tie all these tools together so that you can go from service request to service delivery in just a matter of minutes. One of the best examples I like sharing here is AstraZeneca, one of our larger enterprise accounts.
Before we started working with them a couple of years ago, it was taking them between 50 and 80 hours. That was their service level as a platform team to deploy new applications. After Morpheus was put in place, we've got that down to just a matter of minutes and now they're spinning up and tearing down infrastructure stacks on demand, and so they're able to really transform how they think about application updates, application modernization. So this continuous automation life-cycle is how companies are deploying end-to-end application stacks.
The other dimension is where are those stacks living, and most of you probably appreciate there's no such thing as green field for any enterprise of established size. You've got a collection of on-premises infrastructure, so could be your bare metal servers, could be your VMware stacks, you might be running hyper converged. You're obviously thinking about containers so how do you tackle Kubernetes? There's a mountain of on-premises infrastructure you have to tie together, but you also have teams taking advantage of public cloud services.
And that goes beyond just compute, or EC2. They might be using some of the AI services, some of the other public-like databases. So where are those applications are living and how they're architected is the other dimension that they have to tackle if you're thinking about multi-cloud and hybrid-cloud. So, why did we find success with some of our enterprises? One of the first things that is key is around time to value. So the landscape is changing so fast. You have to be able to unify those tools and get productive very quickly.
Its about minimally viable cloud and then iterating in this agile world that we're living in today. So with Morpheus, because we have all those native integrations, we're actually able to get customers up and running in less than an hour and that's from hitting install on our package. Its just a linux distribution, very quickly installs. You can connect to those third party providers and have a full functioning private cloud literally in about an hour. Not to say you're going to do a mobile roll out, with all your teams, but you know, time to value are very very fast.
Second dimension is around abstracting the underlying cloud platform. So for enterprises that are thinking about VMware, about Kubernetes, about AWS, about Azure, about Google, that don't want to get locked in to any one point of view. By designing automation to an abstraction such as Morpheus, you're able to very quickly change directions or change tooling down the road without the brittle nature of some of the more manual based automation architectures. We talk to companies all the time who might be using a combination of Ansible, of Terraform, of vSphere, and while you can write your own automation framework, what we ultimately find is that becomes very brittle and hard to maintain over time versus housing that automation framework in a platform such as Morpheus.
So this is a solution. Its a solution space that does show much better than it tells. I want to be sensitive to everybody's time. We don't have time to do a full demo today, but what I would actually invite you to is if you can reach out to us, we'd love to jump on with you. Find out where you are in that life-cycle journey, do a demo, get you a new POC. We can also invite you into our community edition of the software.
You can actually download it, get it up and running very very quickly. We'd love to engage with you so give us a shout. We'd love to help you. Here's the URL. com. You can also go to slash demo and just do a demo request. We'll get ya connected to one of our solution architect teams out in the field. With that, thank you very much. Stay safe and have a great day! (intense music)
