Voices in Cloud – Episode 13: Conversation with John McLoughlin of CloudHealth

Guest

John McLoughlin is the Director of Product, Platform at CloudHealth Technologies. In this role, he is responsible for creating and executing the strategy necessary to evolve the CloudHealth platform. John's team drives forward the tenets of scalability, extensibility, and reliability by engineering frameworks to support the collection of all cloud data, developing algorithms to analyze that data, and providing features that let customers explore their cross-cloud, container, and datacenter information. Prior to CloudHealth, John spent 20 years in Engineering working in devops, architecture, and management roles for companies like Akamai, Turbine/Time-Warner, Fiksu, and various other startups.

Transcript

David Linthicum: Hey, guys, welcome to the GigaOm Voices in Cloud podcast. This is the one place where you'll hear from industry thought leaders providing no-nonsense advice on how to succeed with cloud computing, IoT edge computing, and cognitive computing. I'm Dave Linthicum, bestselling author, speaker, executive and B-list geek, and your host today on the Voices in Cloud podcast. Joining us today is a special guest with CloudHealth, John McLoughlin. How are you doing, John?

John McLoughlin: Good, how are you doing, David?

Give us the John McLoughlin story. I mean, you guys are near and dear to my heart because you're right around the corner [from where I] was working at Cloud Technology Partners. What do they call that, Four Point? What was the title of the neighborhood, Four Point?

Yeah, Four Point, the seaport. Four Point definitely is hot, up-and-coming right now.

Tell us what you do at CloudHealth.

My job over here is to be a director of product strategies. What I've been doing over the last few years here is driving towards how we migrate different workloads across lots of places, be it Amazon, Azure, GCP, the data center, and all the way up from serverless technology down to bare metal servers. How do we organize all that and make the world a better place?

Okay, tell me specifically. What’s a day like for John McLoughlin? What are you typically doing?

Yeah, so I wish I could say that my day was not rich with meetings, but it is. A lot of what I do is synthesizing all the different capabilities across CloudHealth and VMware into a strategy that represents a one to three-year horizon. The goal is to meet with customers and prospects, bring together information from architects and technology leaders, third parties who we might integrate with, and then obviously the capabilities of the VMware portfolio into a story that works for how we want to go forward in the next few years.

Moving into the topics that we're looking to talk about today, one would be multi-cloud. I just did a couple of articles on multi-cloud computing and the growth in multi-cloud. Of course, there's RightScale, State of the Cloud Report. There's a bunch of analyst reports out there and [in] some of the reports that we've done at GigaOm around the growth of multi-cloud, and wherever you look, it seems to be the fact that the new normal is going to be plural, public clouds. Sometimes private clouds are there and sometimes it's private cloud analog such as mainframe systems.

We're getting into some pretty complex waters as we're building these multi-cloud-based systems. I'm doing it a lot right now, probably have a couple of projects going at the moment, all multi-cloud, typically dealing multi public cloud brands and sometimes private clouds and mainframe computers and things like that.

Is there any end in sight, or is this something that's going to be the ‘new normal’ in terms of how cloud computing is morphing?

Yeah, I think what we're seeing, based on just polling our customer base, is that it is the new normal, that there [are] reasons, be [they] technical or logistical or otherwise, for companies to utilize different technologies from different places. It's a lot like what we saw early on in the data center days where you picked up a different piece of open source software, a piece of proprietary software, and you started having the same thing but in different packages. Then they got more specialized into what they do. I think what we see in the public cloud and in the private cloud is something very similar where if you want Kubernetes solution or if you want a certain type of NoSQL database, you'll want to go to different places to get that capability the way that you want it, and so we see it more and more, basically.

What's the motivation? Is it monetary? Is it keeping options open? Is it best-of-breed technology? The trade-off is going to be complexity. We're dealing with very complex environments. We have multiple storage solutions, multiple compute solutions, multiple governance solutions, multiple security solutions, things like that. Why are we making this move?

Yeah, I think what I saw or what we've been seeing happen has been – even with a single cloud, you're starting to see some of that complexity grow. The answer (in order) I would give would be: best-of-breed technology, taking the tools that your developers want to work on that have the scale and performance that you need for a workload type. Secondarily, monetary influence is not nothing. A lot of especially enterprise customers have agreements, existing agreements with vendors who they can use to leverage better pricing for sure.

I think those two things are both factors, but I think one of the key factors, though, has been the rise of niche-ness of the clouds and what they operate on. If Amazon is an 800-pound gorilla for a lot of things, that's fine but Azure and Google have special offerings that are cutting edge and people want to take advantage of things like TensorFlow or Cosmos DB and some of these other technologies. I see it as a one-two punch, but because the rising complexity of running any public cloud was already hitting the threshold of when you needed smart software to make your decisions, the cognitive hit to go to more clouds as long as software is there to support you just gives you an advantage.

Another thing I'm noticing with the rise of the multi-cloud is also the rise of complexity and the goodness and lots of the badness that comes along with that. What are you guys doing to provide solutions in dealing with complexity at CloudHealth?

Yeah, I think it starts at the base level of proper classification. When you look at an environment in a cloud context, you're just not breaking it up in the ways that teams have to operate on an application. They're just thinking about it from [a standpoint of] “Well, this is just one pool of servers that's a service I offer as a cloud.” We break it up into “Well, this is application 1 that represents the efforts of these five developers, and this is application 2, etc... When you change the context in your mind of ‘it should be about me and my application,’ a lot of things change in how you operate on the data that you're given.

What we do is some basic things. The idea is identifying waste, be that technology waste or cruft from governance. If you're leaving things around that aren't useful anymore, be [they] financial or not – if you have security groups that aren't doing anything, then you have to scroll through those those things to figure it out. Then also looking at things like security, what's the posture of a production application versus a developer's environment? How do you maintain that standard and go forward with that standard?

Then obviously, the fiscal things, things that do cost money, they come in all different shapes and forms in the public cloud world especially, so you need to have something that knows and understands and how to recommend for you exactly what you need to know to be both, between scale and efficiency, [at] that sweet spot that equals value.

What have you seen around public cloud adoption this year? Let's just time box it between January and now. What have you guys seen occurring? What are some of the new patterns? What are some of the existing patterns? What's happening out there in the world?

Yeah, so we've seen an acceleration into multi-cloud, especially among individual public cloud users. That has been surprising that that adoption, that migration strategy, has taken root and is moving very quickly. I think in the market, what we're seeing is that enterprises, even private cloud enterprises, are saying “I need some burst capacity in my environment.” In the public cloud, they're saying “Look, I want to be able to perform continuity, be able to move my workloads well across things.” I think the first trend we're seeing is people who are classically a single public cloud player picking up a second cloud.

Now, what we haven't seen a lot of is somebody picking up all the public clouds. Generally what we're seeing as the trend, this year at least, is going from a single public cloud or a single private cloud to either a multi public cloud or a private-plus public cloud orientation.

What's a private-plus-public cloud?

When you look at something like that, you think of: be it a vSpheres, View Cloud foundations, an open stack, an Azure stack, open shift, whatever, a pivotal cloud foundry. These have been classically things that you saw on a bare metal hardware in someone's data center that they own. Then a lot of people are saying “I want to buddy up with Amazon,” or “I want to buddy up with Azure or Google to say I want to run my dev workloads there versus my production workloads because I can be more adaptive to the needs of my developer,” or “I just am worried about how spike-y the load is against this application. I want to be able to bridge between two locations to give myself the capacity to grow, sort of what I've seen.

Say I'm a Global 2000 CIO and I called you in for a consultation and the question's fairly simple. I'm leveraging a single cloud, public cloud platform today with some scarcity of private clouds and legacy systems that are connected to it. I'm going to move to a public cloud, add some – two more cloud brand names, again probably for the best-of-breed stuff, the niche-based technology stuff. Some do data better; some do machine learning better, things like that. What should I be doing now to prepare for that journey?

Yeah, that's a great question. The biggest thing I think is setting guardrails for uniformity across whatever your workloads are running against. What we end up seeing is that be you a serverless workload or a Kubernetes-based workload or an IaaS or PaaS-based workload, there's certain functions that should be true at all points in the life cycle of those applications. Those broad pillars are around visibility, being able to aggregate and sort, and organize by groups, being able to govern well, which is being able to give recommendations and opinions to the lines of business that are operating in those environments to say “This is what good security looks like, this is what good tagging hygiene looks like; this is what good budget management could be looking like,” and then ultimately trying to lower the bar so that people don't have to think about these things, that once you have those guardrails set and people from the outset are used to feeling some pressure to be efficient and to be well-governed, that then the business will capitulate into “I will take on the automation of those things; I will allow you to remove snapshots that I haven't looked at in 90 days or a year” or whatever it might be.

I think that is the first thing I would recommend to a CIO is that you need to make sure that you have the right best practices in place so that you get the right recommendations and then secondarily, that they're broadly applied at provisioning time so you're not trying to back-fill it into a legacy where things have already gone sideways.

Where's this going [in] 2020, 2021? Obviously the multi-cloud stuff's going to continue, at least based on my research. We're going to need lots of tools to deal with abstraction automation in terms of how we're dealing with that. Any surprises next year [or] the year after that, in terms of multi-cloud evolution? Is it going to speed up, slow down? We're going to reach a saturation point? We just have too much complexity; we have to stop and simplify things and deal with abstraction automation to push everything behind a magical single pane of glass so we can operate this thing in a reasonable amount of time. I mean, where are we going with this stuff?

Yeah, I see a high/low strategy forming, which is on the low side, people want to use best-of-breed point tools. They really want their sec ops people and their biz ops people and whoever is in the environment to be able to really look at what's important to them. On the high side, I think what the future will hold over the next few years is that there'll need to be a broad integration strategy at a fundamental level to bring those insights up to the level where you can easily action them. When you need to communicate across personas, when the security operator realizes that the image the intra ops person has put out has a security vulnerability, you need a substrate to be able to send those messages and receive confirmation that they've been acknowledged and that they've been resolved.

I think that high opportunity is bringing the platforms together through integration where you don't displace anything but rather additively, you take those use cases and then share them across the different people who care about them. I think in the next two to three years, that's probably the horizon. I think two or three years after that, what you'll end up seeing is more of the full automation, the consolidation, maturity in the tooling so that it's less noisy in the system. I think first, you have to start collaborating, and then you can do the automation piece.

Okay, and so how do I collaborate?

Yeah, so there's a lot of different ways that people want to, because when you look at a developer and what they're operating in, they use an IDE. They care about GitHub and GitLab and build dependencies and things like that. You look at a dev ops person, you see operating on the command line and infrastructure code and doing work there. As you move up through sec ops and other things and non-technical personas using Excel or whatever it is, Tableau and Looker and Domo, all those types of technologies, you need something that brings that story together to collaborate.

Basic concepts of being able to share and annotate graph-based views, tabular-based views is the first step, but then also sharing in the state of the system, the history of the system, the change controls, how we test for what's a healthy system and gating the releases on things that represent health. I think the collaboration on those pieces is going to get richer as in: we will see more constituent personas coming together to say this is a build worthy of going out rather than on a wing and a prayer. “Hey, I shipped it; now let's go see if it works right or not.” To do that, there's a broad variety of tooling that you need in place to do it. Many places, it exists in spots, but I think what you'll see is a more holistic approach to how these different people interact with the environment.

How is CloudHealth going to participate in this evolution of the multi-cloud world?

We've always been aligned to business outcomes and business intents. The goal has always been to integrate broadly whatever's popular in the market. Let's play with those players because that's what customers want to be using. Perform analytics on what we're seeing so that the view, the visibility that you have in your environment is in your context with the proper recommendations, and then finally the ability to automate out actions that are, frankly, tedious.

Those complexities, again, for all these different services that you are fighting against, you want to be able to right size; you want to be able to optimize; you want to be able to govern and be in compliance correctly. The goal would be to be able to push back to those tools, be it in the public clouds or third-party tools, so that you can take those actions smoothly with the proper visibility for everybody who cares and then removing the friction of “Well, I have to log into the fourth portal to make that change to the load balancer.” Make it so that you can seamlessly drive forward change in your platform with the right controls.

What does a typical CloudHealth client/customer look like?

That's a great question. There's the SMB-style customers we have oodles of, and then obviously at the enterprise level, we have around a thousand customers of that size. What they do in the platform today is bring together the story that we were just describing. It's a nascent story for a lot of enterprises because they've grown up, matured in their own environment, be that mainframe market or the data center market, and what they're seeing is the value of the cloud driving efficiencies and driving capabilities for their lines of business. They use CloudHealth to first turn on the lights, understand where's all that usage flowing, how to set policies against it, really understand what the view of that system looks like and how to operate it, and then as they get comfortable with understanding what the view of in their context, they want to push control down to those teams.

A lot of the largest companies in the world will say, “I don't want to central IT office trying to manage every movement of every workload.” It doesn't scale, so they'll use CloudHealth to give permissions to organizations so that an organization can go in and fiddle with the data and understand what the recommendations are and correct to their environment for themselves, so that they can get to a position where some of the noise of the system is just eradicated. They know that they see that value because there's cost reduction. You're hiring [fewer] developers or operators. It shows up in the platform because you're able to configure and manage those use cases with relative ease as compared to clicking, and running command lines, and writing scripts, and figuring out how to do it yourself.

Where can we learn more about your technology on the web?

CloudHealthtech.com has a rich background in the classic solutions and products of view. What I highly recommend is just sign up for a trial. If you're interested, sign up for a trial. We do a couple weeks like everybody else, give you an opportunity to kick the tires on the platform, go into our knowledge base, go into our academy, read the videos, get the training if you want. Then we'll also work with you to set up those classifications, set up that capability so that you can see your environment as you see it mentally. I think that's the best way to do it. Finally then obviously, there's whitepapers, things you can download. Then you can contact the team to ask a question. You can send a note in off of our website. We will contact you; we'll talk to you about it.

Awesome. Guys, check it out. Let's leave it there. Anyway, please pick up a copy of my book, Cloud Computing and SOA Convergence available on Amazon and other places books are sold. Also make sure to follow me on Twitter @DavidLinthicum, L-I-N-T-H-I-C-U-M, as well as LinkedIn where I have several cloud computing courses on LinkedIn Learnings. John, where can we find you on the web?

Well, I'm @JTM on Twitter because I got in early, so that's always a good place you can tweet at me. Otherwise, I bounce around through the CloudHealth website. You can reach me at JimMcLoughlin@vmware.com, too.

Good deal. Reach out to James if you want more information on CloudHealth and what these guys do. They obviously picked a good place to have their office space, so that's my key metric, but they have good technology as well.

So, until next time, best of luck in building your cloud computing solutions. We'll talk at you very soon. Cheers; bye.