If you were going to build a brand new application today, your approach would probably be fundamentally different than five or ten years ago. And I do mean fundamentally, as in the fundaments of the architecture would be different. In the last ten years we have moved rapidly from traditional three-tier applications to 12-factor apps using microservices, and now things are shifting again to serverless. That’s all well and good for any business looking to build a new application, but what about organizations that have traditional applications? I’ve also heard them called legacy or heritage applications. These applications are deeply ingrained in the business and are often what is actually generating the bulk of a company’s revenue. The company cannot survive without these applications, and modernizing them will be costly and fraught with risk. Due to the inherent risk, most companies opt to either keep these applications running on-premises or move them as-is to the public cloud, aka life and shift. That’s the reality we’re living with today, but tomorrow is knocking on the door and promising hybrid cloud to fix all this. What’s the reality and what’s the hype? And what is the most likely journey for most companies?
This week was AWS re:Invent, and I watched the keynote live-on Wednesday.
The three. hour. keynote.
During which Andy Jassy announced new features at a pace that is frankly astounding. Three hours should be too long for a keynote, and if I wasn’t watching from the comfort of my office, it would have been. Not only did the announcements keep unfolding for the full 270 minutes, but some didn’t even make it into the keynote. Running a three hour keynote is tough, creating enough new services and features to overflow a three hour keynote is amazing. My hat goes off to the engineering teams at AWS. It is truly staggering what you manage to accomplish each year.
In the last two parts we deployed an Azure Stack Development Kit on an Azure VM and got it registered with Azure. Then we created an Offer and Plan for the default user and started the download of marketplace items for use on Azure Stack. Now that those items have completed their download, we can move on to the process of installing the Resource Providers (RPs) for Microsoft SQL Server (MSSQL), MySQL Server, and the App Service. In this post I will cover the process and scripts you can use to get the MSSQL and MySQL RPs running. The App Service will be a separate post, due to the additional complexity involved.
Let the registering begin! So you’ve got a working Azure Stack on Azure, which is like some kind of crazy inception thing. But let’s be honest with each other, there’s not a whole lot to do on Azure Stack at this point. You could like provision a VNet, maybe set up some sweet Resource Groups, but if you want to do something useful – like create some VMs or deploy services – you’re going to want to register your Azure Stack with Azure and syndicate with the marketplace. So let’s go ahead and do that using the Register-AzureStackLAB.ps1.
With the introduction of Dv3 and Ev3 VMs in Microsoft Azure, it became possible to run nested virtualization on Azure. Since I’ve got Azure Stack on the brain these days, my immediate thought was, “I wonder if I can run Azure Stack on Azure?” (cue Inception music). Not only was the answer yes, but others had already started the process for me. Following in the footsteps of Daniel Neumann and Florent Appointaire, I was able to bet the process running. One of the engineers at Microsoft took some of that work, added their special sauce and rolled out a GitHub repo that helps you through the process. I have forked that repo, and started adding some automation myself.