Modern Software Podcast logoIf you still think multi-cloud is all about deliberately choosing several cloud providers to avoid vendor lock-in, you may be missing the point.

That’s just one key takeaway from the latest episode of the New Relic Modern Software Podcast, which delves into the complex world of running—and monitoring—applications in multi-cloud environments.

As you may know, earlier this month New Relic introduced new multi-cloud monitoring support with integrations for Amazon Web Services, Microsoft Azure, and Google Cloud Platform. With those new capabilities in mind, we wanted to explore the realities of how and why multi-cloud is being implemented, and share some insight on monitoring infrastructure and applications in a multi-cloud world. So my co-host, New Relic Developer Evangelist Tori Wieldt, and I invited New Relic’s Senior Director of Strategic Architecture Lee Atchison and Senior Manager of Product Marketing Aaron Newcomb to share the perspective they’ve gained from working with New Relic customers.

You can listen to the episode below, get all the episodes by subscribing to the New Relic Modern Software Podcast, or read on below for a transcript of our conversation, edited for clarity:

New Relic was the host of the attached forum presented in the embedded podcast. However, the content and views expressed are those of the participants and do not necessarily reflect the views of New Relic. By hosting the podcast, New Relic does not necessarily adopt, guarantee, approve or endorse the information, views or products referenced therein.

Fredric Paul: “Multi-cloud” can mean a lot of different things. What are we talking about here? Are there different kinds of multi-cloud?

Lee Atchison: Yes, there are a couple different ways that people use multi-cloud. One of the easiest ways is that companies have different projects that use different cloud providers. They may have an acquisition of a company that has an application that runs on Azure and they may use AWS, or they might bring in something else with GCP. That’s multi-cloud but a very, very loosely coupled multi-cloud.

You also have some people who have parts of their application that require specific services from a particular cloud provider, so they might have most of their application on AWS, but some of their AI processing on Google. That’s a common outcome as well.

Rarely, but occasionally, you see someone who says, “I want to make sure my application works in any cloud so that I can move in case I have a problem with the provider.” That’s what people usually think of when they think of multi-cloud, but it’s the rarest example of multi-cloud.

Fredric: I think that does challenge the conventional wisdom. But given all that, Tori, how common are multi-cloud implementations?

Tori Wieldt: Actually, really common. Last year’s RightScale State of the Cloud Report says 85% of enterprises have a multi-cloud strategy [Note: the brand new 2018 State of the Cloud Report put the figure at 81%, noting a drop in hybrid cloud use.] Definitely, they’re doing it. Who knows if it’s really intentional?

multi-cloud conceptFredric: You did say the word “strategy” there.

Tori: Touché. But think about multi-cloud/hybrid cloud: 41% of the workloads are in a public cloud and 38% are in a private cloud. So in total this cloud thing is at 79% of the workload, but there is a mix and match of using a private cloud and then selecting from a variety of public cloud vendors.

Aaron Newcomb: That’s a good point, Tori. I would add that customers still obviously have on-premise workloads, too. So it’s a really varied landscape right now. People still have things they want to run on-premise, But maybe they’re moving toward the cloud so they’ve got a little bit in AWS. And then they’ve got some things in a .NET environment that they want to run on Azure. It’s really varied across the spectrum.

Fredric: Are there specific benefits for having a multi-cloud implementation, or specific challenges? Or is it just a fact of life?

Lee: I think it’s a little bit of both. It is a fact of life, but different cloud providers have certain benefits. If you have a very heavy .NET workload, nothing is going to beat Azure for running that. If you really want a solid, inexpensive but highly productive workload, AWS is great for that. If you have a lot of AI processing or a lot of big data processing, there’s some advantages to Google. There are advantages of different cloud providers for different types of workloads.

Fredric: What about the flip side? What are the difficulties in running a multi-cloud environment?

Lee: You certainly have contractual advantages and disadvantages of having multiple vendors. But each company has different interfaces, a different style of connecting. If you have the same engineers dealing with multiple cloud providers, they have to keep track of how they interact with each one differently and there’s some complexity associated with that. There’s no standard way of talking to a cloud provider even among similar types of services, and that complexity can not only complicate the applications but also complicate the lives of the engineers who have to learn all of this.

Tori: There’s also the whole thing about lowest common denominator. If you’re thinking, “I’m going to flip this from one cloud to the other,” it can be problematic if you’re taking advantage of the specific services that each cloud provides. Some people say that those services make it better, other people call it vendor lock-in. Whatever way you want to look at it, if you’re taking advantage of that, then things aren’t as mobile as you might think they are in terms of making migrations.

Lee: Tori brings up an excellent point. There really is a big debate among companies today. There are companies that I’ve visited that say, “We can’t do vendor lock-in at all. So we have to make sure that our applications run across any cloud provider. Period.”

The problem with that is that means they can’t take advantage of most of the services that the cloud provides because most of the services are unique for each cloud provider.

There are other companies that say, “I don’t care about lock-in. AWS isn’t going anywhere. They’ve got good pricing already, and I’m not trying to pick one vendor off against the other. I want to use as much of AWS as I possibly can … or Azure or Google.”

That mindset is probably the most prevalent but it is a dichotomy. Different companies have a different view on this.

Fredric: So given those complexities in multi-cloud strategies, what are the implications for monitoring in a multi-cloud environment?

Aaron: Anytime you have a complex set of variables to monitor, you’re going to have a problem consolidating those into a single view. It’s almost never possible to get to absolute truth. But imagine a company that has multi-cloud strategy. They’re monitoring Azure. They’re monitoring things in AWS. They’re trying to get a complete picture. The problem is that they have multiple dashboards up with information coming at them from multiple vendors. How do you consolidate that view into a single picture that says, “Oh, this is exactly how this is working.”

For example, I’ve got my web services running in AWS and I’ve got my backend .NET application running in Azure, but they’re telling me two different things. I ran into this all the time as an end-user where my application group would come over and say my storage group isn’t working, and the storage group would come over and say, “No, it’s the application’s fault.”

So how do you reconcile those two things in a single view that can actually help you resolve those issues more quickly? That’s where New Relic comes in to help solve those problems.

Fredric: How do we do that? What does New Relic do specifically for multi-cloud environments?

Aaron: We recently announced new integrations for Google Cloud Platform, Microsoft Azure, and AWS. In fact, we’ve introduced AWS integrations starting near the launch of New Relic Infrastructure more than a year ago. We started with AWS integrations and we’ve been consistently rolling out more and more service integrations, not just for AWS but also for Azure and now Google Cloud Platform.

That allows us to actually show a single view of the world for how your infrastructure and applications are running across all these environments. It helps you get to the truth about what’s going on in context in your applications and for your end users. It’s not just about infrastructure, it’s also about being able to monitor the applications that run there. And then, what’s going on with my mobile application? What’s going on with my browser app? Those types of things.

With these new integrations, we can better monitor all the major cloud platforms as well as on-premise infrastructure, as well as applications and the end-user experience. That really helps us deliver to the customer the ability to monitor across the board in a consistent way that helps eliminate that finger-pointing.

Fredric: Aaron, when we say we have new “integrations,” what exactly are we talking about?

Aaron: An integration specifically for cloud services means a couple of things: It’s the services that the cloud vendor provides. For example, information about a particular instance running in that cloud, and metadata about the instance itself. How big is the machine? How much memory does it have? What kind of tags have I defined for that machine because this runs in production versus development? And so on.

It’s also the other services that these vendors provide that you want to monitor. Things like database services, for example. How well are they performing and what’s going on in that environment? Things like email services or auto-scaling services that help me scale up and down my infrastructure as needed based on the demand of my applications. All of those services are distinct and they’re provided slightly differently. They’re implemented slightly differently in each cloud platform.

When we release a new integration, it’s pulling information via an API from the cloud vendor that shows you the health of that particular service, and then that helps you relate that to what’s going on in the rest of your infrastructure or applications.

Fredric: That makes a lot of sense. Putting that in context, what are the goals of these integrations?

Aaron: Typically, these are requested from customers for the things that they want to monitor. A good example of that would be our AWS Lambda integration. Customers have said, “Hey, I need to get a handle on the functions that are running in Lambda. Can you help me do that?” So we provide that. The end goal ultimately is to help our customers with problems that they’re having either migrating or running in the cloud, and give them more information.

And then to be able to relate that information about how those services are running to a particular problem or a particular way that they can help influence their applications and their end-user experience. An example of that is, I have a particular function; it’s taking up too much memory or it’s running for too long in Lambda. How can I take that function and optimize it so that I cut down my web sales transaction time from 20 seconds to 10 seconds? Can I do that? That’s the type of data and insight that we can provide to help customers either solve problems or improve the way that they do business.

Tori: We’ve had examples where the cloud vendors are appreciative of our ability to reduce the finger-pointing, shockingly. You know, it doesn’t really matter where the problem falls. Whether it’s on the cloud vendor or with the application, the key is the amount of time you’re wasting going back and forth, going, “We can’t find a problem. Oh, we have a problem,” that sort of thing. It’s really nice to pull these things up in real time, look at them and go, “Oh, that’s the source of the problem. Now we can spend our time fixing it rather than arguing where it exists.”

Aaron: I often give the example of the old Reese’s Peanut Butter Cups commercial. It starts out with, “Hey, you got your chocolate in my peanut butter.” And the other guy says, “Hey, you got your peanut butter in my chocolate.” And then very quickly they realize that there’s a way to actually bring this together and look at it and solve the problem, which is in this case to create a wonderful snack that people can enjoy. That happens a lot. You get this finger-pointing, and then all of a sudden, if you can centralize on a tool that will help you cut through the static and get to the resolution faster like New Relic does, you can get past that point. That’s really what our customers are looking for.

Fredric: Of all the new integrations that we’ve just announced, is there one in particular that we’re most excited about?

Aaron: For me, it would be the Google Cloud Platform integrations. These are the first three integrations that we developed for Google Cloud Platform. Specifically for New Relic Infrastructure, we’ve been able to run on Google Cloud Platform with no problem for a while, but the new integrations are adding extra insight into what’s going on with Google Cloud Platform. I mentioned the metadata that you can pull, for example, from your instances that you spin up in Google Cloud Platform. That’s important.

But we also have an integration for GCP’s function service that does something similar to what I talked about before with Lambda. It helps you measure how much memory you’re using when you run each of those functions and how long they take to run. And we also have an integration into their storage service which helps people figure out not only how many API calls my applications are making to the storage service, but what’s the throughput there? Do I need to go back and cut back maybe, or figure out a way to tailor the amount of data I’m sending back and forth to that service, or improve the transaction time in some way?

Fredric: Given the support we’re putting together for multi-cloud integrations, I have one more question. What’s the future of multi-cloud?

Lee: I think what’s going to happen is there are going to be particular cloud providers that are optimized for particular situations, particular services, particular types of customers. And I think that specialization is going to be helpful. What that means from a customer standpoint is, yeah, you’re going to be using multi-cloud probably forever depending on what your needs are for specific purposes. But I think this customization is going to allow each cloud provider to differentiate themselves and allow customers to choose the best solutions that make sense in each of them. So we’re going to have to keep working together.

Tori: What I find interesting is this whole thing about public cloud versus private cloud. That really seemed to be a big argument. Now, the numbers seem to suggest that private clouds are becoming a little bit less popular. Not that marketing people tend toward hyperbole, but I did see a topic of a webinar that asked, “Is the Private Cloud Dead?” I think that’s a bit of hyperbole, but I think it’s very interesting that there was an assumption that people would go to private cloud first and then to the public cloud and that may or may not hold moving forward.

Lee: Whoever wrote that article should spend some time in Europe because I’ll tell you … especially in Germany.

Fredric: Right, they’re still deep in it.

Tori: Exactly.

Fredric: But it does seem that the arc of history is leading toward the public cloud and multi-variant public cloud, where there’s different choices for different things.

Aaron: I agree, too. But you can’t rule out providers like Pivotal and Rackspace that are providing that additional benefit that customers are looking for: “Hey, I don’t have the resources to do this myself. Can you provide some extra services to run in your particular environment—and help me do it?” A lot of times we think about this in terms of big corporations, but there are also smaller corporations that just need a hand in making this migration to be able to realize the benefits they’re looking to achieve.

The exciting thing is that as you move to the public cloud, all of these different choices increase the odds that you’ll be able to get a set of services that really meet your needs.

Aaron: That’s exactly it. The expansion of technology is great because it provides a lot of choice, but you also have to be able to effectively monitor that to see whether it’s working or not.

Fredric: And that’s our goal, right? No matter what kind of cloud you’re in, New Relic can give you the monitoring services and the point of view that you need.

If you like what you hear, be sure to subscribe to the New Relic Modern Software Podcast on iTunesSoundCloud, or Stitcher.

Note: The intro music for the Modern Software Podcast is courtesy of Audionautix'

Fredric Paul (aka The Freditor) is Editor in Chief for New Relic. He's an award-winning writer, editor, and content strategist who has held senior editorial positions at ReadWrite,, InformationWeek, CNET, Electronic Entertainment, PC World, and PC|Computing. His writing has appeared in MIT Technology Review, Omni, Conde Nast Traveler, and Newsweek, among other places. View posts by .

Interested in writing for New Relic Blog? Send us a pitch!