How is it in Microsoft's DNA? They've always run the software, not the hardware. And for Azure, they just took all their Office customers and rebranded them as "Azure" customers, pumping their cloud numbers.

I think the point was that Microsoft has typically been very present in "enterprise" - lots of sales people in lots of industries with lots of connections and lots of experience making the sales and doing the deals. Google less so.

The hardware is just the hidden infrastructure that businesses don't really care about as long as it meets the SLAs, like I don't care about what the physical building materials are when I go and buy groceries or get my hair cut so long as the building meets it's SLAs (which for a building is I guess not falling down when I am inside it etc) I just want the service.

That's fair. Their sales team and the relationships they had made over the years is definitely a huge part of their success transitioning.

Enterprise Sales, Support, Training, Certifications, Deals for packing services/software/etc, Incentive programs, Extensive partner network, etc, etc, etc.

There's an entire realm of software development and consulting in and around Microsoft enterprise products - and that has extended to Azure as well.

Personally, I've worked with AWS,GCP and Azure in a professional capacity (data science consulting) - and while Azure has its fair share of warts, the level of integration and "it just works" between Azure and MS Enterprise products is fairly impressive.

For example, I'm big on postgres - but working with SQL Server on Azure is such as breeze. There's nothing I can do with it that I couldn't do on other platforms, but the combination of tooling (SSMS, VSCode) and smooth azure integration (Blob Storage, AzureSQL, Logic Apps, Azure Functions, etc) made it easy to make things that 1. worked and 2. could be mostly supported by a BA instead of a dev.

One of my favorite resources is https://docs.microsoft.com/en-us/azure/architecture/

It's a rich set of articles about various system design patterns. It's not even really set in the context of Azure, it's just plain "Here are things you should learn about". It's really well done.

I haven't seen anything close from Google or Amazon.

That certainly covers operations in AWS, but take a look at the azure docs for cloud design patterns: https://docs.microsoft.com/en-us/azure/architecture/patterns...

For example, read Bulkhead, Circuit-Breaker, Queue-based load leveling, sharding. The level of detail around why you might want to do it this way is fantastic. AWS whitepapers and best practices never really get into the why, they just focus on the what.

They know how to sell to old stodgy Fortune 500's.

Google is excruciatingly awkward in the room with that group. Amazon is in the middle.

I'm a Satya naysayer as much as any Windows Phone victim, but Office 365 is not part of the "Intelligent Cloud" unit that Azure earnings are reported in.

Since when is the internet in Microsoft's DNA?

And isn't Azure's main feature the fact that they provide a service invented and developed by Google (kubernetes') and a first-class citizen in GCP?

Microsoft's DNA is Enterprise with a capital E. Google has always had the startup pretense (or rather, the pretense of still being a startup, even when they're not by any stretch of the imagination), meanwhile in almost every Fortune 500 company you'll see offices full of Windows desktops running Office. The sales networks are there, and they can reuse them for Office 365 and Azure too.