What Microsofts Modeling Strategy Means for Azure
Email
Print
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 ...
