To continue our “Talk to an RD” column, Markus Egger and Tiberiu Covaci were supposed to get together at this year's RD and MVP Summit at Microsoft in Redmond. Those plans had to be changed in a hurry due to the current Coronavirus Crisis, but that didn't deter these two RDs from chatting about Azure and other topics.

Markus and Tiberiu have been acquainted - even friends - for quite some time. Tibi (as Markus likes to call him) has long been involved with various communities and has organized various events, such as DevSum in Sweden. He even presented some of CODE Magazine's State of .NET Events. (Side note: We've moved our State of .NET events online for the time being. Live events will return once that's possible, but for now, there's a free monthly State of .NET event online, each focusing on a specific topic. Find out more at codemag.com/stateofdotnet). It's therefore no surprise that these two RDs have a lot of interests in common, especially when it comes to cloud computing. Let's listen in!

Markus: Hello Tibi, good to see you!

Tiberiu: Good to see you too!

Markus: I know you usually travel the world, and you've worked and lived in all kinds of places. Where are you right now?

Tiberiu: I'm in Sweden. But yes, for the past 10 years, we've moved all over the world. Now we're back in Sweden, mainly because we have a baby daughter now.

Markus: Congratulations! That's very cool.

Tiberiu: Thank you.

Markus: I even met her last time we got together. It must have been a little over a year ago, I think.

Tiberiu: Yes. She is a year and three months and she keeps us on our tippy-toes. She started to run around the house. So she's the boss for sure. She's clearly making all the decisions in the house at this point.

Markus: That's good. (laughs)

Tiberiu: Yeah, exactly. (laughs)

Markus: We wanted to talk about Azure. You're very involved in Azure. You are a Regional Director, obviously, which is why we're talking, although I'm catching you on the tail end of being a Regional Director, as you're going to move on and join the “mothership” by going to work for Microsoft. From what I understand, you're moving into a role in the Azure team. Tell me about your involvement with Azure. I know you've been passionate about that for a long time.

Tiberiu: I've known about Azure ever since Microsoft started talking about it the very first time. Even before the PDC when they showed the very first data center in a container. I don't know if you remember. Now the show is called BUILD. It was in Los Angeles. I think it was 2009 or 2010 or something like that.

Markus: Yes, over 10 years ago now.

Tiberiu: Yes. A lot of years ago. And they were showing how they wanted to go to the cloud. And my very first thought about Azure was “nah… it's just Microsoft going into the data center business. I don't think they have a chance.” I thought they would kill all their partners. You know, all the ISVs and all the other partners that are offering data centers. But then, I actually started to look at what they were offering. And I liked their approach, because, while other companies were starting from the infrastructure-as-a-service (IaaS) offering, Microsoft was thinking, “how can we solve the distributed computing problem?” and “How can we solve what kind of applications our customers are using?”

And now Microsoft, being the enterprise-friendly company that they are, I thought they'd have enough data to understand what the enterprise customer wants. They weren't so much looking into startups or into private people. But they were looking at how can they offer a cloud that is sustainable for an enterprise. So the evolution of it I really liked, because they had Web applications, databases, inter-process communication, that sort of thing. There were problems, but they had good solutions for that. And then we started giving feedback. In a way, we were the unhappy ones all the time. “Oh, but we need access to the machine that runs my application.” So there were always these kinds of things and Microsoft said, “okay, we're opening RDP for you” or “we're opening SSH for you.” Then, “we're giving you a virtual machine so you can put whatever you want.” So things progressed in a very iterative fashion.

And then they realized that those are good findings, and, based on that, they decided to rewrite the whole thing. And I think that was one of the best decisions ever made by a software company to say, “whatever we've done, we will scrap, and decide to start over with a clean slate.” Nobody else does that. You know, I always advocated for something like that because the first version of every software application should be your playground. That's how you learn when you start writing something completely different. In that case, for the second version, you shouldn't patch the first one. You should just start with a clean slate. And they had the guts to do it, you know? And that coming from a company that wanted to keep compatibility with Windows 3.11 for a very long time. (laughs) That says a lot about how much Microsoft changed and how many things they did. So I came to actually like Azure a lot.

These days, one of the things I'm looking at is how developers are doing [on Azure], because I used to be a developer 100% of my time. I'm still doing it.

What are your latest “five things everyone should know about Azure”?

Markus: As of now, we'll still count you as a developer. Maybe next month when you're officially a Microsoft employee, we'll change our tune. (laughs)

Tiberiu: Yes. (laughs) Just this weekend I was in a hackathon for two straight days and I was working with a few people. We just created a peer-to-peer video communication platform. We had a central server to start the process and then once I started to talk with you, there's no server involved. So there's no bottleneck. There's no problem with infrastructure. It took me about, oh, I'd say, half an hour to deploy that to Azure. So the guy that did the application was running it on Heroku and I just said “okay, let's see how it works.” And then my whole weekend went toward doing the whole Web pack and trying to do automatic deployments. Now, whenever I'm committing something, I automatically get the back-end application deployed. And that's a Node.js application. And the front-end deployed on a storage account, with a CDN [content delivery network]. And all that now happens by pushing to a Git branch.

Markus: What did you use as the underlying tech for the actual video stream?

Tiberiu: Web sockets. WebRTC actually. That's what one of the people involved in the hackathon chose to build the application. He's the creator of XSockets. He did that as a technology to be able to use sockets when Web sockets wasn't available everywhere. It's very nice. And that's the cool part. We wanted to have screen-sharing. You just open a new media stream. And then we said, “oh, we want to do file sharing just on that the media stream” and you send the file. It's very cool. That's the power of these technologies, platforms, and services we all now have available.

Markus: It sounds like a magazine article right there actually.

Tiberiu: That would be a good CODE Magazine article, yes.

Markus: You and I have worked together a lot as RDs. We don't have a formal relationship as such, but we're working together on various projects. You've even done a number of State of .NET events for us over in Europe. [State of .NET events are a series of free events sponsored by CODE Magazine. Recently, State of .NET has moved online with monthly free events. Find out more at codemag.com/stateofdotnet]. I know you've always done a lot of Azure content in those State of .NET events as well as other presentations. For a while, you've done a “five things everyone should know about Azure” series that evolved over time. Tell me a little bit about that. What are the latest five things everybody should know about Azure?

Tiberiu: For the first two or three, it's relatively easy and little changes. You need to know about Web applications, databases, and storage. That's a very good starting point. And you know, when I start talking to people, the first thing they always want to know is “what would be the advantage?” That's always where it starts. When you move to Platform as a Service [PaaS], you shift the responsibility away from taking care of the underlying platform and you can concentrate on your application. There is some—let's call it “hygiene”—that's involved. You need to do some things a little bit differently, too. Like you don't have 100% control over all the things, but I would say in 99% of the cases, you don't really need that. There are very few edge cases where you really need to have control over those small things. Otherwise, there shouldn't be any need for that.

You start with an application and then you get benefits such as scaling. You get custom domains automatically. You get back up as part of it. Everything in your application is taken care of for you without you ever having to worry about it again, and that's a pretty big benefit, even for something as simple as a Web app. You can concentrate on deploying your application and that's it. And as you then start scaling your app, you get benefits, such as affinity to a certain machine being built in. If you scale to ten machines, or to two for that matter, one of the biggest challenges is always to make sure you can still have communications happening, especially if you use session cookies and stuff like that. Because you want to make sure that you talk with the same machine in those situations. Azure solves that problem for you and you never even have to worry about it in the first place. In a sense, it's as if this problem never existed.

Then, the second part is a database. As a developer, I just need to save the data somewhere. Why would I worry about creating the database? Why would I worry about issues such as a back-up? And moving the tapes of my back-up and all those headaches. In Azure, I can just say that I need the database and everything just works out of the box. And it doesn't cost a lot of money. The cheapest production database you can buy in Azure is about $15 per month, which is enough for a medium-sized application. And if you need more, you can just go and say, “okay, I want to pay more for a bigger and more powerful database because I have more customers.” It's a simple turn of a dial.

The third part was the storage. Most of the assets that you're using in your Web application are static files. Why would you put the pressure on your web application when you can leverage a ready-made storage solution that does exactly that? Then, there are a number of things you can configure on top of a storage account. For instance, you can add a CDN on top of a storage account. You can even do things such as making sure storage happens in the right place geographically, either for legal reasons, or because you want to store close to the user for best performance. Those are all benefits that would be very difficult to reproduce without a large cloud infrastructure.

Markus: Subscribers of CODE Magazine see this in action, whether they know it or not, because digital CODE Magazine subscription files are served up by Azure storage. This hugely simplified things for us when we moved to that setup.

Tiberiu: Yes, that's a perfect example!

Those are the three of the five services that I was talking about. Then things change a bit more as Azure evolves. We have stuff like Azure Functions. Functions are essentially a piece of code you need to run when something happens.

Markus: Like something that runs on a schedule, or something that runs as a response to an HTTP request, which could even be a different way to implement a REST API call.

Tiberiu: Exactly! Why would you have to worry about creating the virtual machine and having to pay for a virtual machine, when the only thing you should have to care about is your code running when X happens. You deploy your code, and you say to Azure “please do that for me.” Whenever you have these events, Azure spins up the virtual machine or a container. It doesn't really matter what it spins up. All you care about is that your code responds and does its thing.

Markus: The whole point is that you don't have to worry what the server is. We refer to it as “serverless.” It's a little bit of a misnomer in that sense. There certainly is a server. It's just that you don't care.

Tiberiu: Yeah, exactly. It should be called “I couldn't care less about the server.” I think that would have been a better name than “serverless,” but they never ask us about such things. (laughs) In the end, you have your code running as you would expect. And scalability happens automatically. You just pay for the time your code is actually running. The more requests, the more machines might be spun up for you. That's the price of doing the business. And at the end of the day, it's still cheaper than running a virtual machine all the time just in case something needs to run or something needs to be done.

Markus: Not to mention that Azure Functions provide a lot of extra features that would be difficult to create on your own. For instance, if your code is supposed to run reliably in response to an incoming email or text message, that, in itself, would otherwise be a serious development and quality control task.

Tiberiu: The last but not the least service that I'm talking about is Azure Key Vault. Because most of the time you need secrets. Think about it like this: If you want to configure your Web application to work with your SQL Server database, you need a connection string to get to it. You need to store a password somewhere. Often, that's done in clear text where, at the very least, it's visible to the administrator. That administrator can put it in the Web application, but those are credentials that the administrator should never get access to. The only one who needs access to those credentials should be your application. With Azure Key Vault, I can configure my Web application as a security principle and that Web application accesses the Key Vault. I don't have any administrator involved who needs to see a database. Of course, I can use the Key Vault for other things, but this is a perfect example and a very common usage scenario.

Now, doing the presentation, which I've done many times, there's one question that keeps coming up: “Do you really have to do everything manually?” That's because in doing the demonstration, I have to show every step and do it manually. I can, of course, automate things, but then I don't think it has the same effect for demonstration purposes. At that point, the overview of five services become six because now you have Azure DevOps you can use, and now also GitHub Actions. I really love that, the simplicity of these services. In an automated fashion, you can create the template that deploys everything that you need. You can have an Azure DevOps pipeline created. It can take the code and it can do the build. It can copy the deployment. You can do whatever you need to do transformations, such as minification. Whatever you need to have done, it's done in a scripted, automated fashion.

Using Azure DevOps, you can even use features such as deployment slots. I can say my dev branch will always do a deployment on my dev environment. And the dev environment is more or less the same as my production environment. Then I have the possibility to run my tests on there. I have the possibility to do some integration tests and if I see that everything works, I can put it on staging. From staging, I can get the people to try it out. And then I use a slot and my live application is upgraded to a newer version right away.

There are a lot of things like that that will keep developers relevant. Because if you just ignore them, at some point you will have to do the task anyway. If you want your application to really use the power of the cloud, you need to start using at least some of those services.

Markus: It's a very interesting point to think about. How do you get started? Or perhaps “started” is the wrong word, but how do you move to that? We just had, as you know, a very interesting scenario that we'll be publishing articles about in the future here in the magazine, because we had a major ransomware attack. There's a lot of interesting stuff going on, starting with the fact that everything that we had on Azure was unaffected. It was a reversal of what people usually worry about. Normally they think “oh, I gotta be careful with security in the cloud.” It was totally the opposite for us, because none of our cloud infrastructure was affected at all. And neither were the people working from home or off-site offices. As a result of all that, we decided to remove the other half of our infrastructure that we still had in our local data center. We decided to recover by moving it all to Azure. It was a wild two weeks because it wasn't a well-planned move in that sense. But it did work out pretty well in the end. I was surprised.

I know you were doing a lot of stuff with getting people to start moving into Azure and move existing infrastructure, right?

Tiberiu: Yes. I don't know if you've seen that, but especially now, with the current situation [the COVID-19 crisis]. People always ask, “what triggered you to move to the cloud?” You know, like the CIO or the CTO who's worried about COVID-19. In the past, people always thought you needed to be in the office. Now, all of that has changed. We see a surge of people who say, “what I need is for my employees to be able to open their laptop in a Starbucks and start working from anywhere.” That's the new normal. More and more people have started thinking along those lines. Perhaps they aren't thinking about the Starbuck scenario, but they are thinking about working from home. Either way, if you do the one, the other will just follow. I don't think there'll be any difference because if you know it's safe to work from off-site, then it's as safe or as unsafe at someone's home as it is at Starbucks. I don't think there is too much of a difference.

I don't see working from a coffee-shop as all that different from working at home.

Markus: I agree. I really think that more acceptance of working off-site will be a lasting change. When we had the 2008 financial crisis, we squeezed out a lot of efficiency from our business processes. Perhaps we've relapsed on some of those, but all in all, what will be the optimizations we implement to overcome the current crisis? It gets harder and harder to think about inefficiencies. One of the things I can think of is to eliminate the overhead people run into that is related to work, but inefficient. Things like hours of commuting to and from work are a huge waste. I see a lot of potential for becoming more competitive by having people dedicate more productive time to work while at the same time reducing the overall hours they spend on work and work-related tasks.

We always think of people working 40 hours a week. But when you count the commute to and from work, and you count that they were somewhere for lunch that was really just because they were at work in the office, and that they had to drive to and from day-care because they can't take care of their own children, and so on, then we probably get to something more like 60 hours a week. I think it would be better to reduce that to 50 hours but spend those 50 hours more productively.

Tiberiu: That's exactly the idea! How can you enable people to work with the things that they need to do? Microsoft did a lot of work around that lately.

Markus: How do businesses move toward that? What do you tell businesses that want to take their first step toward the cloud?

Microsoft now has something called the Cloud Adoption Framework. You can think of it as a DevOps approach to moving to the cloud.

Tiberiu: Microsoft now has something called the Cloud Adoption Framework. You can think of it as a DevOps approach to moving to the cloud. If you want to start that process, Microsoft has a DevOps generator that will give you a starting point. You'll get all the activities with all the features and user stories and so on. You can have your Kanban board that includes things such as “you need to convince stakeholders,” “you need to address those business people in order make certain decisions,” and so on. One of the things I love about that is that most companies think their needs are unique. And they are all different, of course. But when you move infrastructure to the cloud, there are certain steps almost every company has to take. This framework really helps with that.

I see a lot of the same patterns in many cases. A lot of customers say “we want to start with Software as a Service and if we can't find anything, we want to write our own using Platform as a Service. If we don't find that, then let's use Infrastructure as a Service.” Guess what? 80% of people moving to the cloud start out moving to Infrastructure as a Service in spite of what the CEO and CTO decided. It happens on its own. Most people are in a rush, so they start moving the machines they have to the cloud as they are. The explanation is pretty simple. Most companies just don't have the time or means to do a full analysis to see if they can move to Platform as a Service.

Markus: We've had the same scenario. The hardest part for us to move after the ransomware attack we suffered was to move the database. We had a very, very large database, which wasn't really designed for the cloud but needed to get up and running. We had two really tough challenges. One was how to get this much data to the cloud. For us, there was little choice, because we were dead in the water. We uploaded to the cloud and however long it took, it took. Then, the second aspect was that it just wasn't designed for the cloud. We had to change some of our data structures. Not much, as it turned out. In the end, it was relatively easy. As a first step, we just spun up a VM and put it in there, as if it were its own SQL server. Then we changed data structures a little bit, and then broke the database apart a little bit, and cleaned it up a little bit while we were at it. And now it's fully on SQL Azure as a SaaS platform.

Tiberiu: Cool.

Markus: What do you see as the hardest part? Is it usually data? Or do you just see old apps that need to change?

Tiberiu: It's people. Still people. That's the biggest challenge I see with every company that wants to move to the cloud. Regardless of where the decision comes from, it's the people that resist the most. They make it so much harder in most situations. They don't want to change. I think that's part of human nature. What I've also seen is that a lot of them are very scared of change because they don't know what to expect. It's completely unknown territory and it's something completely different.

I think for me, at the beginning, it was pretty hard as well because the terminology is completely different. You need to get used to that. But then, when you start explaining, they get the hang of it pretty quickly. In Azure, unlike in conventional data centers, it's not about hardware anymore. Everything is defined by software. At the end of the day, things are still the same, at least from an operational standpoint. Of course, if you talk about monitoring, if you talk about networking, and so on, there are other tools that you need to put in place. They're still the same kinds of ideas. Then, of course, you talk with people, and they still think, “oh, I need my DMZ.” And I'm like, “are you sure that's what you need?” because I'm not really sure.

Markus: You're applying your old concepts to a new setup. And some of those concepts may just not apply anymore.

Tiberiu: They used to work with those concepts and that's why they want to keep it like that. That's the biggest challenge. I don't think it's a technological one. It's people.

Another problem that I see quite often is that they're afraid that if they move a machine, they don't know what all the dependencies are. Most big organizations have a mess of IT. I think there are very few where that isn't the case. There are very few companies that have a complete list of not just all their servers and what's on them, but also what accesses them and what might break if they're moved. There are tools out there that can help with that. They can detect how the machines are working. They can give you a fair picture about what you have. But still, companies are often in a situation where they don't really have everything they need. In most cases, you need to make sure that when you move something, you're able to move back quickly when you discover that you broke something.

Markus: Which is pretty much what the case was for us. I mean, obviously, because our ransomware attack wiped out every single server we had, and because we had to preserve that for forensic analysis, we had no choice. We had to move forward. It was challenging. Getting the major pieces up and running was not so difficult. We had our external facing things, like websites and so on, up and running relatively quickly. But then it was the little internal details that you just didn't even remember, that were the hard parts. Although we had some pretty good docs overall, we didn't have all those details well-documented. Like the little WinForms tool that somebody wrote themselves 15 years ago that was still in use and had access to the database in some way. And you just forgot about that and now it didn't work anymore, and there was really only one person in the company that even still used that.

But I also have to say, when we looked at this maybe two or three years ago, when we started our move to Azure, we identified that about 50% of our infrastructure was easy to move and we moved it relatively quickly. The other 50% was a different story. And it isn't even that we knew it was going to be hard to move. It's more like we didn't know how hard it was going to be. We had a hard time assessing what pieces there are that we don't really know about or that you forget about or that aren't really worth moving. Due to our attack, we were forced to make those changes and take the plunge. And I'm glad, in a way, that we did because we're probably better off today. But we went through a few rough weeks to make that all work.

You know, one of the biggest drivers today is that people are at the end of their contract cycle with their current data center. Or maybe they need to buy new hardware and decide to move to the cloud instead. So three or five years have gone by and they need to switch to new machines, or they push to the cloud instead.

The very first cloud customer I had I actually managed to scare away. (laughs) They decided to move to another data center, not to Azure. I think that that was my mistake. I went to them and showed them as much of Azure as possible in all its beauty. I think to them, it was overwhelming. They just wanted to move some servers and some websites. And I'm like “wait a second. If you do that, you can use the service directly,” and then all of a sudden, it was too much for them. So they decided to just move to a local data center. That was a hard lesson to learn, because it was a project on the order of 20 million pounds by the time it was all said and done. So that was a bit of an eye opener for me, because I thought that if I like it, everybody will like it, especially if you talked nicely about it. But people were still hung up from their own technology and their own way of thinking. And it's easy to overwhelm them with everything Azure can do.

Tiberiu: I hear that.

Markus: “Eye opening” is a good term. It was really eye opening for us to have a scenario where we needed to do this for ourselves. Usually, we do it for customers and help them; when it's their pain, that doesn't seem so bad, right? But when all of a sudden it's your own organization, it truly is an eye opener. And that's good, because it really helped us in supporting our customers better.

Hopefully you will still be able to do that. I know in your new role at Microsoft you're not going to be working directly with customers in a consulting fashion anymore, but you're still doing the same thing for Microsoft essentially when you join them, right?

Tiberiu: One of the things that I will have to do is not only excite developers but more of a general audience of stakeholders. It might involve me talking to the customer. Maybe not doing the groundwork but advising them on how to move. At least having initial discussions and trying to understand what they need and maybe explaining to them how I can help. It will still be an interesting position. So I'll see.

Markus: Excellent. I wish you the best of luck with all that. It sounds pretty exciting.

It's getting late where you are. I'm just getting started with my day here. This is definitely the most geographically remote RD Talk I've ever done. We are pretty much exactly on opposite ends of the planet, with a 12-hour time difference. That in itself is very cool and shows how far we've come. It's been great talking to you.

Tiberiu: Likewise.

Markus: I'm sure the times will come again when we can all meet in person. Maybe at one of the conferences you were involved with or, or at Microsoft.

Tiberiu: I'll still do my conference. [Tibi organizes DevSum in Sweden] We are going to do it digitally this year. There are about 15 to 17 speakers from Sweden. Most of them are from Stockholm. We also have some international speakers. Tim Huckaby, our fellow RD [and former participant in this column] is going to do our keynote remotely.

Markus: It's great that you're still doing it. Keep pushing forward!

Tiberiu: Yeah, exactly. We have to.

Markus: So is Microsoft with BUILD online and other online events. There will be different kinds of events, but I think there will also be interesting ideas coming out of those.

Tiberiu: That's right. Microsoft has announced they're moving all their events online between now and the summer of 2021.

Markus: I hope I will see you sooner than that. And best of luck with your new role within Microsoft.

Tiberiu: Thank you.