I'm interested in tools and application development. So I'm interested in Oslo and what the Microsoft modeling strategy means for the Windows Azure cloud environment. And I'm also interested in your thoughts on modeling altogether.
In the abstract I'll just say the quest, the ultimate goal, is that we push the limits as much as we can to see how much we can abstract into modeling from the entire life cycle from the analyst to the developer to the person who understands ... from the person who understands the business problem to be solved to the developer who will probably in some cases have to wrap it with code, with some procedural code, to how it gets deployed, and to how it gets managed in an operational environment.
The Oslo folks have been at the leading edge of architecture and starting with a great conceptual vision, and building out from that conceptual vision.
If you look at the ... I'm kind of giving you the sausage factory view here. If you look at Azure, when you have a chance to actually open the hood, what you'll see is it's so fundamentally model-driven in terms of how it operates, and those guys have been working very, very closely together. They aren't syntactically mapped yet, but it doesn't matter, because Don's [Box, a Microsoft distinguished engineer] got some grammar that will map to it or whatever.
But the point is in essence what Azure does is it takes a service model, a very robust service model, that basically says there are switches, there are multiplexers, there are load balancers, there are Web front ends; you just define your roles, you define the relationships between those roles, you say how many of each in a balanced system, you express maximums, minimums, you say I want this much affinity between these roles, I want this much of the replicas of this role, I want this much-I don't know what the word is for anti-affinity-I want these many to be in a different data center far away. Like you have two-thirds of them close to each other and have one-third of them far away. It's a fairly sophisticated description so that the service fabric, so that the operational fabric can take your code and just do it.
We're learning a lot. We're going to learn a lot over the next year from people actually playing with it, but taking it up to that level, you know, you could never do it without modeling. That's just the way it is.
Could we pepper that with procedural ... you know, letting people add code to make intelligent decisions about the replication? Yeah, we absolutely can and we will, but right now it's about as purely declarative as you can get.
But the goal is to get the whole tool chain, starting all the way at the business analyst and all the way through, so we'll see. We're at the point now where we've at least got a common repository between a few of the projects that are going on in-house, and we're moving forward.
It's a little bit difficult. ... We've encountered some challenges on the-not to digress too much-but on the Azure side because we have a fundamental, very fundamental requirement of the system that there be no single point of failure, and the fabric controller itself, if it uses a database as a repository, it really has to. There's too much complexity there for it to rely on, unless it's a packaged subsystem on one node. Because it's in control; the question is if multiple ... if the fabric servers, how does it know which direction ...