Our thoughts on the future of digital innovation and the cloud.
Azure for the Win Transcript
The topic of this podcast is Common Mistakes when Moving To the Cloud (Cloud Migration).
Intro: Hi, and welcome to Azure for the Win, the mostly Azure focused cloud podcast brought to you by Invero. We like to sit back on a Friday, relax, grab a drink, and talk some cloud.
Marc: Alright, welcome. It’s another Friday afternoon. We’re here with the Invero crew. We have your moderator. Mark Wil – Mark Wilson, myself, I’m stumbling over my own name, and then we have our 2 founders and Partners of the organization, we have Craig Slack.
Craig: Hello
Marc: And we have John Dobson
John: Hello
Marc: And we are jumping in for the Azure for the Win Friday podcast. So, we’ll do today’s topic then we’ll pour ourselves a Scotch we’ll get started so today’s topic is “Common mistakes when moving to the cloud.” So, pretty light, but also tremendous amount of content available to us ’cause there’s always a lot of mistakes when taking on a challenge that’s as technical as this. So, we’ll see how well Craig and John can do with getting in all the points that they want in a timely manner, and I’ll do my best to wrangle them in when I think it’s necessary. But it might be, might be a little tough ’cause it’s subject I know they love.
Alright, before we get started, Craig I believe that you have a new bottle of Scotch for us today. What do we got?
Craig: Yeah, I think our listeners are going to realize that I have an affinity for the Speyside region ’cause this is another Speyside. I like how smooth they are. Although I do like some slightly peated scotches, but this one very smooth. It’s 13-year-old, and another reason why I selected is the name. Obviously, my name being Craig, and it’s Craigellachie, is the name of the Scotch. Very nice. I think you can decide for yourself and I think it would just be Mark and I partaking but John what are you drinking today?
John: Oh, Rye and Ginger. Oh, Rye and 7-up, sorry.
All: cheers, cheers.
Marc: My favorite part about a Friday. Alright, so, I do have some questions at all kind of diverge from the simplest of the main question coming up, but I guess this is the first part. I mean pick your weapon guys, how about it What are the common mistakes of moving to the cloud? John, why don’t we start with you? I saw the big smile on your face. I saw the list that you wrote up on the board, it was so many of them, I was like, ‘oh!’
Craig: And of course, we’ll preface this that we’ve never made any of these mistakes, ever.
Marc: No, no, of course not.
John: So, there’s lots of mistakes and some of them are general rules, other ones are more specific, but a lot of them are misconceptions. So, number one, I think, in order, is that I’m going to save some money. Meaning that the cloud is going to be cheaper and in certain instances it can be cheaper, instances where you’ve moved workload loads from on premises to the cloud and you turn them off at night. Maybe there cheaper that way, than running it on premises. But overall, the cloud isn’t necessarily going to save you money. It is going to increase your ability to enhance your configuration. And when you have an IT Department that can enhance their configuration what you get is an agile group that can actually adapt to business needs.
Marc: Agile group that can adapt to business needs.
John: So, in other words, if the business says, hey, we need to turn on a server because we’re doing something you can turn it on quickly within the cloud. A lot quicker than you can do it on premises. But there’s a money implication there, so it’s not going to, across the board, save you money.
Craig: Yeah, I actually, we touched on this briefly in a previous podcast where we believe that the cost savings is not necessarily, it’s a misnomer, but it’s more about what value, added value, you’re going to get from the cloud. The cloud gives you, like you said, agility or whatever you want to call it, whatever buzzword, but it is a different way of thinking. You may be spending the same amount of money, but you’re getting way more for those dollars.
John: Way more. Way more. Way more value, that’s the key. So, you get better value than the server sitting on premises. The next one is, that moving to the cloud is going to make it easier to manage. That is right, and wrong at the same time. It is wrong, because to think that OK, I already have a skillset that’s focused towards on premises systems, that is going to be directly transferable and I’m going to be managing everything for a web page. Yes, and no you are going to be doing a lot of management for web page on configuration items, but you still have the concepts, or the constructs, of servers that you still have to RDP into it, still do your regular IaaS-style configuration changes or otherwise. But it’s not necessarily going to be easier to manage.
Craig: It’s actually, I think, more complicated -sorry – because there’s much more risk if you do it wrong. You’ve got some safety in your own on-Prem environment being behind a firewall that you control, and you can lock down what’s coming in and out. In the cloud, you give somebody permissions to create a resource. They could spin up that resource in V-net that is now suddenly exposed to the outside world that maybe they didn’t mean to, right? So the ease of management is another misnomer, but it’s also, there’s ways, yes, you can do it through a portal, you can do with scripting or whatever, but there’s a lot more complexities that didn’t exist on prem.
John: Right, right. So, we’ve all been in IT for a while, we’ve all had to learn new skill sets. When you learn the infrastructure as code skill set, and when the skill set is allowed to, you know, when you’re going to actually deploy it, that’s when it will get easier to manage, but it’s a hurdle everyone has to overcome.
Marc: So, I want to cut you guys off a little bit because I think, and you kind of mentioned this, but I think that you’re diverging. You’re going into misconceptions, not necessarily mistake.
Craig: Ah, you’re keeping us honest.
Marc: I want to hear about mistakes, not misconceptions.
Craig: Mistakes, OK. I’ll throw one in then. Well, one that from actually even before we started BSS, one of the things we saw a customer do which was – anyway, I’ll explain it. So, the customer was committed,
they’re going to the cloud. In this case, I think it was AWS, doesn’t really matter. They knew how to manage their VMs on prem, they were good at doing that. They had a SharePoint environment running on prem, exchange environment running on prem. They did a lift and shift of those to cloud into IaaS VMs. And you might think, I don’t see anything wrong with that. But here’s the problem. Their SharePoint is a SaaS service through Office 365. Exchange, email, as a SaaS service through Office 365. But now you’ve moved your VMs, great you’ve got the same service, you got, you’re running in the cloud. But you still have somebody that has to manage that VM you have to patch that VM you have to back it up.
John: It’s more expensive, in the long run.
Craig: It ends up being much more expensive. There’s opportunity costs that people, that a lot of IT departments overlook, that if you move that to a SaaS service, now you no longer have to worry about exchange backups. Like, for my entire career I’ve done, I think, half a dozen at least, exchange upgrades from like Exchange 55 all the way to whatever it was, 2008, I think was the last one.
John: And where’d it get you?
Craig: No, and then you’re always moving mailbox, your databases are getting full, your transaction logs get full or fill up your disk. All those sort of things that are headaches are, they adding value to the company at the end of the day? No. What’s the service that the company wants? They want their email. They want Outlook to work, they want their email – when they send it it’s going to get out to the outside world.
That’s the service they want. They don’t want to know that, oh well, we’ve got somebody who is perfect at managing this exchange environment, and they know that very inside it out. That’s not a valuable task so the mistake that I’m saying is, when there’s alternatives from a PaaS or SaaS perspective available, don’t just do what you’ve always done, which is loading up services on virtual machines, in the cloud or on prem, is going to be the same if there’s alternatives they should be considered.
John: Right, so the rule is, the general rule of thumb is, move it to SaaS first if possible. Those are your best managing, as you just said. PaaS next because again someone else is managing the majority of it, you’re just using the features and IaaS last, but everyone a common misconception is to just move your IaaS from on premises to the cloud. And those two examples highlight it, but people do it with regular application servers. People do it with something as simple as a print server.
Marc: Though, that’s definitely the majority of what I’ve seen so far is IaaS where people are just picking up their VMs and dropping them in the cloud and then, see ya later.
John: Instead of refactoring.
Craig: But you know you can’t fault people who don’t have experience with the cloud. They’re doing what they know, they don’t have to retool, they probably got scripts already to run against their virtual machines.
John: And they gain the backup and they gain, technically, some form of high availability that they could not
have achieved on premises, meaning that they can back it up and restore it to a different region if required if their V-Nets and their network are set up the right way. So they would be able to do all of those things.
Craig: Yeah, IaaS is – we’re not saying IaaS is not something to do, just if there is an alternative, consider it, and there are valid reasons why even when there is an alternative, you still want to go IaaS.
John: And I’ve done a load of migrations before an if you’re migrating something, you’re either going to do two moves. One move is IaaS on prem to IaaS cloud, and then, IaaS cloud to PaaS, or just make the shortcut and go right to PaaS if you can.
Craig: Short circuit it, yeah.
Marc: I can understand why the two-move scenario happens so often, because I think that people probably have a few different goals and they grasp at the low hanging fruit. Low hanging fruit being, okay, goal one: I want to get rid of my physical server, because I’m gonna have to buy a new rack, and it’s going to cost me $60,000 and I don’t want to have to do that. So I want to get rid of the iron as I’ve heard Craig call it a few times, so I kind of like that, so I want to get rid of the iron, and then I want to baby step into the cloud, and knowing
that I can then look at PaaS later on. I’m not necessarily saying that’s the right way to go. I know that you said a couple times now that it’s not necessarily bad, but I guess I can understand why they go that way.
John: Yeah. It’s a luxury if you can avoid it, avoid it. If not, go that way. ‘Cause you’ll understand it better and –
Craig: Just get out of your comfort zone and be open to new ways of doing things, ’cause that’s what the cloud is all about, is a paradigm shift. Do things differently because you have the opportunity to do so.
John: Yeah. And actually it’s a good point to bring up right now, is that some of these other features, beyond IaaS, PaaS and SaaS, aren’t as mature, Exchange and SharePoint are more mature or just as mature as IaaS used to be in that space. But some services are not, so we’ve come across customers that are like, “we have to go IaaS in the cloud with our system because it’s just so customized, and to make it configurable into PaaS is going to be a big change for us,” but they still want to benefit from it, so that’s there’s nothing wrong with doing that.
Craig: Yeah, that is true. SQL is a good example. There’s PasS offerings for SQL, but is not compatible with all scenarios, so –
John: Correct.
Craig: Especially the PaaS SQL, the managed, instances SQL managed instances on Azure, are much more compatible. But there are still some limitations, usually around performance, but yeah. It’s, yeah.
Marc: Okay. I don’t know if I want to go to the next question, but I think I’m going to because we talked about a few mistakes, and I think that we can cover more mistakes in my next question. So, my next question is basically I think that if, if you, in any business, and anyone that’s been involved in doing any kind of technological transformation with an organization, you have read many lists online of “The Top 5 Mistakes” when I’m doing this, “The Top 5 Mistakes” when I’m doing that. I think that a lot of people, especially in, recently, in deploying SaaS systems, and it almost seems like it doesn’t matter what area of the business you’re in, you’ve been involved in a SaaS deployment at some point in your career. And so, if you Google right now, like, “5 Common Mistakes when deploying a new SaaS System,” you’re going to find 1000 different results, right? So, there’s a lot of common mistakes that people know about now that historically have been things that they didn’t know about, but now they’ve gone through that experience. Then, okay, proper planning, building a proper full-fledged set of requirements. Building out an appropriate timeline, things like that that I’m relating to a SaaS deployment. There’s a lot of other different technological transformations that have occurred over the, however long you want to go back, that common mistakes have been somewhat related to those other areas.
I don’t feel like I’m explaining this well, but what is what is different about moving to the cloud? What are common mistakes that you couldn’t lump together, that wouldn’t apply, to things that people have historical experience with. What is something that’s a bit of a bit of a game changer, a bit of curveball, that people couldn’t think well, I’ve been through lots of digital transformations over the course of my career. I can probably figure this out, so what’s going to hit them as a mistake that they didn’t think about?
Craig: I think putting controls in place to prevent sprawl because, not just cost controls to prevent sprawl, ‘cause in an unconstrained on prem environment, where you’ve got, you’re constrained by your physical – sorry. On prem is constrained by your physical, you can over-provision, so you can go over allocate your memory, CPU, all that stuff, and at some point you’re going to hit a threshold where, okay, where everything is colliding on itself. Problem with the cloud, which is also not a problem, it’s a positive, is that it’s unconstrained. There’s infinite capacity, they so the point is, putting those controls in place so that you can actually ensure that sprawl does not happen, or is controlled, like you can still sprawl, but you at least have some management around –
John: Notification in particular
Craig: Yeah. Because it’s easy, and we see it all the time, to create resources and forget to delete them later. Or or you delete them, but you leave little bits and pieces around, like, you delete a VM, maybe you didn’t delete the NIC, it didn’t delete the discs. Yeah, so being ever vigilant about ensuring that what’s there is actually being used, ’cause you’re going to pay for it if it’s not.
John: Yep, agreed. And you’ll just accumulate that as technical debt over time. So, I think the other thing is the security planning. That’s another thing that’s just not well thought out so, because it’s a new environment to a lot of people, they just open the access, and they’ve been diligent with the on premises world by saying “I’m going to really lock this down, I’m going to give administrators admin accounts that are disconnected from their email,” which is a good security practice. But in a cloud environment, “I’m just gonna make everyone an owner,” and everyone can go in and do whatever they want, create the sprawl, create the — and it’s — there’s no safeguards in place. When you have a situation like that, you actually put your business at risk because your business has to pay for these cloud services out of profit, and they’re not able to, or, pardon me, they have to actually generate revenue to generate that profit, so there’s a financial, you know, they’re just not financially aware of the implications of this unlimited sprawl.
So a classic example is someone, “Oh, I want to create a new environment, I’m just going to create it,” and then go on to the next thing and they forget the other environment’s running. Or, they’ve got two environments running, and then they create a third environment, and again, never going back. That person leaves the organization, and if you have an estimated 20% year-over-year turnover as an industry average. People are
going to forget about that. The company is going to continue paying for it. And it’s forever.
So Microsoft’s in a great business with regards to that because they’re collecting all the technical debt out there that was traditionally left and capped on premises, and they’re just, people are doing, just about every single customer that you go into his got a storage account, a disk, something laying around that doesn’t have to be there.
Marc: And it’s just racking up costs month over month.
John: Correct.
Craig: So, a good example of that is, say your company makes 5% net profit off of every dollar that it earns, right? So, say somebody makes a mistake that’s a 5 thousand-dollar mistake, one month. How much do you think – this is a math test for you guys – how much do you think the company needed to actually earn – these are easy numbers –
John: It’s 20 times….on how much mistake was it?
Craig: A $5000 mistake, so they turned on a VM or did something that cost $5000.
Craig: For our listeners somebody made a $5000 mistake. How much revenue did that company need to earn to cover that cost?
John: One-hundred K.
Craig: Yeah.
Marc: (Laughs) I didn’t even finish it. I wanted to crack at it. Okay.
John: Oh, okay.
Craig: So, I was using simple numbers.
Marc: Because you’re saying, because –
Craig: So, a company has 5% net profit margin. So, 5% from every dollar they make goes to the bottom line.
Marc: Right. Profit on top – okay, I understand.
Craig: So now you have increased your cost your expenses by $5000.
John: You have to increase sales by $100,000 just pay for that mistake. Some of these environments can literally kill a company.
Craig: Yeah, so a $20,000 mistake, they had to make $400,000 revenue just to cover, just to pay for that. So, put that into perspective, that’s what we like to think of is how, in terms of all these mistakes, it’s a business mistake. IT typically being a cost center is like, okay, we’re given this budget, we’ll go and spend it.
Marc: I feel like there’s a really good one-pager in there for governance in what you’re describing, like, that we could kind of put together to articulate the impact of these things. I wasn’t sure, and I feel like I didn’t articulate the question well, but I wasn’t sure if you guys were going to be able to give me an example that I felt was actually going to be different, and that this is a good one because when you look at controls, putting those controls in place, I think historically, even when you even when you were allowing people to have heavy control over systems that could significantly impact your business, and it wasn’t necessarily cost impacting. So, for example, Salesforce. I’ve been in situations where people have said, well, I’ve requested “you know, I want admin access to everything, because I want to be able to tinker. It’s been given to me and that’s been great; you go ahead and do whatever you want. But you can’t buy licenses. You’re not going to all of a sudden have a surprise invoice on any SaaS system out there because you gave somebody you know full admin rights to go ahead and interact with the program. There’s a check and balance there with the purchasing, and I think that when you’re looking at cloud architecture, when you give somebody full access, their tinkering has direct cost impact and then I think of that something I could see that being a mistake that people wouldn’t –
John: Right. So, the way to avoid that is to set up a budget, the same way you would in a financial plan or in business. Set up a budget, enforce groups who have the ability to create sprawl or to create anything. Set up a budget and put it on in Azure. Dedicate that number and negotiate that number with them and have finance know about it as well. When they had the capacity of it, you can either keep the service is running or turn them off and tell finance that they have to tell them.
Marc: So, that was going to be a question that I had is, is there functionality available in Azure that would allow you…
John: There is through a process that we’ve developed but it’s a customized process that’s part technical or part automation, part manual. But it involves, I actually want to call it past the hot potato. I don’t know if you remember that game when you were a kid. I think it’s when the music stops, who’s holding the hot potato. And what happens is, we all declare, it’s a check and balance system, we all declare “that I need to use $100 in Azure every month.” And when I approach 90%, I’ll get an email saying it’s gonna – hey, you’re at 90%. That’s only halfway through the month. I know I’m going to over consume because my guys have over consumed the cost what I’m going to be able to do is tell you that. If you don’t tell finance, it will cap out at the exact amount. You have to go back and tell finance, “Hey, we need another $50,000.” But the onus is on you the owner not on me.
Or the administrator.
That’s what we’ve got to do. IT has to arm themselves to be prepared to say, to justify, the month over month increases that businesses will naturally incur. And that’s the only way you can do it. And they’ve never had to do that before because of capacity in on prem.
Craig: Well, and because you’re buying in chunks so you’re buying capacity. You get approval go and spend $100,000 on Saan or server or whatever. That’s your approval. Now you can fill that up in 6 months or a year,
2 years, whatever but that’s now, there’s your constraint. you’re not like Oh, well, just add another couple of discs, nobody will notice right?
John: Yeah.
Craig: You have to go through business case. You have to get sign off, procurement has to order it or whatever.
John: Correct.
Craig: The cloud changes that significantly. Public cloud.
John: Significantly, and I’ll give you another case. If you have a project and it’s a customized project and you’ve got a code pipeline. If you fork that code to a different environment and you’re testing it in a different environment, you’ve doubled your cost of your environment. And forking happens all the time, sorry to say.
Marc: Forking happens all the time. That’s my new, that’s my tagline for this podcast.
Craig: You’re learning – every podcast you learn something new. Is that a word you didn’t know?
Marc: I don’t know if I really learn, I mean, I guess, I suppose. I wouldn’t have ever really thought of forking as a term. I understand what you said. I think I learned, yeah, I suppose there, you go. There’s my tidbit of knowledge for the week, is forking.
John: I love forking.
Craig: I’m all for forking.
Marc: I think the governance – this is another example of talking about the importance of governance because, you can’t rely on the cloud providers to be your buddy and your pal to protect you from –
John: Yourself.
Marc: Shooting yourself in the foot, yeah. And the same way that like, Virgin mobile, or whom I shouldn’t be name dropping my cell phone provider, or Bell or whoever it is, you know, Time Warner, whatever. When you’re heading over your data limits, they don’t care. They might notify you, but they’re not going to stop you from keeping on going.
John: Correct, so you have to have the self governance to be able to do that. And IT groups don’t do that today.
Marc: So, in relation to the concept of the importance of governance is the importance of consultants and
cloud partners like ourselves.
That brings us to our next and second final question. OK, so. This is going to relate to us. So, what common mistakes do companies like Invero, and I know there’s no other company really like BSS. The other cloud strategy and consulting partners like us what are mistakes that we make. What are mistakes that your partner, as an organization you’re partnering with a company that’s helping you to, maybe to transition to the cloud, or helping you to manage or govern your cloud infrastructure and tenant. What are mistakes that companies like us commit?
Craig: I’ve got one. Not eating your own dog food, which, that expression, if somebody is not familiar with it is, practice what you preach essentially. So, you’re telling your customers “oh you should do this, you should do that.” And, you know, yes, we’re guilty of it. We’ve got a subscription that’s sponsored by Microsoft because, so we can do POCs for customers and so on. We notoriously don’t go in and clean up after ourselves, right? We’ve got stuff in there that’s, you know, should be deleted, or everybody like, “what’s that there for?”
Marc: You’re supposed to be talking about a hypothetical other company (laughs). No, I’m just kidding.
Craig: No, we, I said, we make mistakes, too we’re human. And actually, we had a meeting today, just about that, where we were talking about cost management and so on. I think the problem in that sponsored subscription is it’s unconstrained because we’re not paying for it. If we were getting the bill every month, I’d be all over it. I’d be like oh, why did it go up by ten bucks?
John: Who’s the biggest offender?
Marc: What do you mean?
Craig: I’m not going to name drop.
Marc: Are you asking biggest offenders as far as company or like roll?
John: Individual inside of BSS.
Craig: Well, the individual’s no longer here.
John: Oh. I thought it was me. Yeah. So.
Craig: No, I mean, I am the first to admit that we make mistakes, right? We are human. But we learn from those mistakes and that’s why we, we talked about it and we’re developing processes that we’re going to test on ourselves before we even bring it to customer. So, we’re working on these cost management processes, custom developed applications we’re building.
John: I think something we do better than other companies is we do estimation better. We have an entire document.
Marc: We talk towards that in the second.
John: Yeah, template that actually covers off the configuration architecture everything else, and we keep a monthly run in there, and Craig’s been able to fine tune that into the ability to get it down to about approximately about $100 in some instances. In other instances –
Craig: You’re talking about estimating consumption?
John: Estimating consumption. So, we do that quite well. Better than, I would say, other providers or other integrators. But it’s still difficult overall to estimate, so customers have to have the expectation set for them that things have to normalize. You move things up, and it normalizes. Integrators have to use the language to say it’s just an estimate.
Marc: Something that is kind of in some, it’s caused a lot of emotions for me, actually, In some ways it’s kind of frightened me, in other ways, it’s exciting in other ways. It’s kind of enlightening, but in some of the discussions that I’ve been involved in a recently. Two in particular, one related to a migration that, John, you haven’t really been too hands-on with but then also one that you and I have been talking about with the company that’s looking at a potential solution to some of their data needs, is that there are so many ways to skin a cat. There are so many ways to get to the conclusion that it’s like, even if you’re doing like a simple migration, you know, an IaaS migration, there’s still multiple ways. So, I’m looking at our own team. Internally, having debates, saying, “hey, you know what? We should do it this way for these benefits,” and the other person saying, “you know, we do it this way for these benefits,” and hopefully we can meet in the middle. But I think that from my perspective coming in on this pretty fresh I can see how companies might — there’s a few different mistakes that companies like BSS could make.
John: Oh yeah
Marc: One is, too many cooks in the kitchen.
John: Yes.
Marc: The other is, not enough because if you have one person that’s very singular minded and doesn’t get another input on something, they could be going the wrong direction and not even know it. I have no idea how many ways, how many different solutions you could with in order to solve the same problem.
John: Agreed, and that’s why you’ve got to kind of vet everything. You’ve got to go back to the provider’s culture and make sure that every voice is heard because there’s always a guy in the back, saying, “hey, you should have done it like this, you should do it like that,” and because they’re not a senior, they’re not heard. We’re not that kind of culture. We listen to everyone’s voice and on top of it we want to give the customer multiple options on how to do, on how to solve the problem that we’re trying to solve. So, I agree with that. That’s an age-old problem that’s not reserved for cloud.
Craig: Well, and I would actually take that a step further and say that. Us, we are technologists, right? So, people and companies like ourselves come at it from a technology mindset, and they’re trying to throw technical solutions at whatever problem it is. And that, I think, is a common mistake and is a bad mistake to make. We take more of the business approach: What is the business problem we’re trying to solve? So the example of the customer you just referred to, and I don’t want to get into too many details, ‘cause we don’t want to give anything away in terms of who they might be –
John: Customer privacy.
Craig: Yes, but they came to us with a specific solution in mind, and we challenged them. We said, “what are, –” and the solution wasn’t a fit for us technically, right? So, it didn’t actually fit within our standard service offerings. But, so, we sat down with them and listened to, okay, what are they trying to achieve? And from a business standpoint we understood what their end goal was. And then we were able to provide a solution that didn’t match what they came to us for originally but they actually, they bought into. They’re like, “wow, that’s exactly what we need.” So, to me that is the common mistake is, throwing technical solutions at problems without understanding what the business challenge is that you’re trying to solve, because the business, as we’ve talked about before, they’re the ones who are paying for all this. You know that $100,000 in revenue that you need to earn to pay that $5000 mistake, that’s coming from the business. The business is selling $100,000 of
product to pay for what IT is doing at that bottom end, right?
Marc: One thing I like that that I’ve seen that we do as a company is, we do provide different options, but we do take a hard stance of what we think is the better option, and we provide our feedback and the backup data to be able to stand behind the option that we recommend. Because one thing, you want to you want to let your client know that there are other options available, but you don’t want to just say, “Hey, here’s all the different ways you can do it. Let us know what you want to do, and we’ll do it for you.” Because then all you’re, you’re essentially just doing whatever –
John: Catering to them to get their business.
Marc: Exactly.
John: And no one is an expert across all clouds, and no business necessarily, and it’s a common misconception to have a multi cloud strategy across the board. If, they think that if Amazon is going to over charge them, or Amazon has an outage, I’m just going to flip all my stuff to Azure. Doesn’t work that way.
Craig: So, that, we’re back into common mistakes. Yeah. That what the theme of the theme of the podcast is, common mistakes that people make. Large enterprises are particularly –
John: Susceptible.
Craig: Guilty of this, susceptible of it, because they don’t want to be locked into any one vendor. They’re concerned that if they are locked in, they have no negotiation power on price. They lose that strength, and you know, they also don’t want to, from a technical standpoint be tied to one vendor over another. So, Azure is stronger in the Microsoft Stack, whereas AWS might be stronger in the open source, which is not necessarily true. Azure is pretty strong –
John: Every one of those points as a counter to it. They’re already locked into Microsoft majority of times. Microsoft and Amazon counter each other to keep the prices low.
Craig: Bang on, yeah. Well, it’s competition. If there weren’t three big vendors, unless they’re colluding, which I don’t think that would be possible, it’s not impossible, but –
John: The United States government wouldn’t allow it.
Craig: Yeah, well. They tried to break up Microsoft years ago. That’s a whole nother podcast. But it’s the law of competition that they’re going to go, the price will go down to the marginal cost, so the marginal cost to produce, say, let’s take storage. To deploy another TB of storage, that’s what the cost is going to be to sell it, because that, from a competitive standpoint, when it’s a competitive marketplace, which public cloud is very competitive right now. If Microsoft lowers their price, Amazon is going to match, GCP is going to match.
John: And they’ve historically empirically proven that they’ve been doing that. I remember in storage on prem was $1,000,000 a TB, and now it’s $25 in the cloud.
Craig: I bought my first gigabyte hard drive, that was a full-height scuzzy drive, GB sounds like nothing, right? It was a full-height, scuzzy drive, $1000. Was a dollar a megabyte.
Marc: Wow. Well, there’s the classic image of Bill Gates. He’s in a harness and he’s up, somebody pulled him up into a tree and he’s standing beside a stack of paper that’s four stories tall or whatever, and he’s holding a disk and it is supposed to have shown you like, oh this amount of data displayed by paper, can fit in this disk. And then also they also paired with a quote, and I’m going to butcher the quotes, ‘cause I don’t know exactly what it was, but Bill Gates is something along the lines of like, “no individual ever need more than 256 kilobytes of data.”
Craig: No, 640K will be enough, is the quote, because that’s the memory size, and so Windows, so it was for DOS, but then Windows 3.1 actually was constrained for a long time y that memory limitation. They actually, that’s why the Pagefile got created.
John: It’s stated memory 384 K was to get you to, um, one MG.
Craig: Yeah, it was crazy.
Marc: I’ll never forget when I bought my first iPod and I thought you know, I don’t remember how many gigs it was, but it was like blah blah, I could never fill this up. Never in my lifetime and I, sure as hell, I did.
Craig: Well, that’s a whole nother topic ‘cause storage is increasing now with IoT, and all these devices that are producing data at unheard of rates. There’s, I can’t remember how many, zettabytes, is the term now. This is, a zettabyte bite is 1000 petabytes. And a petabyte is a thousand terabytes, I think. So –
Marc: It’s hard to even comprehend it.
Craig: Yeah. And so, by, in the next 5 years, there’s going to be how many Zettabyte bytes of data, and now companies are having to choose between keeping that data versus the costs of storing it versus the value, the long term value of. Anyway.
Joh: I have to ask a question that’s relevant there.
Craig: But we’re – we’ve got to stay on on topic, though, but go ahead.
John: I’m not the metric measurement? Or is that imperial?
Marc: Sorry, what?
Craig: So it’s well, I mean, bytes and bits and bytes?
Marc: Oh, that’s gotta be metric.
John: I know, it sounds like it’s metric.
Craig: It’s, no, no, it’s not. It’s binary.
Marc: Yeah, yeah, of course, ‘cause it wouldn’t either.
Craig: No, it’s binary. It’s ones and zeros.
John: Is there an empirical equivalent? Yeah, you’re right, it is binary.
Marc: No, because it wouldn’t relate to space or volume or, or, yeah, which all –
Craig: You’re welcome. (Laughter)
Marc: How do you guys tie your shoes?
John: It’s not off topic.
Marc: It’s a tie your shoe comment, I’ll (indistinguishable) I’ll get it to a different thing. A whole other whole other ballgame. Alright, so on that note. I think let’s actually wrap it up, and that’s going to get us into our bonus question.
Craig: What? Are we — we’ve got so many more things to talk about still.
Marc: Do we? We could keep going.
Craig: Okay, let’s take a look at our list here. So, did we hit all the ones that we wanted to cover off? It will be faster. That was one like –
John: People think it will be faster because Microsoft has these billion dollar, or, pardon me. More than a multibillion-dollar data centers and it’s going to be faster and the IOPS processing within the VMs may or may not be faster than on premises, but then the transferring and latency, it all comes into a factor that faster means what?
Marc: Let me ask you, let me ask this: how many companies, like how often do you think that people are taking, are taking steps to move the cloud, when they’re thinking that this is just something they have in mind. Maybe it’s common mistake. Where thinking from a purely technological standpoint, “I’m going to going to shift to the cloud for these reasons,” and that, “I’m going to get my data on Azure or AWS or whatever,” and they have zero plan for what benefits they could actually get from doing so in the long run. There’s no business value discussions.
John: So, they’re going along based on peer pressure.
Marc: Maybe it’s peer pressure.
Craig: Or technical whiz-bang, like, they’re like, oh this is next shiny object, right? I’m going to go to the cloud because I want to boost my experience with something new. Shiny object.
John: So, what are you saying? What are you asking?
Marc: I’m guess I’m asking, like, how, I would assume that a common mistake is likely most companies don’t have any plan in place. They don’t have any road map, they don’t have, like, a blueprint as we like to call it at BSS.
John: Correct.
Marc: You know, they haven’t, they aren’t looking at both short-medium-long-term, and then also those BHAG goals, the crazy pie in the sky goals, like what could we do if there was no limit on our money or our technology goals, and building that out, so that when they’re taking those first steps, that have all of those things.
John: Yeah, they need to preplan everything as much as you can. And if you can’t determine what it is, you have to ask. And it’s better to ask, because nobody knows everything that you can possibly foresee ahead of time. So, you have to ask. You have no choice.
Craig: And that’s where you need to lean on a partner that knows, right? Like, we’ve seen, this is a common mistake. It’s not actually on the whiteboard, but it’s a common mistake that companies have very smart IT departments. No doubt about that. They think, “we’re smart enough to figure this out on our own.” Okay. Yep. We run against that all the time. We try to sell them on our services, they don’t buy in. They call us 6 months later, 9 months later because they got into it, you can get an Azure subscription, get it (unclear) on your credit card get going. But then you don’t know what you don’t know. And I think that’s really the root of it. If you leverage a partner, we can short circuit all of those mistakes that we know everybody is going to make. We’ve listed some of them today.
John: Correct. And save you money.
Craig: Save you money to save you time.
John: Value, everything.
Craig: All that, yep. So, another one that we missed is around, this is specific to Azure, but companies that have existing Windows licensing that they are, they already have existing Windows or SQL, any licensing. They’re paying for on-prem, and they go to a pay as you go model or other models, even with the EA, and you don’t choose the Azure Hybrid Use benefit. So, that can save you significant dollars. And it’s very much overlooked by many, many people.
John: That’s SQL and the operating system.
Craig: SQL, every, all, well, not all Windows or Microsoft licensing, but yeah.
Marc: I think you might have covered this; I’m getting a bit of déjà vu, I think you might have talked about this in a different podcast. But, the calculators. I feel like taking the calculators at face value is a common mistake. Just plug into some information, “hey, this is what I got,” plug it in, and looking at the data, looking at the number that comes out. That’s gotta be a common mistake.
Craig: That’s a great one because if you run the calculator with what the average person thinks is apples to apples comparison of Azure, AWS, and GCP, if you run those calculators, GCP is always going to come out cheaper. And the reason is because their model is different, their pricing model bakes in discounts the
longer you have the compute turned on. So, it makes it look cheaper, but you can get those same and, in many cases, cheaper options with AWS and Azure by buying reserved instances. It’s just a different approach.
John: Yep.
Craig: Personally, I like GCPs model because if you want to leave your VM on longer, you get those discounts at different breakpoints, right? I think that’s straightforward. Buying reserved instances gets very confusing and it’s confusing to the customer. Oh my gosh.
Marc: It does get confusing. It’s confusing to me (indistinguishable).
John: We could do an entire podcast on reserved instances.
Craig: Absolutely.
Marc: ‘Cause it doesn’t, it doesn’t, the average person is mind doesn’t work that way. It works the way that you’re describing that GCP works, where you leave, the longer you leave it on, the more of a discount you’re getting, like, it just makes sense to me.
John: Exactly
Craig: Well, and the reserve instance concept, it scares people because it’s like well, I’m locked in now for a year or three years. There are options, but anyway.
John: And you gotta pay it all upfront.
Craig: Yeah.
Marc: That’s, I mean, that’s going to be a huge hit. I think in the way that companies are calculating, the way that they’re putting in their cloud spend in their books is probably a major shift.
Joh: That’s another topic.
Craig: That’s a whole podcast. And it varies from company to company, it’s not like a general rule that says okay, you can capitalize, you cannot capitalize. It varies from company to company some companies have been able to justify the thing by reserved instances. An example is CapEx. Others, they say, oh no, unless we can tie it to a physical asset or serial number, it can’t be capitalized so.
John: But that’s changing, that’s going to change.
Craig: Yeah, ah, we hope so.
Marc: But is there no, before we get to the bonus question, is there no way, I’ve heard this come up a few times, a serial number. A physical number. Can you not relate a number to…
John: It’s because of the accounting concept, it has to be related back to a piece of physical equipment that depreciates.
Craig: Yes. Yes.
Marc: I guess there’s never depreciation – ?
Craig: But there is depre – So, I’m not an accountant but, you know, you buy a reserved instance, you’re prepaying 12 months or 36 months up front. That has a useful life over that 12- or 36-month period that you can amor – you should be able to amortize that cost. That is capitalization.
John: Yeah
Craig: Anybody listening to this who is an accountant, please comment because I would love to hear your opinion, or call me directly because this is a question we get asked all the time by customers.
John: Because they can’t move to the cloud because they can’t sustain this type of cost because of their size and scale.
Craig: Yeah, or they’re a public company and now they switch from being a very CapEx heavy company to OpEx, it blows their numbers and now their share price tanks. So, nobody wants to do that, right?
Marc: This has gotta be huge in Microsoft’s periscope. They must be looking at this on their own, and thinking, I’ll think of an issue now.
Craig: But it’s not up to them. That’s the thing.
Marc: I know, but I would assume that they would assume, I, like, Microsoft proposes solutions to everything. It’s almost like they have, they come up with too many solutions to so many problems that they’re saturated with too many ways to skin a cat, to use the same phrase twice in a podcast but. I just feel like they should be
coming up with a method to say, “hey, this is how you should put this in your books.” But we can cover that in another podcast. Alright, so we’re going to wrap it up here. It’s been a good session.
Craig: We got the bonus question.
Marc: We’re getting into our bonus question. We’ll try to make this pretty quick. So, I’m going to make this, I’m going to say the question and I’m going to make a comment. So, what, we were talking about common mistakes. What’s the common mistake few people – few people? What’s a common mistake you see people, making in their everyday life? And I made a comment earlier about tying your shoes. We had this whole thing before we started the podcast, the average person is tying their shoes backwards. But that’s not that’s not the example I’m going to give. I’m going to give a different one so while I’m giving my example, John, Craig, think about it. What’s a column mistake you see people making in life? It could be a big life mistake, or it could be just a small item. The one I’m going to give is about zipper merging cars on the highway and on roads and how you zipper merge.
Craig? Zipper merge?
Marc: So, zipper merge is the concept of when there’s two lanes that need to converge into one lane, you go one car, next car –
Craig: Alternating.
Marc: One car, alternating. But, here’s the common mistake –
Craig: I’ve never heard of zipper merge. I learned a new term now! Zipper merge.
Marc: Zipper merge. But here’s the common mistake, because I feel like most people know the general idea. We’re in Canada. Everyone is really, really accommodating, you know.
Craig: Polite.
Marc: We’re very polite. So, people generally go one after the other. Here’s the common mistake: we’re too polite. Let’s say that you’re driving down the road here in the right lane, and you look, and you see construction and it’s 300 meters ahead. A lot of people in Canada, and I think this is the same for around the world to be honest with you. They think that if I drive all the way up to the very, very end and then try to cut in, then I’m an asshole, and I’m the guy trying to skip the line. So, I’m going to try to cut in now, because I want to be nice. That’s wrong, that’s a mistake, because the science shows that you are then cutting off 200 meters of road from use for the whole traffic system. The right way to merge is you drive all the way up to the very, very end, you drive all the way up to the obstruction, then merge in.
Craig: Interesting.
Marc: Everyone follows that formula, the whole city have way less traffic jams, and I honestly think that people, I think that the city should be pointing out infomercials telling people, not only do zipper merge, we go all
the way to the end because you’re utilizing all of the road and it makes everybody’s life easier. So, that’s a common mistake. So, for those out there, when you see an obstruction, you when you see a lane ending, go all the way to when the lane ends and then force yourself in.
John: Yeah, I’ll do that now. I’ll do that from now on.
Craig: Interesting. You want me to go first?
John: Absolutely.
Craig: (laughs) You’re still thinking of yours. Well, this is a common mistake, and I made this younger in life and maybe you guys can relate. It’s around financial management, and so, as a young 20 something fresh out of University, first good paying job. What does everybody do?
John: Car.
Craig: Go and buy a car. Exactly, buy a fancy car. And this is something I’m trying to instill at my kids that, yes, a car is good, you need transportation, so and so forth. But it’s, it’s, uh, you just throw money at a car.
Marc: You’re preaching to the choir here. Yeah, my car’s in the shop, and I’m not going to make it in time to go pick it up right now.
Craig: On no!
Marc: It’s like, believe me.
Craig: So, I bought a Volvo. Everybody’s going to laugh at me now, but I was 23 years old.
Marc: What a life mistake buying the sexy Volvo, there, Craig. Sure you picked up a lot of ladies in the Volvo sports wagon.
Craig: It was a sports wagon, by the way. It had Turbo. Anyway, but no. I went and bought a brand-new Volvo. I was looking at Volkswagens, uh, but made a decision to upscale to a Volvo, and you know, I was paying basically the equivalent of rent, for what? A vehicle that gets me around. I loved the car. I enjoyed it and when you’re 20-something that’s maybe what you want in life, but –
Marc: Every 20-something dreams of a Volvo.
Craig: (Laughs). Putting it into perspective, though, is I think now, 20 years ago, if I had instead put that money,
basically, that rent, towards a savings account or something that I could put towards a down payment, I could have bought my first house sooner. All these sort of things, so get by with less and, I think that the common mistake I’m trying to say in general in life is, when people start earning more, they spend more, right? So, keep your spending in check, and stay within your means, and the excess? Put it into savings, ’cause that’s going to compound and buy you more freedom in the future, and that’s what money is really for, is buying freedom. So.
Marc: There you go.
John: I actually don’t have anything. I’m happy with everybody.
Marc: I should have given you the – I gave Craig the question earlier, so it’s all good. ‘Cause you had to take the phone calls, so you had to hop out. I felt, I was gonna give it to you earlier –
Craig: John’s an important guy, got an important phone call.
John: It was from my wife. It was a call from my wife. Um.
Marc: Come on, anything. First thing that comes to mind.
John: Well, it’s in line with what you were saying is, I don’t like when people don’t signal. I instantly think they’re stupid for not signalling. And don’t care about other people.
Craig: Maybe their light’s burned out. (Laughs).
John: I don’t know. Anyhow.
Craig: Anyway.
Marc: Alright well, guys, it’s been a lot of fun, this podcast went a lot longer than we thought it did because we weren’t sure how many mistakes were able to cover, but uh –
John: Apparently there’s a lot.
Marc: I feel like we got a few.
Craig: We didn’t cover them all, either, so.
Marc: We did not cover them all. In fact, I don’t know. I don’t know if we’d ever have enough time to cover all the potential mistakes, but. Thanking anyone that’s listening to us, we like hanging out, having a couple drinks on a Friday afternoon, talking about our industry, and we hope that anyone who’s listening enjoys the banter, get some value out of these discussions. You know, we would love to get any kind of feedback you might have, so do feel free to reach out. And we’ll be more than happy to answer any questions you have, or take any feedback that you have regarding our silly Friday afternoon podcast. So, thanks again everyone. John, Craig, cheers!
All: Cheers (clink glasses)
Marc: Have yourself an excellent weekend and an excellent Friday.
outro music
