December 11, 2007
@ 11:27 PM
Comments [1]
Why arbitrary tier-splitting is bad
I got a couple of emails with questions reagarding  my previous post on Volta. So here's another go at explaining why dynamic-tiering is not a good move - this time in technicolor.

Let's start with a simple illustration. The diagram below represents a typical local component(A) in its environment. As a component that works locally, it has access to other local components which it interacts with. These can be objects it created by itself or objects that where injected to it. The likely design for local components is to have a chatty interaction - After all objects can talk to instances of other objects quite easily.



Now enters Volta (or any other  such framework - and I've seen a few. I am  ashamed to say but I even wrote one about 15 years ago) and says we'll just mark things we want to execute on a different server and everything would be fine. What you get is something like the illustration below:



We have the same number of interactions - only now all the interactions between A and its (used to be) near environment requires serialization, network interaction, possibly encryption, authentication, authorization and what not. You can imagine that this type of interaction can have a heavy hit on performance and scalability if it wasn't pre-designed somehow.

This is a bit of hand-waving so let me also give you an example from a real project. About 3 years ago I was invited to consult in a project. This was the kind of project that interacts with real things like sensors etc. I'll use an automated irrigation system to illustrate its architectural components. One type of component is "Things", these represent real devices you can interact with like sprinklers, soil sensors etc. Things represent the logical state of the real devices and cannot talk to each other. When two Things need to interact -e.g. we want to turn on the sprinkler if the soil is dry, we introduce another architectural component, we'll call it "Interaction" which looks at the state of the Things and can then act upon it. The last major type is "Services" (not services in the SOA sense) e.g. we can have a Service that reads the weather. Services can't interact with Things directly, but they can interact between them and they can interact with "Interactions". This particular system had dozens of Things, Hundreds of "Interactions" and "Services". And the tiers/process boundaries were as follows:


Interactions have to know about changes both in Things and Services so messages keep flying around this system to keep the Interactions in sync as well as propagate decisions made by Interactions. The outcome of this "smart" design is that every status change in a Thing results in an order of magnitude more messages to react to the change is status. I was brought in to find a way to find a way to get in-order reliable messages flow fast enough between the different tiers. I did my best and left -what they didn't want to listen to, and the better solution is to give a lot of thought about related Things , Interactions and Services and bundle them together into "tierable" component. The interactions within these "chunks" would be local and would then inflict a whole less messages on the system. In our example it makes sense to bundle the four components (sprinkler etc.) into a single tier and possibly the same process and increase the overall performance significantly while also giving us  more cohesive boundaries.




(as a side note I'll just mention that I ran into someone who is part of this particular project a few days ago - They are still struggling with performance and stability problems...)

Anyway, one could argue that frameworks like Volta would allow you to move from the bad partioning to the good one more easily - but this is not really so since when you rearange the components you also have to remodel the messages that flow between the new partitions. Also

This is not to say that having the ability to run a system in local and in distributed modes does not have value - as I said in the previous post- it is the assumption that you can easily move this boundary and still get a viable solution that is wrong. Also if you are going to allow running in local and distributed mode that doesn't have to spell to "dark magic" of MSIL rewrites and compilations.
In another (SOA) project we designed services so that in a small-scale installation you would be able to instantiate services in the same process. Services were constructed as Active Services (i.e. have at least one  thread of control). If you wanted to let two services run in the same process you just had to write a new ServiceHost and a new ServiceBus The new ServiceHost has to provide each service its own thread or thread pull and the ServiceBus has to work inmemory by passing message objects around rather then serializing/deserializing and sending them over the network. On a small installation this works better than multiple processes (but not as good as a system designed specifically to run on a single tier). Note that this is the opposite of what Volta does as it takes a distributed solution and allow it to run locally rather than the other way around.

The other part of Volta is the C# to javascript cross compiler. This may have a future - but it really depends on the attention Microsoft will put into this direction. Google does something similar on its android mobile platform where it takes Java bytecode and translated it into the Dalvik VM. But for Google that's a strategic platform. With MS investments in Silverlight (Which I personally prefer), I would guess the effort in would always lag behind (though I hope they'd get it to be better than it is today)

 
Tags: .NET | Design | Everything | SOA | Software Architecture

« Microsoft Volta - oh my oh my | Home | Make it easy to do the right thing »
Friday, December 14, 2007 5:39:34 PM (GMT Standard Time, UTC+00:00)
Thank you for taking the time to write about Volta. You definitely are right that distributed computing is not easy and that designers should not fall into the trap of forgetting the fallacies of distributed computing. It is easy to see that you have a lot of experience here.

I do want to clear up a few things about Volta that we apparently didn't make clear enough. We do not believe that you can develop an application as if it will run on a single tier and then just sprinkle a few custom attributes here and there and be done with it. More than anything else, programmers need brains. Volta does not claim that programmer brains can be checked at the door. When the programmer wants to divide the application across a particular boundary then things like network latency, new failure modes, concurrency, etc. need to be considered at that boundary. What Volta does is make expressing the transition between boundaries easier. It reduces the accidental complexity of writing all of the boilerplate code to express the programmer's intention. This allows the programmer to focus on the essential complexity of his problem domain -- figuring out how to write effective code for that particular tier boundary.

There are some schools of thought that believe if something is potentially dangerous then make it hard to do so that the programmer will really have to think about it in order to get it done. Volta is not in this discipline of thought. It makes it easier so that the programmer can use more mental power to solve the hard parts of distributed programming.

I assure you as one of the two principle people who worked on tier splitting that we never forgot about the fallacies of distributed programming. They were and are ever before me. This is one reason why custom attributes are used. The intention that a boundary should exist at run time is clearly expressed in the code. This is opposed to automatic tier splitting which uses a combination of static and dynamic analysis to decide on the proper boundary.

Furthermore, you have touched upon the performance problems of the first preview release of Volta. We know it has problems but these are obvious and well known. Our team decided to focus on sparking the imagination for the first release and performance will be addressed later. We have regularly measured and analyzed where the performance drain is going and we are confident that it can be addressed.

Thank you again for the commentary and I look forward to future posts.
Wes Dyer
Comments are closed.