Preface: data professionals, if you’re in a hurry, skip this post. Nothing in here is directly relevant to your career in the next couple of years. I found it interesting because it explains where Microsoft’s developer story is going, though.

At DevIntersection/SQLIntersection today, Microsoft’s Jeffrey Snover (@jsnover) talked about Azure Stack, something data professionals haven’t been hearing much about.

In a nutshell, Azure Stack means running parts of Microsoft Azure on-premises (including databases). Most companies aren’t going all-in with the cloud – they’re just moving some of their workloads up. Azure Stack is Microsoft hedging their bets, letting you use Azure services, but without handing data and control over to Microsoft.

Snover said, “The cloud is a model, not a location.” By that he means that you can get Azure stuff from:

• Microsoft
• Service providers (think Rackspace, for example)
• In-house in your enterprise
• And of course, a mix (with some of your stuff running on-premises, and some elsewhere, and hopefully it won’t matter where you move stuff to down the road)

Microsoft’s taking what has traditionally worked well for them – selling through partners and enterprises – and has traditionally not worked as well for their competitors (Amazon and Google.)

Buying and Deploying Azure Stack

To get Azure Stack, you pick a vendor (Cisco, Dell, HP, or Lenovo), pick your capacity, and the vendor brings the hardware in and wires it for you. “This is better because in the past, you bought your hardware from one place, the software from another place, the network from another – with Azure Stack, you pay one bill, and you get end to end support.”

Data professionals have seen – or at least heard – of this model before. It’s the same thing behind Microsoft’s Parallel Data Warehouse, their Fast Track Data Warehouse Architectures, and the Database Consolidation Appliance. Thing is…I bet most of you haven’t actually used one of those. The adoption rate in the SQL Server community was extremely low. I don’t see this as being really different.

In theory, Azure Stack’s one-throat-to-choke model appeals to enterprises and small businesses alike who’ve struggled with deployments. Oddly, though Snover talked about you being able to call anyone you wanted – the hardware vendor, Microsoft support, or your implementer – and they’ll all work together harmoniously in order to get you the right resolution. I know a lot of us have had tough experiences with that kind of support, but if there’s truly standardized hardware/software/networking, and really good support runbooks, it might work.

Thing is, I see a lot of sysadmins going in the opposite direction. They’re going for lowest-cost, commodity, interchangeable hardware running virtualization that means the hardware differentiators are meaningless. The idea of buying higher-cost sealed appliances is the old mainframe way, and I’m not sure that’s going to catch on.

Patching and Maintaining Azure Stack

Snover described on-premises Azure Stack maintenance as a low-skilled job. “We have a light come on to tell you what gear to replace, and you call for support to handle unusual problems.” In the same breath, he described SAN admins as low-skilled jobs, saying, “SAN admins don’t really log into servers and look at specific data. They just replace drives that go bad.” (I’m still kinda stunned at that diagnosis.)

Azure Stack patches itself, Snover said. Microsoft tests patches and makes sure they’re going to work well, and you don’t have to worry at all about what they patch, and when. It’s just going to work.

I know, dear reader, you expect me to make a lot of snide jokes here. Thing is, I don’t think I’ve heard a single horror story out of Azure PaaS patching. Yeah yeah, we’ve had our share of breaking news for on-premises SQL Server, but Microsoft’s doing a pretty good job of patching stuff (and probably catching/repairing deployment bugs) that they control directly. I don’t have a problem with this – it actually sounds great.

Building Apps (and Resumes) with Azure Stack

In a keynote room full of developers, Snover pitched Azure Stack as a resume builder. If you hone skills that only work with public clouds (Amazon & Google), then you can only work at companies willing to use the public cloud. However, if you hone Azure Stack skills, you can work at any company. (Errr, any company that uses Azure Stack. That’s where this argument kinda falls apart today, but in 5 years, this might well be different.)

I think he’s burying the lede here. Function-as-a-service (aka serverless) is going to eat conventional development alive over the coming decade. If you’re a Microsoft developer, I’d simply ignore Azure Stack altogether and focus exclusively on Azure Functions. Azure Stack includes the capability to run your Azure Functions on-premises (along with supporting services for file storage, load balancing, etc.)

I’m drinking the serverless Kool-Aid big time, so in my mind, the keynote would have been better spent with 80% of the time spent on Azure Functions, and 20% of the time explaining that you’ll be able to run your FaaS code on-premises with Azure Stack. That’s just me though.

There’s never been a time in my personal history where I wanted to go back and redo my career. I’m pretty happy where things ended up. However, I’m jealous of folks coming fresh out of school these days, ready to start using function-as-a-service computing. You can build anything and scale like crazy for really low down payments. It’s a great time to get started as a developer with a business idea.