December 12, 2007
Why Arbitrary Tier-splitting Is Bad
I got a couple of emails with questions regarding 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 example. 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.
 " border="0"> .
Now enters Volta (or any other such framework, and I've seen a few, I'm ashamed to say. I even wrote one about 15 years ago). So Volta says "we'll just mark things we want to execute on a different server and everything is fine." What you get is something like the illustration below:
 " border="0"> .
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 three 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., you want to turn on the sprinkler if the soil is dry) so I introduce another architectural component, I call "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:
 " border="0">
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 Thingresults 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.
 " border="0">
(As an aside, 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 in-memory 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 let it 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 translates it into the Dalvik VM. But for Google, that's a strategic platform. With Microsoft's investments in Silverlight (which I personally prefer), I would guess the effort would always lag behind (though I hope they'd get it to be better than it is today).
Posted by Arnon Rotem-Gal-Oz at 04:28 PM Permalink
|
January 2008
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
|
1 |
2 |
3 |
4 |
5 |
| 6 |
7 |
8 |
9 |
10 |
11 |
12 |
| 13 |
14 |
15 |
16 |
17 |
18 |
19 |
| 20 |
21 |
22 |
23 |
24 |
25 |
26 |
| 27 |
28 |
29 |
30 |
31 |
|
|
January 2008
| Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
|
1 |
2 |
3 |
4 |
5 |
| 6 |
7 |
8 |
9 |
10 |
11 |
12 |
| 13 |
14 |
15 |
16 |
17 |
18 |
19 |
| 20 |
21 |
22 |
23 |
24 |
25 |
26 |
| 27 |
28 |
29 |
30 |
31 |
|
|
|
