Dwayne Monroe is a senior cloud architect at Cloudreach, an organization that helps enterprises maximize their cloud investments, who’s focused on Azure. Prior to joining Cloudreach, Dwayne worked as a senior Microsoft and cloud architect at High Availability, Inc., a Microsoft cloud solutions architect at McGraw-Hill Education, and a Microsoft Technologies Architect at MedRisk, Inc., among other positions. Join Corey and Dwayne as they discuss the journey that led Dwayne to Azure, how and why the typical customer ends up in Azure, the kinds of new services Dwayne sees being built on Azure, why it’s important to understand an enterprise’s legitimate concerns as they consider cloud migration, how Visual Studio Code is awesome and would be even better if it worked on an iPad, how the people who use Azure tend to be more concerned about operational things than very flashy things, how negotiating with Microsoft has gotten considerably easier in recent years, and more.
Episode Show Notes & Transcript
About Dwayne Monroe
I've been a technologist, in some form, for most of my conscious life (starting with a Sinclair kit computer). I work as a cloud architect, focused on Azure and spend a lot of time thinking and writing about that (particularly controlling spend). Besides that, I enjoy a good Bordeaux or martini, travel and my life as a transplant to Amsterdam.
I've been a technologist, in some form, for most of my conscious life (starting with a Sinclair kit computer). I work as a cloud architect, focused on Azure and spend a lot of time thinking and writing about that (particularly controlling spend). Besides that, I enjoy a good Bordeaux or martini, travel and my life as a transplant to Amsterdam.
- Books on Amazon
Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.
Corey: This episode is brought to you by DigitalOcean, the cloud provider that makes it easy for startups to deploy and scale modern web applications with, and this is important to me, no billing surprises. With simple, predictable pricing that’s flat across 12 global data center regions and UX developers around the world love, you can control your cloud infrastructure costs and have more time for your team to focus on growing your business. See what businesses are building on DigitalOcean and get started for free at do.co/screaming. That’s D-O-Dot-C-O-slash-screaming and my thanks to DigitalOcean for their continuing support of this ridiculous podcast.
This episode is sponsored by a personal favorite: Retool. Retool allows you to build fully functional tools for your business in hours, not days or weeks. No front end frameworks to figure out or access controls to manage; just ship the tools that will move your business forward fast. Okay, let's talk about what this really is. It's Visual Basic for interfaces. Say I needed a tool to, I don't know, assemble a whole bunch of links into a weekly sarcastic newsletter that I send to everyone. I can drag various components onto a canvas: buttons, checkboxes, tables, etc. Then I can wire all of those things up to queries with all kinds of different parameters, post, get, put, delete, etc. It all connects to virtually every database natively, or you can do what I did, and build a whole crap ton of lambda functions, shove them behind some API’s gateway and use that instead. It speaks MySQL, Postgres, Dynamo—not Route 53 in a notable oversight; but nothing's perfect. Any given component then lets me tell it which query to run when I invoke it. Then it lets me wire up all of those disparate APIs into sensible interfaces. And I don't know frontend; that's the most important part here: Retool is transformational for those of us who aren't front end types. It unlocks a capability I didn't have until I found this product. I honestly haven't been this enthusiastic about a tool for a long time. Sure they're sponsoring this, but I'm also a customer and a super happy one at that. Learn more and try it for free at retool.com/lastweekinaws. That's retool.com/lastweekinaws, and tell them Corey sent you because they are about to be hearing way more from me.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Dwayne Monroe, Senior Cloud Architect at Cloudreach. Dwayne, welcome to the show.
Dwayne: Thank you, Corey.
Corey: So, you come from a world that I don't understand in the least. I'm not talking about Amsterdam, which is where you apparently live, but rather that you're a cloud architect who's focused on Azure. I tend to operate in a world where I deal with obviously a lot of AWS, I do see some GCP from time to time, in similar environments, but while I do have customers that are doing significant spend with Azure, I never encounter it in the course of what I do with them. So, what I brought you here to ask you about is, you don't work for Microsoft. To my understanding, you've never worked at Microsoft.
Dwayne: That's right. Yeah.
Corey: And what I want to know is, tell me about Azure customers, please. As someone who does not have a particular horse in the race that depends upon you selling Azure to answer the question.
Dwayne: To answer the question, I think, let me tell you a little bit about my own, to use the term of art now, cloud journey; forgive the phrase. I started my career, as many of us of a certain age did with general geekery. And then when I graduated from university—in which you have computer labs, and all that kind of stuff—I was floundering for a job, and I was working at a boutique bank in Philadelphia. And that bank found itself facing some challenges from the FDIC. That led to me becoming—because I was the youngest person there and the person who seemed to have a handle on client/server technology, that led to me becoming the person who deployed the first network.
Kind of fast forward a bit. I'm working in enterprise-scale data centers, like pharmaceutical firms, and this sort of thing, and at one of these particular situations, I was introduced to AWS because there was a problem that the organization had, which was scalability. We were selling books, and every season, the type of book that was being sold, the VMware infrastructure that we were using would be stretched to their limits. A very smart colleague said, “Hey, how about EC2 instances, Elastic Beanstalk?” I’m like, “Well, what the hell are you talking about?” So, I dove into that. So, I began my cloud journey with Amazon, as I think many people did—
Corey: For a while, they were the only option. I mean, you wouldn't call it Cloud if you spent a long time working on, I don't know, VPSs offered by some fly-by-night web hosting company. That, it would sort of look like cloud today, but we never called it that back then.
Dwayne: That's exactly right. And Microsoft at the time under, I think it was still Mr. Ballmer, Azure was just Windows Virtual Machines, but it was very weak. So, I didn't pay attention to what Microsoft was doing in that space because what Microsoft was doing wasn't compelling. Fast forward a couple of years and leave out a couple of details, I'm working for a firm out of New York that had pivoted to Office 365, and one day—and this may make me sound like a genius or may make me sound like a goofball, I don't know—but one day, I was sort of poking around at the base of 365, I noticed that there was an Azure AD tenant. And I said, well, let me just log on to this Azure AD tenant, and voilà, there's all this going on. And I’d been so Amazon focused, and Microsoft up to that point—and this is going back four or five years—up to that point Azure had not been compelling, but it was becoming compelling.
So, I pivoted to Azure because I'd already had kind of a deep commitment to Microsoft technology, to the Microsoft stack, and it seemed to be a logical progression for my career. To get to your question, and that's a long-winded way of getting to your question, the typical Azure customer, from my point of view, is an organization that has a deep commitment in Microsoft stack, and sees the need to modernize that stack into the Cloud, and Microsoft has provided a bridge. So, you have SQL Server on-premises, and you can modernize that SQL Server, you can do it on-premises. But then that SQL Server on-premises, the code has been put into SQL server to see assets in public cloud Azure.
So, Microsoft's hybrid story, I think, is very well realized. And so the typical Azure customer, from what I've seen, are customers that say, “We have these investments in databases and so forth, storage that are Windows-based, built around the Microsoft stack, and we need to get out of the data center business; we need to get out of the infrastructure business. Let's move that stuff to the public cloud. And Microsoft has already built the code that allows us to do that, if not easily, at least you can see the direct path.” You can cross the Rainbow Bridge, and go from where you are within your messy data center to your cloud estate. It's very logical.
Corey: I have a standing policy of not insulting various customer choices, workflows, environments, etcetera, unless A) they are very clearly egregious or B) I'm trying to make a larger comic point. And I want to revisit that because there's absolutely nothing wrong with what you have just described. The whole Silicon Valley model is built upon more or less sneering condescendingly down your nose at anything that was written more than 18 months ago, but that is very clearly not how the world works. We are focused on building new, but everything that we're building on top of has been around for ages. And just because there's a new or different paradigm for developing these things, does not mean you get to sweep away the last 30 years of development work. So, there's a tremendous need for an awful lot of these workloads to migrate out of the data centers in which they find themselves. So, far, the worst environment I've ever seen, from a physical risk standpoint, was where the data center was in a company's office. That office was located on a boat. That boat was holding the data center, and data center was below the waterline.
Dwayne: Oh, my God.
Corey: So, there was a migration to Cloud, and not surprisingly, there was a challenge as soon as that was completed. People who were working on the boat were reporting severely increased latency.
Dwayne: Yes, of course.
Corey: This stuff becomes a problem. Stacks aren't written 15 years ago to take advantage of the new paradigm that we find ourselves in today. How do you get someone to go from where they are to where they should be without A) insulting them; B) disrupting what they're doing, or C) forcing them to re-architect everything instead of developing new things for the next couple of years. And Azure has, to be honest, a terrific story around that.
Dwayne: I think so. And I'm not a Microsoft partisan because I definitely see strengths and weaknesses in all of the major CSPs, Cloud Solution Providers, including Alibaba, and even Oracle within a very narrow frame. But yes, I think that—just from what I've seen, and again, I'm speaking as a person who admires what Amazon has achieved, but from what I've seen dealing with enterprises—and let's just take an example: you're making paper clips. You're not a sexy Silicon Valley company. You're not Twitter for Pets.
Corey: Well, you're not Twitter for Pets.
Dwayne: Right? You're not building satellites that beam lasers amongst themselves or whatever. You're making paper clips and you're a multi-billion-dollar enterprise, and you have manufacturing concerns. You have all the classic concerns of companies that do things. And you're saying I understand that my estate of Windows 2003 Servers and Exchange 5.5, all these things. I understand that all these things are a mess. I know that. What do I do to modernize, and the data center refresh is coming up, a hardware refresh cycle is coming up. And my god that bill, it looks pretty bad. Looks pretty bad, am I'm getting yelled at because the CIO went golfing with someone and said, “Well, we're in the Cloud. What are your guys doing?” and was like, “Well, we still have a bunch of servers in our data center.”
I think that the way that you would help customers bridge this gap is number one—and this is I think, where Microsoft does well relative to its competitors, and also where those of us who have been in this business for a while do well, is you, first of all, acknowledge people's legitimate concerns. You do not sneer; you do not condescend. I was at a client that's a manufacturing firm in North America, and the guys who run—and it was all men. That typical—the guys who run the manufacturing facility had legitimate concerns about plant operations going wrong, and things exploding. I mean, literally exploding if valves didn't open, and various things didn't happen. So, the systems control and data acquisition, SCADA network that they use in their plant operations could not be relocated to the Cloud. Full stop.
So, in the push for the Cloud, you have to listen to that, and then architect a solution that allowed them to participate in what was a larger cloud migration strategy without being left behind, but at the same time, which acknowledged their challenges. And so, in the case of this particular project, it was that there was tolerance for the data that was gathered to be on Azure SQL, and Azure SQL Data Warehouse, and eventually Cosmos DB. There was tolerance for that because that was not part of the control plane. It was part of the analysis plane, so if there was a little bit of latency in doing analysis, that was fine. And that took a huge load off their shoulders because they were hosting both the control plane and the analysis plane within the plants that this particular organization has.
So, listening and crafting a strategy that is sensitive to the real-world concerns of organizations. And again, people are actually—they're running vast enterprises, or even mom and pop shops, whatever it may be, they're running a business, and they have legitimate concerns. Sometimes they make mistakes. Sometimes people are stubborn. We are error-prone creatures, so there's that. But often at the base of it, there's a legitimate concern—and usually, there's legitimate concern. That's what I found to be successful.
Corey: I think that this turns pretty easily into a cloud migration story. The problem is, is that it seems that every Azure customer I wind up speaking to, in some way turns into having been a migration story like you're talking about. Do you see net new being built on Azure?
Dwayne: I do. And one of the things I see that is very popular on Azure, and I've seen this multiple times, is IoT. I've seen this in customer after customer after customer. And also net new databases. So, they're building new solutions that are not necessarily customer-facing, by which I mean, they're not the sneaker store. You might build that using Lambda or some other platform, but all of the infrastructure that supports that revenue-generating function might be developed on Azure. And I've seen this an awful lot because I think people—it’s particularly companies that have an acute need for security and compliance to meet those needs, they turn to Azure because I think that the role-based access control story, some of the methodologies such as blueprints and policies, and so forth, it's very, very strong. And it also makes the life of individuals who have to be concerned in, say, pharmaceutical, and finance, and so forth, it makes their lives easier because the reporting from the platform about what's going on is very robust. So, those are the kinds of net new solutions I'm seeing being built, particularly as I said, in those areas in which customers have a very strong concern about compliance and security. I've seen customers turn to Azure for that.
Corey: One thing that I’ve found that I think is, I guess sort of the outlier—it was odd enough that it's worth commenting on—was, I made a tweet a while back, that whenever Azure has issues, it seems like nobody's website goes down. And that was sort of a facile, off-the-cuff response, but what made that interesting to me was that it was basically true. I know it's a weird, and it sounded borderline insulting way of framing it, but in the tweet, I said, “Now, I'm sure there's a bunch of SharePoint servers that are broken.” And a lot of people came in and weighed in on that—oh, did I get letters on that one, all saying, “That's not true.” But I wasn't getting any factual correction or substantiation for it other than, “Well, we don't really run SharePoint anymore. That's kind of what Microsoft Teams is.” Ah-ha. I knew it.
But the lesson that I took from this, though, was that okay, so what are those workloads? IoT makes an awful lot of sense and to be honest, I really should have connected those dots sooner. I had Dr. Galen Hunt from Microsoft, working on Azure Sphere—which is an IoT security platform—about a year ago now. And he had a great conversation about what this looked like. But you generally don't see a whole lot of net new web apps, but I found one. In fact, it turns out, I'm the customer of one of them, and that, sort of, threw me for a loop. I've been somewhat public about using Retool—that's retool.com—not, at time of this recording, a sponsor of anything that I'm working on. But I'm working on them to fix that because I talked enough about how awesome they are that they frankly should be paying me by this point.
Their service runs on Azure. They’ve positioned themselves as a basically Visual Basic for tying web API's together. Though, that is my phrasing, not theirs. I think frankly, it's a better phrasing than theirs because it makes it intuitively clear what it is. I don't have front-end skills, so I can slap everything I need together to build my newsletter, and click a few buttons and it generates what I need. I can pass this off to other folks who I've hired to do some internal work on, for example, getting the sponsor copy in where it needs to go. And this all ties back together and it's transformative. But it's never been intended—from their perspective to be something that is public: it's for internal applications. But it is itself a web app being sold to the masses. So, they built a SaaS product, but even the SAS product that they built on top of Azure is still aimed at back office workloads, and I don't think there was anything intentional about that. I mean, I don't have insight into the decision, but even when you have built something that is effectively public-facing that public-facing thing is just for back-office stuff. If, for example, all of Retool and their hosted version went down because of an Azure outage, that would not cause any disruption to the websites of its customers.
Dwayne: Exactly right.
Corey: Of Retool’s customers. Now, Retool itself may very well have its marketing site down, but it's not going to cause, for example, the front page of an e-commerce website to crash.
Dwayne: That's right. Yeah, that's right. And you make an interesting point because to return to the example of the manufacturing firm I was mentioning earlier, they did build net new web applications using, at the time, Azure web apps. Facing customers, but in their case, the customers would be other organizations. Companies that were ordering their product and could order millions of units of the items that they manufacture. But you and I wouldn't see that if it went down, but many, many large enterprises, including McDonald's and so forth, would know that because they use it to order some key parts of their logistics chain. And so that's the kind of thing I am indeed seeing with Azure that people are building these sorts of things.
I think that—this is just my opinion on this, obviously—I think that it might have to do with who has the mind-space of developers. Who do developers think is worth pursuing, or is a cool organization or something—and not just cool. That’s kind of pejorative and dismissive—but who developers feel is listening to them and offers them the tools that they prefer. And I believe that Microsoft is extremely developer-friendly, but I think other organizations such as Google, and also Amazon, I think that they have, kind of, a panache about that, that perhaps Microsoft doesn't have, or at least perceived as not having because you could very, very easily, or at least you certainly could build a customer-facing web application. It could even be serverless; it could be using Azure Functions, and talk to Cosmos dB, and it could sell your really cool sneakers, but for interesting reasons, I think, that maybe are deserving of delving into, a lot of developers are not pushing for that; they're not going in that direction.
But I think that management from the other side is saying, “Hey, when we do our work, our really key business glue work, it's going to be in Azure.” Again, this is what I've seen many many times. When you ask people, “Well, so why did you choose Azure for this particular workload, these particular series of projects?” “Well, there was advocacy within the organization for people who are advocating for Azure. And also, management said this meets our business requirements.” It doesn't have to do with what you like, we did an analysis, and this is meeting our business requirements, again, getting back to the compliance and security, and also the fact that they can modernize existing skill sets for public cloud.
Corey: This episode is sponsored in part by ChaosSearch. Now their name isn’t in all caps, so they’re definitely worth talking to. What is ChaosSearch? A scalable log analysis service that lets you add new workloads in minutes, not days or weeks. Click. Boom. Done. ChaosSearch is for you if you’re trying to get a handle on processing multiple terabytes, or more, of log and event data per day, at a disruptive price. One more thing, for those of you that have been down this path of disappointment before, ChaosSearch is a fully managed solution that isn’t playing marketing games when they say “fully managed.” The data lives within your S3 buckets, and that’s really all you have to care about. No managing of servers, but also no data movement. Check them out at chaossearch.io and tell them Corey sent you. Watch for the wince when you say my name. That’s chaossearch.io.
Corey: I think you're absolutely right as far as what you just said. There's a tremendous groundswell of developer energy that is pushing for a lot of the developer-first platforms, by which I'm talking specifically about AWS because people have more experience there, and GCP because their developer experience is phenomenal. I mean, that sincerely. Azure has really caught up in a bunch of different ways, and things like Visual Studio Code are transformative.
Dwayne: I love that app so much. I didn't in the beginning, but now I’m like, “This is really fantastic.”
Corey: Get it working on an iPad, and I'll be a convert for life, and I am deep into the vim weeds. Their acquisition of GitHub was transformative, and they are leveraging that in an absolutely major way. I think that they absolutely are positioned to go super well. And I think that saying, “Well, they're not necessarily going to be something where developers flock to,” I think that's wrong. If you take a look at the industry of development across the board, there's an awful lot that doesn't get well represented in typical developer surveys.
These are folks that spend 40 hours a week writing Java at some large company, and then they go home. They don't tend to engage in community as much as some of the avant-garde front end development types might. You see people doing the same thing with a whole lot of .NET and earlier Microsoft technologies, and there’s this certain type of developer out there—and I say this with no condemnation, and I’m not trying to sound pejorative at all—but there's a subset of folks for whom this is not a passion or part of their core identity.
It's a job similarly to the way that an awful lot of accountants don't go to accounting conferences, or hang out on accounting backchannel Slack rooms. They show up, they do their job, and then they tend to go home and live their lives. And there is absolutely nothing wrong with that approach. And Microsoft has been phenomenal at addressing that constituency historically. Just because we don't see the new whiz-bang startups built on this, does not mean that there is not a tremendous groundswell of Azure uptake. I do not believe that Azure is not in second place, as most analysts tend to say that they are. I think that their cloud numbers are largely real. I think that there's a tremendous groundswell of enterprise support for this, but enterprises hate anything that remotely looks like publicity, particularly around something that carries perceived risk.
Dwayne: That's exactly right. When the JEDI announcement came down, the Pentagon selection, I recall on Twitter, there was a lot of outcry from Amazonians who said, “Well, this could not possibly have been driven by technical excellence, but it was entirely political.” And I have to say, as a person who has enjoyed and built things on both platforms, I found that to be a little bit astounding, because can you admit that there is competition? But also, it was very clear to to me that the [00:24:02 hyper division]—Azure Stack, which we haven't talked about, but I think Jeffrey Snover’s work and others’ work on that has been really quite strong—and the compliance and security model, if I was the person in the Pentagon, looking at public cloud, Azure would make a lot of sense to me, because here I have Azure Stack, and so I can have isolated Azure, that is entirely secure; it can be off the grid; it can phone home when necessary. It can be in remote places, like bases and so forth.
Or the classic example that Microsoft gives, which is the cruise ship. And then I have Azure, which I have all of these tools available to me to track, to control, to monitor, to know exactly what's going on. Now, that doesn't mean that these tools are effectively used all the time, but they're all there. And so this cornucopia of command and control tooling, which is well designed, probably built upon—not probably—definitely built upon what Microsoft learned from on-premises Active Directory, and LDAP over the years. Getting that wrong, getting increasingly right with each iteration, and then finally, sort of, migrating that to the Cloud, and then making mistakes and learning.
Those are all extremely compelling, and that's why I think that the audience for Azure, I'm just trying to find the words to say this without coming off as a jerk, but the audience for Azure, I think, tends to be people who are more concerned about foundational operational things than the very, very flashy things. Which is not to say that you can't do these things on Amazon. Of course you can. But I think the audience, I think that the mind space or the attraction, I would say, to Azure is very clearly for people who say, “I have these problems. I'm an enterprise. I want to take advantage of Cloud, but I need to be secure. I need to be compliant. What's the best platform for that? I've looked around and I think Azure is it.” It's not a mystery to me why organizations would be choosing the platform for those things.
Corey: Yeah, and I think that that tends to be a very different story than one that we've been seeing specifically. That brings us to another topic I wanted to discuss with you. Let's talk about cost. What does that look like in the world of Azure? How do you wind up handling cost prediction, cost allocation, what does negotiating these deals with Microsoft look like?
Dwayne: So, there's a couple of elements to cost with Azure. There is, of course, the classic negotiation with Microsoft. And that is an area that I have more experience with than I care to admit, having worked with enterprises to help them do that. But once you get past that particular hurdle—because it's not as complicated today as it was in years past. I mean, it still can be complicated, but it's not as nuts as it was in years past with the licensing, and so forth. Microsoft has done a lot to simplify that. It still just comes down to consumption. And yes, there's reservations and all these things, similar to Amazon and, I believe, GCP as well, but it just comes down to consumption and control. So, on Azure, you have the classic problem that you have on all cloud platforms, which is what people are able to deploy, and they have to deploy solutions. They do so. And they do so sometimes—especially when they're really cooking with wild abandon, and they're not turning things off—it's all the problems you have on all the cloud platforms. They're over-specing virtual machines, or they're choosing virtual machines instead of choosing platform services. They're doing things that are generating a lot of cost that could be avoided. And so the thing that I think Microsoft has offered customers that sets them apart from their competition in this area—and I've actually written a book about this—
Corey: And we'll throw a link to that in the [00:27:53 show notes].
Dwayne:—thank you—is the Azure cost management and cost analysis tooling.
Corey: Now, before we begin to continue down that, did that grow organically, or was that what they did when they acquired Dyne, or DYN or Dyn, or whatever the hell they call it?
Dwayne: Yes, Cloudyn. Cloudyn. Yeah—
Corey: Cloudyn. That’s right. CloudDYN, CloudDYNE. Cloud… something.
Dwayne: Yeah. Which, as I recall, was an Israeli firm, which had a really good story to tell; really strong product. So, the cost management platform existed prior to that, but I think it really became much better once they built the Cloudyn code base into what they were offering, and I think they've also enhanced it by leveraging Power BI because they're definitely eating their own dog food as the saying goes. And what that gives you the ability to do, which is similar to Cost Explorer on AWS, but in my experience, looking at the two, it's a bit more logical and a bit better organized. It still lacks a few things that are business sensitive, but it does give you a tremendous amount of data.
Your metrics, where the cost is coming from, and so forth. Tagging is key, obviously. A lot of organizations are not doing that properly. But what it gives you on the Azure portal is a really lovely business intelligence interface that at a glance can tell you exactly where your costs are coming from. And it builds upon some of the compliance and the management tooling that I talked about earlier, like Azure Management groups, which is an organizational container for your subscriptions and resources that are contained within subscriptions. You can point cost analysis towards aggregated resources if they're properly tagged. And particularly, you can get very, very granular data about where your spend is coming from, and you can create views at the portal for say, the finance officer who can then log into the portal, and get his or her view of what's going on.
There's ways of enhancing still further. You can use the Consumption API to get that data in a way that maybe is more to your liking or more to your needs than the reports that are available from the portal, but the fact that Microsoft has even thought about this, I think is rather impressive because what I'm seeing is that a lot of organizations are not thinking about cost, or rather, they are thinking about cost, but they're not sure what to do about it. And they're not aware of the linkage between architecture and cost. They're not aware or rather, they're not taking advantage of tagging. They're not doing a whole bunch of things that you can do—not using budgets.
There's a lot of things that they're not doing, and I think that it's providing fodder for some of the people who are still trying to sell you boxes on-premises because they're saying, “Oh, my God, your cloud bill is so high, and there's nothing you can do about it.” I'm always frustrated whenever you can article, like, on LinkedIn, or some other place in the tech press. Someone saying we repatriated our stuff from the Cloud, because the cost was too high, and no one ever digs into a couple of things like, well, was the spend generating revenue, and what's the tie to that? But also, what did this company do to try to get a whole other spend that they simply built, as I've seen, like, “Hey, wait, we have 3000 VMs on-premises. Let's build 3000 VMs in Azure.” And, “Oh my god, [laughs], the cost is crazy.” Like, well, yeah. It certainly can be a problem if you didn't refactor to the greatest extent possible, even after you lifted and shifted.
So, I think that as in other areas, what Azure is offering to customers is what I'm going to call a business-friendly way to get an understanding of where your costs are coming from. And even though the recommendation engine, which is a bit of ML—machine learning—some recommendations right there in the portal, about how you can save some money. They’re not always good, because it's an algorithm, obviously, but at least there's a kind of, an understanding of what your patterns are and how you can save money. And this is another area in which I think that, as I said, I think Microsoft is doing a very good job of talking to the business audience; they're talking to developers; they’re talking to infrastructure people, but they're also talking to the business audience, and it's that third part of a tripod, I think that is missing, often, from their competitors is that there’s those conversations with business people as to what the business actually needs and how the technology can help.
Corey: I think that's something that gets lost quite easily when you see engineers talking about cost. I belabored that point to death on this podcast before, to the point where it's not necessarily worth revisiting. But I think you're right. There's a very strong story here around Microsoft, specifically, having a much more mature view of how—I don't want to say legacy companies because that's unfair—but historical companies who have existing and exhaustive physical estates and enormous investments in how they do things that you don't see in a company that didn't exist 20 years ago. That is actually one of their strongest assets, and I think it's easy to dismiss that unfairly.
Dwayne: Yeah, I think that does happen. And what I think is happening amongst partisans for cloud providers is I think we're talking past each other because, I mean, as I say to my colleagues, what is this technology for? What is it for? It's not for you to do cool stuff. It’s to get something done. And that something done might be cool. It might be landing a probe on Mars. That's very cool. Or it might be helping your grandmother get something that she needs. I mean, that's also very cool, and also very necessary. There's a million other things that the world needs that technology should be helping us achieve.
And so, your code could be sweet and all that could be good, but if you're not accomplishing anything with it, what's the point? And I think Microsoft today—in the past, I think there was some stumbling and some problems—but under—certainly under Nadella, I think that Microsoft understands how to have that conversation with their customers. And they keep building things that make it very easy for me to advocate for the platform because I'm not advocating for a platform that you can't use to solve your actual existing problems. It doesn't mean it's perfect, it doesn't mean that I don't get frustrated. It doesn't mean that some things are not in preview for way too long, and I'm like, “It's been a year. Why is this still in preview?” It doesn't mean that you don't encounter problems when you try to deploy stuff. But it does mean that you know what the direction is. And the direction is to help you get stuff done. And I think that's very compelling.
And that's why I think some of these enterprises that I've worked with tend to be large scale organizations that are building things themselves. And they're not keen on showing off a technology. They're keen on getting things done, and they've made their decision about what platform will best help them do that. Although there is a multi-cloud story as well in which you're using not multiple platforms for the same application, but different platforms for different things, which I think we've seen a bit of that as well.
Corey: I think that's probably a good place to leave it. It winds up being a convoluted complex story, and I don't think that migrating to any cloud provider from any other cloud provider is going to materially change the complexity of the billing problem. This is a systemic problem. It is not a provider problem, for better or worse.
Dwayne: That's exactly right. That’s exactly right. Yeah, I 100 percent agree with that, but it's also—speaking to my fellow techies out there—it's also a perceptual problem. When you design something, cost should be on your mind. In the Azure case, there’s a pricing calculator; there's all these tools available to you; there's the API. You can say to your organization, “I have architected the following solution. And I can provide an estimate of how this design costs versus that design,” always keeping foremost in mind what the goal is.
So, one of the things that frustrates me is when your organization is surprised by their bills, because I'm like, well, you could have predicted that if you were paying attention, and it's now kind of everybody's job to pay attention. I mean, to return to Amazon for a moment, the CCOE—which I think is an Amazon creation, the Cloud Center of Excellence—I think that idea is fantastic. I think it should be implemented. I think one of the things that a CCOE would do for organizations is help keep everybody's mind focused on what you want to do and how much it’s going to cost, and also whether or not it helps you achieve your goals. And if you spent 100 million, but you made a billion because of that, then okay, that's fine, but if you spent 100 million and you're not making 100 million because of that infrastructure spend, then you've got a problem.
And you as a technologist should be able to predict—if not what the eventual product will make, at least what the runtime costs of the thing that you're proposing is, and also monitor and remediate. That's one of the beauties of the Cloud. You can change, you can change your architecture if you do things correctly. So, yeah, if anything, I would say to my colleagues, billing is not boring. It's a signal of what you're doing, and it's a signal to you to do it better.
Corey: I think that's probably one of the most astute things that we've heard today. Do things better. But it tends to be one of those simple bits of advice that people don't tend to take nearly seriously enough. Dwayne, thank you so much for taking the time to speak with me today. If people want to hear more about what you have to say, where can they find you?
Dwayne: So, I'm on Twitter. Twitter at @cloudquistador. And also I'm on LinkedIn. I'm Roberto Dwayne Monroe. That's my middle name comes first, and find me there. And I also have a blog that I have to revitalize called The Azure Cmdlet Project in which I talk about things Azure.
Corey: Excellent. Thank you very much for taking the time to speak with me today. I appreciate it. Dwayne Monroe, Senior Cloud Architect at Cloudreach. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. If you've hated this podcast, please leave a five-star review in Apple Podcasts and a comment explaining your reasoning in triplicate for our procurement department’s consideration.
Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com, or wherever fine snark is sold.
This has been a HumblePod production. Stay humble.