PostHole
Compose
Login
Episode 545: John deVadoss on Design Philosophies that Drive .NET/Azure
We talk with John deVadoss about the philosophies underlying the development of .NET and Azure software. We discuss the "Fiefdoms and Emissaries" concept of building loosely coupled systems, talk about strengths and drawbacks and how to build services...
In this episode, host Nikhil Krishna speaks with John deVadoss of NEO Global Development in Seattle about his previous work in the .NET Patterns and Practices and Azure teams at Microsoft. They dive into the software design philosophies that drove these large software development efforts, including the loose coupling approach that was adopted when building .NET. John introduces an interesting mental model, called “Fiefdoms and Emissaries,” which was applied in Azure development where the concept of a fiefdom was used in determining the boundary context for services. The discussion explores how this philosophy should be applied to service interfaces, which deVadoss recommends should be versioned rather than changed, and then considers the concept of an Agent, which is a type of Emissary, as contrasted with proxies. Finally, they discuss service orchestration and the challenges of dealing with errors, compensating actions, and rollbacks.
Show Notes
- Episode 520: John Ousterhout on A Philosophy of Software Design
- Episode 495: Vaughn Vernon on Strategic Monoliths and Microservices
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Nikhil Krishna 00:00:17 Hello and welcome to Software Engineering Radio. This is your host Nikhil Krishna. I have with me today John deVadoss. John leads development for the NEO Global Development Practice in Seattle. He previously worked at Microsoft, and he built the Microsoft digital.NET Patterns and Practices and the .NET architecture strategy groups. He also incubated Microsoft Azure when he was at Microsoft. John launched two machine learning startups, but more recently, he’s a board member at the Global Blockchain Business Council and the founder and head of development at NGD Enterprise focusing on building blockchain development tools. John did his PhD work in machine learning, specializing in recurrent neural networks. So welcome to the show, John. Great pleasure to talk to you. Is there something in your bio that I missed that you’d like to add?
John deVadoss 00:01:15 Thank you, Nikhil. Thank you. First of all, I want to say thank you for giving me this opportunity. Thank you for giving me time, and thank you for the very kind introduction. No, I think there was enough in there, so I will not add any more. Thank you.
Nikhil Krishna 00:01:30 Cool. So, the topic for today is an interesting one. It’s about design philosophies, and as we discussed in your introduction, you’ve worked in pretty large enterprises on, in pretty large departments. Obviously, there are design philosophies that you have encountered and embraced. And one of the ones that we are going to talk about today is some of the design philosophies that drive .NET and Azure development. So, one underlying pattern that you mentioned was the concept of loose coupling, which you said was one of the driving patterns for the .NET and Azure platform engineering. Perhaps for the audience, could you tell us what is loose coupling in your mind, and what is the advantage of loose coupling and why you adopted it in Microsoft?
John deVadoss 00:02:19 Certainly Nikhil. Yes, thank you. I’ll start with a little bit of history, historical timelines, going back perhaps to the mid to late nineties, the early days of service-based or SOA architectures and kind of the early, very early days possibly of even what you might call cloud computing. At that time systems primarily were built in a monolithic fashion, monolithic meaning sort of single system, single app, up and down all the way. What we were trying to do with .NET back in ’99, early 2000, even long before it was called .NET, was to break away, to first chip away and break down these monolithic systems. The idea that systems had to be so tightly interconnected, we believed, and of course now we know in retrospect — you know, at that time was very early in the game — that systems fundamentally should be compositions of services. And the idea behind loose coupling was that these services should be autonomous in their own right.
John deVadoss 00:03:30 And so, if services are autonomous in their own right, then what is an application? An application essentially becomes a composition of one or more of these services. And so, loose coupling as the underlying principle, almost the primary principle, if you will, evolved in the early days of .NET. And of course, it continued to flourish through the Azure incubation, through the Azure development as well. So, I would say much of the Microsoft Dev platform and tools really kind of shifted from a mindset perspective away from monoliths to autonomous services. And of course, loose coupling, you could say was the primary design and architectural philosophy.
Nikhil Krishna 00:04:19 Okay, that’s a great overview. I appreciate the historical context as well. But in your endeavor or in your journey towards this particular architecture, could you talk about a little bit about the challenges that you might have faced or the pushbacks that you might have faced? And maybe also comment about the constraints of the system, because every system obviously has advantages and constraints, right? So, maybe you could talk a little bit about that.
John deVadoss 00:04:47 Absolutely. Yes, and I think you make a very, very good point. The challenges, the constraints certainly, but also the enablers. The challenges certainly, you know much in terms of the mental models, so much mindshare, so much engineering, so much developer share has had been focused on single-system monoliths that even the idea, the notion that somehow we could build applications differently, that they could be compositions of services, was an alien concept. And the first, I suppose the obvious question was why, why do we even care? And, and remember, this was about 20 plus years ago. It was still very early in the days of the internet. And the notion that entities would collaborate, would cooperate across the internet was still lacking, right? And that was kind of really the “aha!” as more and more people saw the possibility of connecting across and over the internet until then, the intranet was the king.
John deVadoss 00:05:51 And so you could argue, why do I care about services, about loose coupling? But once you broke this sort of, this abstraction that connectivity was going to be over, the web, collaboration was going to happen over the web, and interconnectedness, interoperability was going to be a driving imperative, I would say that’s really what drove the, the shift. In terms of challenges, the interesting piece, Nikhil, was there were some people who took it overboard, sort of went extremely overboard. And they said everything is a service, everything, right? And so, very interesting as I think about it, right? You had this sort of almost what you might call a microservices philosophy. Everything, every component people assume would become a service. And of course, what happened then was that composition becomes very expensive, right? So there has to be some fine balance between how you define the boundaries of a service.
[...]