The Strengths and Challenges of Azure Networking - C2C036

And because we haven't really had a chance to roll through and do a deep dive Azure type of session , I figured that , hey , I couldn't think of anybody better to bring on . So , woody , go ahead and introduce yourself .

So when the local field teams get stuck with networking or connectivity issues in a pre-sales motion , then they wheel in the Global Blackbelt to kind of whiteboard their way out of the situation . So I was doing that at Azure for about five and a half years . Prior to that I was actually on the infrastructure side .

I started out there as a load balancing architect so running all the F5s and Citrix gear and stuff . But that whole division was actually subsumed by Azure after Satya took over . So we became part of the Azure networking services team . So I was there for a while .

So kind of know where some of the bodies are buried , because I was there when Azure was bootstrapping itself and that was fun .

We haven't really had a good chance to talk about Azure , so , in the spirit of figuring out where the bodies are buried , if you will , so you know , in the spirit of figuring out where the bodies are buried , if you will , what do you think from an Azure networking perspective versus , like AWS , how do you feel about , I guess , azure's networking in general ?

We'll start there . Actually , let's just start there . We'll kind of pick it apart from there .

So they began building a global WAN back when MSN was a thing Remember the little rainbow butterfly Get MSN dial up . There was a whole branding exercise around MSN and MSN NBC came out , and it was at that time that they were building the preliminary data centers .

So Boynton , blue Ridge , san Jose , des Moines , there was one in Silicon Valley , tokyo , dublin and a few others . There were about seven or eight . These do correspond to Azure regions . They grew up later and became Azure regions and , of course , azure has added a lot of regions that were not in the original data center circle of MSN .

But over the years , as Azure grew and grew , microsoft has invested billions in their backbone . So , depending upon the yardstick that you choose to measure , it's either the largest or second largest private network in the world . It is massive , hundreds of thousands of miles of dark fiber . Some of it owned , some of it leased tremendous amount of redundancy .

Even though Azure doesn't give SLAs , they do run a five nines network underneath for all of their other connectivity services . If you think about M365 , formerly O365 and Teams , which actually uses Azure front door , by the way , for its point of entry . All that stuff is super duper reliable because they've had decades and decades to perfect it .

So Azure is really smart at leveraging this network for competitive capabilities . So , for example , every public IP you build in Azure is Anycast . It doesn't even matter if you're sticking it on a virtual machine or a load balancer or a PaaS service . They're going to grab that IP at your closest point of entry into their network .

So if I'm a customer that lives in Hong Kong , for example , and I build a virtual machine with a public IP in US East or US East 2 , that public IP is going to the connection to that public IP is going to enter the Hong Kong POP and then they're going to cold potato that over their whole network .

So there's a tremendous amount of speed and reliability that Azure can deliver with their network , and they do have some good latencies . I remember seeing a Thousand Eyes report a couple of years ago , though , that showed that Google network was just as reliable and fast . So they are obviously no slouch .

They've also invested billions and that AWS was catching up quickly . Aws was catching up quickly . So I don't want to say Azure has squandered their lead , but they definitely know how to leverage their big network and use that for a variety of services , teams being another great example . Azure Front Door is kind of like a Layer 7 load balancer .

It's kind of like their version of Akamai . They have a CDN product , but Front Door is a kissing cousin of that and it's a pretty cool product actually . It's like a web accelerator SaaS service , and so there's a bunch of Microsoft services that run on that . Another thing I like about Microsoft is they eat their own dog food .

So , for example you know again , Teams actually runs on Front Door . They're confident enough in their Front Door service and the rest of their network to put Teams on it , which is , of course , their flagship productivity chat thing . So that's cool .

You know , they definitely have a belief that if they can't get it right , if it's not good enough for them , it's not good enough for their customer . I did like that attitude . Azure has been first out of the door on a few things , believe it or not .

They , of course , are well aware that AWS was first to cloud and that AWS really developed the most mature virtual networking services first , like Transit Gateway and Direct Connect Gateway , and they do have a chip on their shoulder about that because they're very competitive .

So one of the things they tried to do and , depending upon your opinion , were either successful or not so successful I have mixed emotions about this was leverage the breadth and depth of their network through a service called Virtual WAN .

So they were first to market with a global connectivity platform that did backbone routing and cold potato routing as a kind of a PaaS offering . It was a beautiful idea . I think the overall service was really thoughtfully done in terms of its capabilities on paper and how you would use it to connect .

The problem was that it just didn't have the muscle for enterprise . The problem was that it just didn't have the muscle for enterprise , so it was a little too quick to market and it was missing some table stakes features in terms of routing control and security and ease of connectivity and ease of use that enterprise customers really wanted .

And that is something I think that is kind of endemic with Azure .

Insofar as they really are in a space race with AWS , they're really anxious to get some of these killer networking services out the door first , and in this mad rush they would rather plant the flag in the ground first than kind of wait for things to be fully baked , and so this can be a problem sometimes .

What's your thought about the fact that Microsoft was second to the field and they got to kind of see what AWS did right , did wrong , and then , like , do you think , do you feel like they've kind of benefited from seeing AWS do it right or wrong ? Or I kind of want your thoughts on that .

The Azure networking shop is like Germany prior to unification . So you have all these teams inside that are working on different products . They're friendly with each other , they're collaborative , but ultimately they're not arcing towards necessarily the same end goal , so they're kind of independent .

Necessarily the same end goal , so they're kind of independent , and they have different release dates and different feature implementation ideas and different concepts about what innovation is . And so some of these teams are really good at being a fast second . So Azure Firewall is a great example . They noticed that there wasn't really a cloud data firewall in AWS .

They saw the need for it . They studied the market . They talked to a lot of customers that were either former AWS customers or prospective AWS customers , and they learned early that cloud security was a big , big deal , that lifting and shifting firewalls was really hard to do . So they came out with Azure Firewall and that was a success .

That was a great motion . As a fast second , network security groups are a great example . They studied the way that security groups and ACLs work in AWS and they're like this is a nightmare . So they made security NSGs capable of blacklisting , whitelisting and graylisting so they're a little bit more sophisticated and easier to use .

I use that term kind of lightly because no cloud ACLs are super easy to use , but they're more sophisticated than AWS . But some of the teams because of their independent nature , I would say squandered that capability . So , broadly speaking , if you look at the speeds and feeds of Azure networking , they've never been able to catch AWS .

So the fastest express route gateway is a 10 gig device . Now there's some secret squirrel ways of getting it faster , but unless you're a big , big enterprise and you have a lot of sway , you do need to stick with the offering that you see , you know , on the website , which is a 10 gig device . Direct connect gateways , I think , go up to 20 or 25 .

So AWS has always had a faster . It seems like just the virtual machines in AWS in general are capable of faster speeds and feeds , so they haven't been able to really exercise on that . Not that Azure has slow or bad VMs Some of their VMs are amazing and super powerful but the networking part of the stack has its bottlenecks .

So that's one example and some of that again , to be candid is it's taken Microsoft a while to embrace open source .

So some of the gateways not all of them , but some of the gateways services that are built in Azure are running a special version of Windows Server with RAR , which is their BGP routing stack , installed , and it's very stable and of course , they've got world-class engineers from Windows Server that know how to optimize these things .

But if you're really looking for , in my opinion , a world-class routing device , you should be running Linux or Unix or something right , just because of the deep levels of support and features and testing and open source community around networking on those boxes .

So it's , they're catching up there , but I think that has been a hindrance to them , this kind of old school desire to to run Windows come hell or high water .

Do you think that is a net positive for them ? Do you think that is a net positive for them ? Is there any kind of benefit that comes or detriment , I guess to using and building out this new operating system ? I don't know if you've seen how that kind of ties into the overlay and how they operate .

So after John Arnold moved to the Sonic team , a gentleman by the name of Christian Kutz took over and then he went to work on the Azure load balancing team . Then I took over as the load balancing architect for Azure , so I sat in John's old seat . John's a great guy , super smart guy . I think Sonic NetNet is a good thing .

I think it helps for a variety of reasons . I think it helps Microsoft and Azure with their vendor dependence strategy to avoid lock-in . I mean , you know , all of the big names are there in some way , shape or form under the covers of Azure .

I mean , cisco is there , juniper is there , arista is there , of course , and Microsoft has decades of experience and deep relationship with these companies . But I think after Satya took over , he understood the importance of OEMing and turning more to open source , and so Sonic was the first big initiative that came out of that assessment . And it's a white box .

It runs Ubuntu , and what's cool about Sonic is that its operating system is containerized , so different parts of the stack run in containers . Thus you can have hit list upgrades . So I can upgrade the networking stack without even having to reboot the box , because all I do is spawn a new container and then merge it in .

So the downside about Sonic is it's probably going to take a while for first that device to be able to become stable enough to use endemically across a lot of Azure . I think my understanding is that Sonic is mostly in place now as a Tor top of rack switch and that this it's adoption is spreading and it's becoming more and more ubiquitous .

But Microsoft is understandably , on the Azure side , very conservative and cautious about introducing too much change in their underlay because of the high , high , high availability requirements that they have . But it helps from a price point . It helps from an open source community perspective .

So anything that helps save Azure money should in theory lower the price for the customers . It resists vendor lock-in . You know all these things .

So things like VWAN and network security groups and things like that , if we're talking about specifically transit networking or you know whether it be regional or global , you know VWAN was the answer that Azure brought to the table for that right .

Yes , I mean historically , if we actually look back , if my memory serves me right , I'm pretty sure AWS Transit Gateway and VWAN went GA like the same year I think it was within a few months actually for the first time . So I mean , obviously each of them have their own specific reputations separately within those clouds , right ? I'm curious to get your take .

What do you think you know from that point ? I think it's 2018 up until now , so we've had about six years to bake on it . What do you think you know from that point ? I think it's 2018 up until now , so we've had about six years to bake on it .

What do you think AWS did with transit networking , that they got right and wrong versus what Azure did right and wrong in that regard .

There's no doubt that AWS are masters of simplicity . The way that they commission or surface every network function as a gateway I think is brilliant , because gateways are very granular , they're very easy for customers to grasp . They become Lego blocks . They're modular . You can use them in a lot of really creative , effective patterns .

So if it also , yeah , there's just a simplicity and elegance to it that leans towards faster adoption , easier architectures , you know , and I don't know about the stability piece I'm sure AWS is also hyper focused on stability but just that ease of use and just the ability to kind of grok how their network components fit together because there's a similarity between

them , I think is wonderful . I don't think Azure took that approach right . Azure has some gateways and then they have some past things like virtual WAN , and then they have some SaaS things like front door , and each one of these environments is totally different than the other , so there's nothing that maps really from one service to another .

There's some similarities between ExpressRoute gateways and their VPN gateways . Those two are close but each one is kind of bespoke and so it is exhausting to kind of have to go through and master each of these different services and it gates adoption , it does .

And also you know you don't get a lot of reuse but innovations that are happening , the virtual WAN team are going to be trapped inside of that environment because you can't take anything that's happening in virtual WAN and then map it to ExpressRoute because they're totally different platforms .

You know separate reference architectures . You can deploy the same thing with it . You can do VWin , you can do a hub and spoke VNet architecture right . But that's kind of comes down to the you know , to put it in AWS terms the primitives that they've put in place within that cloud right .

So yeah , it's interesting to see how adoption has basically affected from that .

We're on service insertion . It looks exactly the same as Inspection BBC . You write a policy to affect CloudWind because you can't manage the route tables . It's like that . But anyway , just real quick , because I think you really nailed it . What are the the bit about how all of the AWS things feel like Lego blocks that fit together .

Very importantly , they fit together and they it's very obvious how they fit together . They have the same experience . But and yeah , you're right , I there was always something that in Azure that made it feel more complicated and I think that's it right is that each individual piece , networking piece of Azure doesn't feel , doesn't have that snap together feel .

Right Azure does another , basically very cool thing , which is called VNet injection , where they do special magic in the Azure hypervisor to expose Azure hypervisor vSwitch interfaces to services that run in their public pass side .

So what I mean to say is , if I am a customer of the VNet and I have a private network , that's my VNet or a series of them , use a motion called VNet injection and take a public pass service , like you know , the Azure web services or functions .

The control plane logic is different between all the different services , the capabilities are different and there's just no consistency .

So if I learn how to master VNet injection for Azure Web Services , which is called an ACE , an application service environment if I want to do a function I need to use an ICE an integrated service environment totally separate animal , totally different set of an ICE an integrated service environment totally separate animal , totally different set of rules .

So it's just like again , a lot of amazing innovation , a lot of super cool functionality , things customers love . Like the application service environment .

The private instance of that web service was super , super popular and probably continues to be , because you get the sweet spot between yes , I have a pass service but it runs in my VNet so I can tick all these compliance boxes . So that was flying off the shelves like hotcakes .

But then customers would be like great , I'm ready to do functions now and I'd be like , okay , well , that's different , that's an ice . We're going to have to plumb different control plane rules to your firewall . We're going to have to build a different kind of subnet . The CIDR requirements are different , the capabilities are different and it was frustrating .

Some people would say that's good , right , and I don't know if I agree with that necessarily , especially if you're going to do VNet peering with lots of routes , lots of subnets , lots of ENIs right , that's all manual or via Terraform . I actually like how Azure chose to do it with hey peering just makes the routes available by default between the two VNets .

You just have connectivity . I remember when we were trading knowledge on the whole AWS versus Azure thing and I showed you how the AWS VPC peering worked . I remember you being kind of unimpressed with it compared to the Azure version . And Azure can do other things , like you can check it and make a transit VNet very easily . It's just a checkbox , right .

There's definitely some function , some ability there that I feel like Azure Microsoft took advantage , looked at what AWS had done and said , hey , we're going to make this easier . But yeah , I mean having said that , of course there are other things , like all these different bespoke services that bring the complexity right back into it .

But I do like some of the basic primitive stuff that Azure did on the networking side .

But it was a way to create three or four different crystallized patterns of VNet peering with a point and click or easy automation motion so you could choose a full mesh , you could choose like a ring , or you could choose a hub and spoke kind of , for example . And that has a lot of potential .

Because another thing that I think is common to all clouds , not just Azure , is limitations . So it just big enterprises coming in .

This is prior to cloud repatriation , when literally they would just look at every single application they thought they could migrate and they would just square peg that bad boy till the cows came home and they just cram that sucker in there and sometimes it worked great and sometimes it shit the bed because that application was designed in 1999 or 1998 or something

and had all of these esoteric performance requirements and wild little nuances that it needed . And then you try to smash that into the cookie cutter motion of cloud and the wheels would fall off . So , for example , vnet peering limitation , customers would hit quite often .

So Azure Network Manager was built because one of the ways to get around hub and spoke peering limitations is to full mesh everything . One of the ways to get around hub and spoke peering limitations is to full mesh everything , because essentially you only have one or two peerings from any one VNet to any other because you're fully meshed .

Am I getting that right ? Well , anyway , you have quite the hub . Every VNet only has one peering to each other VNet . Thus if you have 500 total peerings before you've exhausted your peerings , you can have 500 total VNets peerings before you've exhausted your peerings . You can have 500 total VNets .

But it also helps with this ability of creating kind of like a distributed system . But trying to do that manually is impossible , impossible . So people get stuck in these hub and spoke architectures . It's really interesting to me how the hub and spoke became the pattern du jour . It just became the de facto way to develop an enterprise .

Stamp in the cloud was the hub and you put all your security and routing stuff in the hub and then you put your applications up at the spoke and there are some really great outcomes to hub and spoke , but it's also terribly confining and this is just across all clouds in general and one of the you know not just Azure . Hub and spoke is popular everywhere .

Gpc is neat , though they you know not just Azure . Hub and Spoke is popular everywhere . Gpc is neat , though they have the global VPC . That's kind of different , although I haven't spent a lot of time with it .

Yeah , no , I mean , personally , I think hub and spoke is a thing , for the same reason that centralized firewalling is a thing and it has to do with administration and scaling right , and that's all there is to it . I do think Azure does a good job with Transit VNet . Like I said , it's just a checkbox and now , hey , your VNet is now transitive .

You can't achieve that at all in AWS , for example , checkbox or no , no matter what you do . So , like I said , I think Microsoft did look at some of the things AWS did and had that second mover advantage of being able to correct some of that . I do think there's other problems .

So , okay , actually , let's move on a little bit , just to try to dig a little bit in on some of these just before we run out of time .

So Azure Route Server is kind of a lot of people think of Azure Route Server , similarly to the Transit Gateway , but the thing with Azure Route Server is , of course , that it's control plane only , which means it's more like for those who are network engineers . It's like a BGP route reflector .

It's not in the data plane , and so that makes some very interesting routing architectures . So I mean , tell us a little bit about ARS and kind of what you feel about it , what you might have seen it with . I don't know if you had a chance to work with it or if you were out by that point .

I think he's still at Azure , but ExpressRoute is now run by John oh , I forget his last name Also a super good guy , super smart guy . John's going to kick my butt . If he hears this . He'll actually laugh that I can't remember his last name because he and I have been at Microsoft forever . But I'm just , I'm having a brain fart .

But Charlie Wynn , the brainchild of Charlie Wynn , and he came to the black belts and said I have this idea about a route reflector that we could use to make BGP more palatable and more easy to consume inside of Azure .

And we were huge proponents of it and actually kind of helped him co-design some of the outcomes and architectures to which it could be used and we did a lot of beta testing on it . So that was really fun to be there in the ground game and be part of the actual build and kind of design part of ARS .

So it's not a story of too little , too late , because you can get a lot of stuff done in Azure without Azure Route Server , but it fixes a lot of things . It fixes the fact that you can now plumb BGP routes into what Black Belt's called the Azure Fabric Router which is the route table that the Azure control plane maintains .

I could have a whole conversation on the Azure control plane but I'll bore everyone to tears . So it maintains it and nurses it and injects it in a very precise way into each of the NICs of all the different virtual machines and literally keeps track of millions and millions of different NICs in their states . It's an amazing system .

But what Azure Route Server does is it gives the capability for bring your virtual router , bring your Meraki , bring your Cisco , bring your Palo does speak BGP , but it does a crap job of it . So we would see some of that . It was more like the Junipers and the Viptelas and the Velo Clouds .

It was really the SD routers and they form a BGP relationship with ARS and then ARS will plumb the BGP routes in the fabric table on a per subnet basis with the next hop .

So finally , there is a way to bring these two worlds together , which was , if I import my CSR inside of Azure , its routing table knows nothing about what's happening in the Azure rib , in the Azure Fabric Router not a clue , and Azure Fabric Router has not a clue about what's going on in Cisco . So how do you join these two worlds together ?

It was all static routes and then you run into everything ugly that happens with static routes right , you run into the lack of agility , you run into limitations , you run into the brittleness , you run into the mistakes , you run into just that whole lack of dynamic behavior .

And so that's why the black belts were so gung-ho with Charlie about the Azure route server .

It's like , finally there's a way to bring that SD-WAN device , that router device you pair it with Azure Route Server , and everything that's in the brain of your other overlay , your SD-WAN overlay or your Cisco overlay or whatever , is going to get pushed right inside of Azure . So it's incredibly powerful .

I hope customers are wielding it correctly , because along with great power comes great responsibility , and there's plenty of ways to shoot yourself in the foot with ARS and then reload and shoot your other foot off .

But if it lives inside your subnet and it's part of your address block and ultimately lives in your subscription and your tenant , but Azure is the one pulling the strings underneath , like they pick the VM SKUs , they feed it the control plane , they are responsible for scaling it and rebooting it and curating it and sizing it .

That is absolutely what we call private paths . So Azure Route Server is private paths , firewall is private paths , er Gateway is private paths , application Gateway is private paths , so on and so forth ILB right servers private pass , firewalls private pass , er gateways private pass , application gateways private pass , so on and so forth ilb right ilb is different .

The load balancer is public pass load balancer lives outside of the vnet , then uses a very clever trick , um , to inject its uh back-end awareness into the vNet using . It started out as IP and IP encapsulation and back in the days of Yor , but now it's mostly a VXLAN and in some earlier parts of Azure is also GRE .

So it uses Encap Decap to create a tunnel into the NIC of the virtual machine in the VNet to deliver the data stream which arrives just north of the Tor . So actually every single instance level public IP in Azure is on the Azure public load balancer service . It's massive , it moves terabytes and terabytes of data .

It's really just acting as a BGP route reflector in a creative way . It's very like you said , it's a very powerful tool , but depending on the use case , you know , there are some really cool architectures that you can do with Azure Route Server .

That was , I think , one of the things that I thought was the coolest thing that I saw about it was and I was like okay , it's a route reflector , that's really useful and that's nice , but then the the way you can kind of change the architectures and how you're building your express routes

,

and

things

like that turned out to be very cool .

Azure . We are also huge on the idea that network or no work and that ultimately , customers aren't migrating to cloud to build networks . Networks are a means to an end . They're migrating the cloud for their business critical applications .

This networking stuff is either a speed bump or a brick wall or something in between , right , and so we were very empathetic about that . So I had , and a few of my other peers had , some very strong feelings about the price game . But all the clouds do it . In this case , I think ARS is .

You know , we just feel like at that price point it gates adoption and ease of use .

But it's not meant to be a profit center . If you make networking into a profit center , then it will gate the overall cloud adoption . It's just going to slow down cloud , in my opinion .

Not only has networking been kind of monetized in this weird way that infrastructure people like us were not used to , it's also like when things started , networking wasn't like . It's not like . I think you can make the argument that none of these products , from a networking perspective , are truly innovative . It was always an afterthought .

Uh , as far as , like , adding some familiarity with , with networking back into the component , right , like things like cloud win or tgw v , win , ncc , all this stuff is adding stuff we were already doing on prem into the cloud and allowing you to do it . But now you're potentially paying for throughput .

You know number of the x , number of things that you're doing with it , right , where , like , usually we were just paying license fees and maybe you know , if you're in the Cisco world , you're having to bump up the licensing to get a certain throughput .

But the the like getting paid per per gigabyte is is like a very hard thing to grasp , I think , for for a lot of people in this , in this realm .

There's probably differences , but again in Azure , the way that even services are , the building plans and the way that they meter is very different between , say , an ExpressRoute gateway and VirtualWan , and they're very different .

And if I integrate ExpressRoute into VirtualWan , there isn't any kind of discounting or anything , and so that is a challenge that I think that's an opportunity for cloud providers to continue to refine their model and their go-to-market , which is to make the even if they're going to monetize it .

Opportunity for cloud providers to continue to refine their model and their go-to-market , which is to make the even if they're going to monetize it . And I mean , I understand the reasons why they're running a business . It's highly competitive . They're paying people huge salaries to do this . They have boards and shareholders , I get it .

I still think monetizing the network gates adoption that's my piece on that . Just streamlining the way that cloud networking services are built and consumed , to be transparent about it and try to equalize them , so that again , I'll just pick on these two services . They're both great services , but I've been picking on them all night , so I'll just keep doing it .

The way ExpressRoute builds , once you understand it , it's straightforward , but you have to learn a bespoke language . Virtual WAN is very complicated in the way it bills , but again , very little about the way virtual WAN bills maps to ExpressRoute . So again , I'm learning a whole new billing model .

It's very hard for sellers who are not networking people your regular CSAs and your regular AEs and Azure specialists and ATSs . Azure technical specialists are very strong in compute and application and data and AI . They tend to not dwell in the networking world , right ? So this would be what we would call a call generator , right ?

Gbbs would get tons of calls about pricing and confusion on what's my frigging monthly bill going to look like . And we developed internal spreadsheets with you know , macros and stuff to try to figure all this out . I'm like , okay , we work for Azure , we're networking experts , we have macros in our spreadsheets . What are the poor customers going through ?

That , I think , continues to frustrate customers across the board , across multiple clouds .

So it's weird , because it's like it's a different audience that they just charge more and try to talk about how easy it is , but then , like you said , you get calls because it's broken . Like the GBB gets calls because it's broken . You need someone to come in and actually design it properly . So it's an interesting dichotomy all around .

Stop nicola diving on the data . Man move the data . That's .

. Okay , so before we run out of time , I did want to get your thoughts on kind of more of a trend thing than a specific Azure thing . So Azure has been and we've been reporting on the podcast for the last year . Over the year that we've been doing this , Azure is pretty steadily growing compared to its competitors .

I mean , I'm still thinking 2024 might be the year that they actually overtake AWS as the elephant in the room . What's your feeling about that growth compared to the other CSPs ? Can you maybe put your finger on why it's growing this high ?

I mean , we have our own thoughts , We've voiced them on it before , but I'm very curious your thoughts about why Azure is growing so fast compared to everybody else , or are they ? Do you think maybe they're fudging the numbers or kind of what your thoughts are no , no , I mean they don't cook any books or anything .

They were also really good about keeping a lid on it . So the whole open AI thing and push to artificial intelligence , machine learning has been going on at Microsoft a very long time .

They pay top dollar for some of the best data scientists in the world , but these guys and gals were incubating and incubating and like no one was quite sure what they were doing . It was like all that Apple with the guys building the iPhone . Right , they're like in the secret room somewhere and they will never tell you exactly what they're up to .

So that they played the long game with AI and it paid off . And that was because , again , satya hired the right people , eye and it paid off . And that was because , again , satya hired the right people . He has the right mentality . Amy Hood is really good with money .

She's very good at running a crisp budget and knowing how to intelligently invest and knowing when to pull back . So she's a big part of the recipe . They're very good with their cash flows . This allows them to hire and retain some amazing top talent . So there's that side of the story .

The other side of the story is Microsoft has long held trust with enterprise . So it started with Windows and the proliferation of Windows through all the enterprises .

And then Microsoft did something amazing , which was Active Directory , which was we're going to keep track of all of your usernames and passwords and access , and so when you onboard to Azure , all of your access via Azure Active Directory , which is now called Intra , just follows you over .

So if you own user access and you own enterprise trust and you're a master of AI and you're a master of finance , you know , look out right . So , and of course , productivity , so O365 , I mean , who doesn't use Excel ? I tried Google . What is it ? Google Sheets or something Pissed me off . I couldn't use it . You know , it's just like Kleenex .

Like everyone uses Excel . So like not everyone , but most people , or PowerPoint or whatever or . PowerPoint or whatever , or Word , you know , I mean .

Word Microsoft is really good at playing to their strengths and they know how to sell to enterprise and they have deep , long-standing relationships , and so what they're doing is developing services that they know will cause a tremendous amount of innovation for enterprise .

What Microsoft has routinely sucked at even though there are a few bright spots here is consumer devices right . Windows Phone was a disaster . Xbox stands as a success overall . I think for a shop coming out of Microsoft , xbox has been pretty good . Microsoft is doing good now with the Surface , but remember Cortana that thing never took off .

Right , they've been in that enterprise procurement cycle from the 80s probably , depending on when you started , right , and that was the thing that kind of surprised me , because Microsoft obviously probably the most successful software company of all time to date right , winning the software thing was always an easy grab for them , I think , whereas what I didn't see

coming was them slowly start to win this developer battle . Now People want to develop using Microsoft tools , whether that be VS Code or be Copilot , things like that , and it seems like there's a lot in that area that they're getting right because people like using that .

And I'm curious if you've seen some of that , or do you feel the same way , or where do you sit with that ?

Visual Studio , which was , I think , xander , was heavily involved with Windows Studio and then went over , of course , to be the head of Azure and Guthrie was very heavily involved with Visual Studio . So Visual Studio was a halo product for Microsoft for a long time .

But watching Visual Studio turn from kind of an inner software development tool to sort of like a world-class IDE , right . And so again , microsoft knew okay , we're going to target enterprise with this . We're going to put in features and functionalities that enterprise developers want that make it seamless for productivity .

We're going to put in a lot of interplay between Visual Studio and Azure . So all the stuff I'm developing in Visual Studio I can literally one-click and deploy it into Azure .

He knows all about it , but I was amazed to see how fast it spread and how people started saying you know , it doesn't suck . It was really cool .

But it won't be small , I'll tell you that potentially scary , I don't know , but it won't , it won't be small .

It's that way now and it was that way when I was there , and I really fondly look back on all my times in work at Azure and I wish everyone over there the best .

And they are doing amazing things and you know it's easy to pick on people that are successful as we do , and I think it's exciting Like we all have front row seats to this battle of the giants between Azure and AWS and it's a great boxing match . It's starting to get interesting . We're about round eight , so we'll see .

Hi everyone , it's Tim and this has been the Cables to Clouds podcast . Thanks for tuning in today . If you enjoyed our show , please subscribe to us in your favorite podcast catcher , as well as subscribe and turn on notifications for our YouTube channel to be notified of all our new episodes . Follow us on socials at Cables2Clouds .

You can also visit our website for all the show notes at Cables2Cloudscom . Thanks again for listening and see you next time .