Home > SolarWinds Lab Episode 81: Debunking the Cloud Hype Curve With Microsoft Azure Advocate Rick Claus

SolarWinds Lab Episode 81: Debunking the Cloud Hype Curve With Microsoft Azure Advocate Rick Claus

Hype isn't helpful, especially in IT. And cloud has now reached a special status: Zombie Hype. It just keeps coming back over and over. In this session, Microsoft Cloud Lead Advocate Rick Claus joins SolarWinds Head Geeks Patrick Hubbard and Thomas LaRock to break down how SolarWinds customers are using cloud in the real world. Learn what hype curves are, how they're different from adoption cycles, and how to gauge your organization's journey relative to your competitors. We'll cover user experience from the Pit of Despair to the Productive Paradise, diagram snakes eating elephants, and get industry-specific tips. We'll also talk about the common benefits and challenges based on where you are on the adoption curve. Whether you're an early, middle, late, or non-adopter, you'll discover how useful your existing skills are when it comes to building an effective cloud plan—even if your plan is nope.

Back to Video Archive

Episode Transcript

Welcome to SolarWinds Lab. Tom and I are joined today by Rick Claus from Microsoft. How you doing? And we are talking about how incredibly helpful hype is in getting our jobs done, day to day, in IT. Yeah, hype. Hype for things like autonomous databases or you know the blockchain, or how about 5G, that's lots of hype. Now, come on, you got the Microsoft guy in the show, you gotta talk about the biggest hype thing of the last nine years. Yeah, the cloud? The cloud. You gotta talk about the cloud. Yeah, but at this point, is it actually hype or is it just a thing, like virtualization or anything else? It's like a zombie, it keeps on coming back. More and more hype keeps coming up about the cloud. But, really, it's just a series of tools and technologies that you can use in your everyday job, no matter where you happen to be on that hype curve. Right. So, okay, well, what should we talk about you think? So today I think we should look at that hype curve, help them understand where they might be along that adoption phase. Okay, and you know, I can interject with some ideas and stories for customers that I've heard, about what they're using and what they find useful during those different phases. That'd be great. That'd be awesome. And then along the way, we'll also give some recommendations about how to be really successful and measure where you are along that curve. The advantages, disadvantages, and some specific ways that you actually make it a lot easier for yourself and get more out of the technologies that are part of cloud. So, what I think we should do first is maybe get a picture, to help people understand what that hype curve really looks like. Don't you think a diagram would always be helpful? I think so. You know what? I got this, I got this. So over here we've got time. And then over here we have excitement. Now, new technology comes out, you've marketing slope at the very top and peak, lots of excitement and then it goes down into the pit of despair, and then eventually it goes over to productivity and adoption. Yeah, so basically, we can never do this, computers can do this and then it's a budget item and it's just something that you use everyday. And here's just a whole bunch of marketing, babble and speak, you know, blockchain will solve everything. But they change from year to year, right? Well, they do, and that's where you can get the most value out of this. Is that if you look at a hype curve for just one particular year, well, it's actually quite useless. You have to look at them year over year, it has to be like your own time series. You have to compare them one year after another because that way you can see where something, like a blockchain, would move along the curve, because sometimes technologies become obsolete, even at the height of their excitement. All of a sudden, before adoption can happen, it's gone. But then doesn't it mean that the whole thing is basically delayed by some amount of time because it's a measurement of excitement and despair. And it's not a measurement of what you're actually doing, it's really sort of expectations, after the fact, that you're sort of being measured against? I would say so. Let's put this into something more tangible, let's talk about a technology that all of us have used and has actually gone through this whole cycle of what things are. So how about virtualization. Ooh. Right? Virtualization back in the day Ring 0, Ring 1, hypervisors and that sort of stuff for where people happen to be. It all got very much hyped, all sort of craziness, everyone is all there, all of a sudden it went down and to no, no, no, I'm never gonna leave my bare-metal servers, I'm always gonna stay on bare metal, makes no sense, I lose too much power and performance. And now it's gone through the last of the progression, it's just everyday table stakes, everybody does virtualization, regardless of your provider. Yeah, that's a great example, I mean. So what would be a better way of looking at that? I think we should talk about this from a simple adoption curve or adoption wave or whatever term you wanna use but simply, it's adoption for a lifecycle for where things come. So how would we help them to figure out where they are along that adoption curve. Let's actually start with the chart that's actually based on data. Like an application life cycle, think of it like a snake that's eaten an elephant and then back down. That sound gruesome. Ow! So, you have a few people at the very far end, they were early, early, early adopters. And then there's a few that are really catching up. Where's the majority? But where's the majority? Right here in the middle. How do you figure out where you are? Well, from my experience, it's been a matter of kind of stepping back and looking at the projects that your organization and you have been doing. If you step back and look at the last six to eight months or nine months of what's been going on, is it just all the same and nothing new, nothing's changed? Then more than likely, if you're not self-aware, you're probably gonna be in the latter half of that particular curve for adoption of new technologies. If maybe there are a couple of small things that are popping up, that are kind of like a little small, rogue group that's going off and doing their own thing with the cloud service or doing their own thing with Kubernetes or containers, something like that, maybe that's gonna be more of the front end of that particular curve before the adoption goes. But the important part is that you have to invest and step back and analyze what's going around you and take an active interest in this. Get your head up, out of the toil of everyday what's going on. Well, the other thing I hear you saying though, is that there's no shame and you're measuring just where you are and, mostly, you individually and your organization, maybe you're both different. But, none of that, there is no measurement against hype. There are certainly expectations that people have to deal with, but you're saying that you just are somewhere along that adoption path and then there's going to be benefits, there's gonna be challenges and then some basic tricks that you can use to make that a lot easier. Mn-hm, absolutely. You're literally looking at a technology, does it solve a problem that I have? And then looking at your readiness, as an organization, as an individual, to actually use this to solve a problem that I have inside of my organization. I would also remind the audience that it's industry-specific. So there being certain parts or pieces of these technologies that might be really critical for you to be on top of and be an early adopter for. And other things you could, "I can wait, I can wait for that to be mature." COBOL COBOL. So you don't have to feel pressure that you're missing out on something, that you're falling behind just because there's something in the early excitement phase. It can be industry-specific as well. And there's absolutely stuff that you can do when you do this analysis to find out where you are in this particular learning adoption, to determine what I can learn from it and then how can I leverage it and to start to apply it inside of my work environment. So there's something for everybody across this full spectrum. So, is there a specific set of recommendations that we could give to people regarding this adoption curve? Well, let's start over here in the early adopter phase. That's where everyone starts. Yeah, you and I both started at-- Absolutely, I was down here like nine, 10 years ago. And so everything that you did nine, 10 years ago, perfect, you wouldn't do anything differently now? Absolutely not. I would change it, because things have evolved, new technologies have came out and different of ways of doing things to bring out new efficiencies have come about. So if you're inheriting a project that might have been an early adopter years ago, you need to go through some phases of understanding, is that still optimal? Because things have changed. So what advantage that drove you to that in the first place? Why would you do it? Well, new capabilities that didn't exist, for instance, for me, for on-premises. I wanted to be able to go off on the scale and take advantage of this new thing called cloud. And so it simply was understanding the capability of, "Hey, I can spin up VMs inside of Azure." When we actually first started, we didn't even have VMs and infrastructure, so that was all a PaaS-based service. So now, as soon as VMs came along and like, ah, I can understand that, it's virtualization to the next level, let's go off and implement some stuff. Right, so for some businesses it was a huge competitive advantage, right? I mean, they always trot Netflix out on stage to talk about it, but, yeah. So early on, especially if you had some VC backing and you had a little excitement going on on the curve, then moving to cloud was an option to really gain some visibility about what you were doing. But, to your point, then you've what? That's a lot of risk. Let's say, operationally, I need to go back and validate that it's still there. Like, maybe the VMs I chose are now out of date and I should be using different size VMs, maybe I'm not using enough of the VMs, so I can shrink the size down to save some costs. Maybe I was gonna come off with a better way of having load-balancers in front of them, there are a whole bunch of different technologies that came out after that first early adoption. But I don't know, necessarily, all the different things that are involved in a original project if I wasn't the original creator of that project. Right, and there's also some costs disadvantages, maybe, to being early in that you are maybe gonna have to do some rework. Maybe you've got some old tech, you would have done it differently. Or maybe you've got a bunch of shadow instances or infrastructure that was set up, maybe by developers or someone else that's been out there running for a long time. What about multi-cloud? Is there more use of multi-cloud for early adopters, or is it about the same for everyone? There's only one cloud. I work for Microsoft, of course. [laughs] No, no, no, seriously. No, multi-cloud is definitely one of those things that's on the, I think it's about on the peak, if I will, as far as the hype is concerned. Because, I mean, it definitely is possible, you can go off and run different components inside of different cloud providers and even on-premises as a private cloud as well. But, again, there are different efficiencies, different standards, standards change, the way you connect into things. I think you guys had Pierre Roman here for another one of these things. He actually wrote an article about how to connect AWS and Azure, and then he needed to rewrite that article just recently because the technologies changed, people make that connection. Right and I think that's the real thing that's a discovery for people about multi-cloud, is the idea of, well, I can run the same workloads across everything. But, really, 10 years ago it was a bunch of different shaded services, they'd pick cloud A for one particular feature, cloud B for another one. I mean, my original phone system at my house was IBM Bluemix because they had some early voice recognition technology. You guys had some private phone system at home? Yeah, exactly. Silly stuff. But the point is, I had to consolidate that, right? And so, a big part for the complexity, and a lot of our customers talk about, is they are doing what we've always done in IT, which is to go ahead and combine those into a smaller number of instances, right? So that is now you're reimplementing, a lot of times, something that was maybe an early version of a service that's not actually ubiquitous across platforms. And being able to consolidate, again, it's not exactly completely reimplementing but there's some additional cost to that which is a drawback to being early. You guys have, I'm assuming, got something to be able to help out with these recommendations that are coming out here, so if I have the problem of not knowing what's involved with this project, what can I do to be able to go off and to discover this kind of stuff? Well, yeah, I think the recommendations for early adopters, I would say, important things are discovery and consolidation. Right? So there's plenty of ways for, especially our customers, just one of the things we try to help them with, all of our customers that tell us that they're using cloud, we're like, "So this is the area you're gonna need help with." One, of course, being discovery. So what does that cover? Application Performance Monitoring, SAM, what else, we have WPM for SaaS services, so NetPath, these are all different ways to help get that discovery phase, understanding what's in your environment right now. Right, then application changing more to an APM approach to monitoring, especially if you were early, you've got a lot of technologies, maybe, that you're not accustomed to, you've got, ideally, horizontally scaled applications that are based on cloud-native technologies and so there may not be a lot of traditional infrastructure to monitor at all. And so for them being able to do application tracing with code injection, being able to do log aggregation and analytics at a really high scale that maybe they haven't before because the ephemeral nature of cloud-based logging, it's just hard, there's no disk to necessarily go to to pull logs from six months ago. And then a little bit of a focus more on external monitoring, even beyond NetPath, right, where this is, how is the application actually performing for users, as a way of tracking back and discovering what the components of that are that were built out of that early cloud-native technology. And the consolidation part, I think, we have a nice tool we built with Microsoft, the Azure Cost Calculator. That's one of those ways where we can help you understand where you're actually spending your money right now. So if you're thinking about, maybe, moving or if you find yourself in early adoption or you maybe you wanna be in early adoption, you might have a way to, say, consolidate certain workloads that you might not even know were happening. You might have maybe too much sprawl and you might want to be able to rein that in, especially in the early adoption phase, where everybody is like, "Oh, I get my own Sandbox in Azure." There's a little bit of shadow IT with early adopters. Shadow IT, right. So you might have, it's one of these ways where we want to help our customers understand where they're spending their dollars in the Azure cloud. Yeah, I mean, we've got a bunch of good stuff as well for built-in tools to provide you with some guardrails, as my good friend Phoummala likes to say, with governance to make sure that you don't give everybody admin access all over the place and don't give everyone ownership access to everything. To keep people within their own little compartments and prevent the sprawl, but you have the tools that we develop together to be able to discover stuff, and go off and make recommendations on consolidation. But that's not where most of our customers are, I mean, I can't imagine there's a company out there that does nothing but early adoption of all these technologies, right? So the bulk of the work that we always see and hear about, is that middle part, yeah? It's the early adopters are definitely on the smaller side, the bulk of the people that I've seen, the customers I've been talking to, they're definitely smack in the middle, that elephant part of that curve. And so where are the benefits and challenges for the people in the middle? Generally, the benefit-wise, I mean, they've already learned the lessons from the people that were the early adopters for these different technologies. They figured out the bumps and the grinds and the support issues that they have to worry worry about and then more documentation is available, more training's available for people there's a more rich ecosystem they can lean on to be able to get stuff fixed and be able to ask questions, those are definitely some of the benefits I've seen. And, potentially they can choose to follow those individuals or, deviate from that path and then go down their own path with the lessons learned from the first guys. Well, it's also a lot easier, right? The technology's a lot more mature, there's tools that are second and third generation, that are a lot easier to work with. And to your point that the training is actually, there's formalized training, but especially with cloud, so much of it is free. So, recommendations for the people in the middle, like, for me, one very big important one, especially for everything you're doing these days, I tend to focus on the security aspect. Like what is it you're doing where you are right now? And are you current with everything? Because in the early adoption phase, you know, near and dear to my heart, being a database guy, it was always, "we'll worry about that security stuff later." So you know, whatever got deployed in that early adoption phase that is now in that middle pit of despair, one of those things of despair, like, "Oh, this is hard." Is one of those things is, yeah, we need to make this, we need to apply security, we need to make sure that our data is secure and private. For the recommendations, you have to plan for that because you know that it's coming. So a lot of that goes back to Rick, what you were talking about, about really taking a step back and assessing and like making security for once, one of the things that we get to put put up front, because I don't think in IT, we ever think about security last. I think we tend to think about security first, it just tends to be kind of last in the budget, or maybe people who are pushing rapid adoption, like, "yeah, we'll get to that later." gives us a chance to really to step back and say, "Hey, hold on a second." This cloud thing, the whole point is to increase access and availability and let more people get in here and for us to be more responsive and more nimble. But that's kind of scary if you haven't put governance in place. What about sprawl? That feels like something that early adopters maybe ended up with a lot more that you have an opportunity, by being middle in terms of adoption, to really keep under control from the beginning. I mean, a lot of people go through, like you mentioned, and just simply run with too much administrative rights. And therefore they can go off and create what they need to get a job done, and then move on to the next task at hand and maybe are missing some good clear guidance and governance. So we have some very good governance from people that are doing cloud adoption at Microsoft, we call that the cloud adoption framework, if you will, and that allows you to kind of step back and see what have other people done when they're adopting these new technologies, what things they're putting in place to make sure that they don't end up with a lot of sprawl. But if you've inherited the sprawl, as you mentioned in the first segment, you've hopefully discovered where that is, you've taken advantage of cost benefits, and you've consolidated some stuff. And you don't have that issue now. You're in the middle phase of adoption. A lot of our customers that use our Virtualization Manager tool, which they've been using for years on-prem to manage sprawl. And I had someone talking about it the other day, and he said, "Oh, it's the moving problem." You get rid of as much stuff as you can before you pack everything in boxes, and then you move it to your new house, then you unpack it, and then you throw away 20% of what you move, because you didn't get rid of it all. Don't take sprawl that you already have on-prem into the cloud, because it might be free for you sitting in a rack, but it's not free once it gets to cloud. So that area of sprawl management and thinking about what do we actually have and what we need, ends up being something that's really important, but it's much easier because you already know how to do it, so you can carry those skills forward. Do you see a lot of people also seem to be happier now because they have options from vendors that they've been working with for a really long time? They don't have to go and pick some bespoke small company for each niche that they're trying to serve. Yeah, a lot of technologies are starting to flesh out with different experiences and different levels of maturity within each of the different providers in the cloud space, for sure. Also, even just the general knowledge of the individual organizations and teams looking to use cloud technologies, they're becoming much more aware of what they're comfortable with, of using inside of the cloud, and what they're comfortable with keeping on-premises and having kind of a hybrid connectivity, too. So, I'm finding more customers are moving away from the whole concept of the best of breed and instead kind of bringing us into a clearinghouse of more of one to be able to take advantage and leverage of scale and leverage the benefits of having that one partner, as they say, "the one throat to choke," if you will, when there becomes an issue. So I think that's also what you're seeing on our end about trying to help the bulk of the people that are in the middle and working with companies that they trust, this is why we have our tools now listed in the Azure Marketplace, right? In order to help you understand what's really happening because we have lots of experience and lots of customers, and we know the struggles and the concerns that they have. And it's been beneficial to say, yeah, we're the same company that you trusted before. And we're working with Microsoft, and that we can help you monitor and manage and alert on those cloud services and infrastructure that you're actually running as well. So it's a nice way to say, basically, that trusted advisor role, it doesn't matter where you are, what you're running, there's going to be a way for us to help you get your job done. And so, well, exactly. It has also been time for vendors to really make that integration simple, right? If you go back, for those of you who saw Lab 80, we actually did a demo of what that looks like deploying out of the Marketplace, and you should definitely check that out. But it's cool because the forms that actually asked for users' passwords, the way that that's actually set up, the way that it's configured are all part of that Marketplace. And then it goes and creates that instance for you. It also, there's some other things that we've done in the last few years to make it easier, like any other vendor that's been around for a while, like our Orion Platform products can run on Azure SQL, so that if you want to actually start managing your database, that's an option. And then, Server & Application Monitor has a license model, now that's node-based so that it makes it easier. You're not thinking about all the little discrete things that you're monitoring, instead, you're more thinking about the application infrastructure for the apps that are running in cloud and not so much about this runs on that server with this many instances and it's just a lot more flexibility for the way that she would do an install. So, I know you guys have already done an episode on this, but I haven't seen that one about Azure Marketplace. And so I'm curious, what is your adoption, like from your customers using your products inside the Azure Marketplace? That's a great question. Well, first of all, we did a Lab episode on it. So, that kind of is the answer that you all are actually doing that. But that was really to showcase that we had added the Orion product portfolio. But, we've had a couple of products in the in the Marketplace for some time and we actually started with DPA, Database Performance Analyzer Database Performance Analyzer, yeah! So here's the thing, what DPA does is it's gonna analyze the activity inside of the engine. I don't care where that engine's running. I don't care if it's running in your data center or somewhere else, it's an engine and it's either running, runnable, or suspended, and that's it. That's what we're gonna track and we're gonna aggregate up. So yeah, we've been there for a while. So this was great talking about the middle, but what about the last third there, the late adopters. So being a late adopter isn't necessarily a bad thing. You can leverage a lot of the stuff that people have done before you, the technology's more mature, there's less potential risk that you have to worry about, but still at the same time, there's still time to actually go ahead and do the implementation. OK, now you say it's not necessarily a bad thing, and I might agree for the most part, but I'm gonna tell you of two things that you really need to consider. One, is that it could be harder for you to find people to work on those systems, because they're so old, like COBOL, mainframe, we can go down the list of the stuff that still exists, and people say they're still looking for these programmers to do these weird things. Don't worry we're gonna migrate it. But you know that it's not that they don't exist, but they also come with a higher cost. This is a risk you have. But you're also, if you're that much of a late adopter, your competitors may have been years ahead of you, compared to where you are now. So, you could be really far behind. Let's say, like, if you wanted to build a cloud these days, if you hadn't been spending money, in any sort of cloud development for the last 10 years, you're probably going to be far behind and never catch up. There's definitely some catch-up things you have to worry about in that particular sense. But I'll also talk about one thing that's very near and dear to my heart right now, for the Windows side of things, is end of support for Windows Server 2002, it ends, the show airs after the end date, I think, I have to think about when that is. No, actually it's January 15th, so this is before it ends. Is that the extended support? That's the end of regular support. And you can purchase extended support if you need it. This is not an advertisement for Microsoft. But I'm just saying, this is an example of someone that may be waiting to adopt newer technologies, still using the old stuff because it still works, but you're putting yourself potentially at risk, because it's gonna be now more expensive to have to worry about getting security updates from a vendor like Microsoft. It also can be another issue where I came across a customer that were also trying to get as much as they possibly can out of the capital investments for their hardware, that now their hardware is out of support by the vendor, and it's coming off of lease and then have to purchase it or buy another extended support just for the hardware that's running their virtualization platform. So, watch out for both of those capital costs, extended support, and also software-based extended supports, too. But what are your recommendations for this? Well, when we talked to customers who are, I don't need to say late, they'll usually say, Well, we sort of have a toe in the water Cautious, they're cautious or we're starting to experiment. Yeah, or maybe they have a couple of, maybe start with backup, or maybe they move a couple of variable workloads out or something else. What they are telling us is that they are spending a lot of time learning that they're using this opportunity because it basically cost them nothing to really learn about technology, and there's so much available that they know when they're ready to go between standardization, technology tends to become less expensive over time, that they're going to be ready to go because they want to be able to accelerate that as much as possible once they launch. And a lot of customers, certainly if you've been a part of, seen any of the THWACKcamp episodes, you've you've heard us talk about opportunities for free learning on the networking side. Definitely a lot of them are involved with Cisco DevNet and then they're also involved with Microsoft Learn for their Microsoft technology. So obviously this is where I put the plug in for aka.ms/azopsfun for the operations fundamentals about what is going on with Azure, Zed? "Zee" for you Americans. It gives you a free sandbox to go off and to learn cloud technologies, doesn't cost you anything, tracks your progress, gamification, all the cool stuff that all the cool kids are doing. And you can try that out for free right now. And you can put that in the lower third down there, right? We'll put that in lower third, and we'll also put it in the show links, the notes so that you guys can click on that as well. Well, this has been a really interesting conversation because the big takeaways here, at least for me are, one, ignore the hype. Well, don't ignore it, but don't use that as a guide to knee-jerk make decisions about what you should be doing. We can say be informed about the hype. Right be informed about the hype. The second one is there's no shame, regardless of where you are along the adoption path. There you have reasons for it, just be aware of where you are so that you are aligned with your competition and available technology and cost and really aligned with what your business actually needs. Not what the hype is telling your business that it actually needs. And then we had a chance to talk about some recommendations for how to use products that you already have as you go through this evolution, but, is there anything else that you'd recommend? Like how often should people take that moment to consider where they are on that journey and where they are in that process? So I recommend people at least do it on a quarterly basis, even if it's just like a like a lunch-and-learn, brown-bag type thing, just get together and kind of shoot shop about what's going on in the technology area, where you are in the different kind of hype environment of the adoption lifecycle, and things like that, at least a quarterly basis, maybe once a year, if that's more of a slower adoption, kind of curve, your call. So not necessarily assign somebody to keep an eye on that, but maybe brown bags, every now and then? For me, it's a group effort. If you assign one person that one person is gonna get overwhelmed with it. So involve others with it, but you have to be curious and you have to want to follow up. That's awesome advice. Well, so hopefully, you've got a lot of great questions for us in the live chat, which will be over here to your right. If you don't see that chat, It's because you're not with us live. Swing by our homepage which is lab.solarwinds.comm, check out dates for upcoming episodes and make sure you can be with us so that we can take your questions on-air. Thanks again for being a part of SolarWinds Lab. I'm Patrick Hubbard I'm Thomas LaRock. And I'm Rick Claus from Microsoft.