Now, layers are way more popular and friendly to any development environment, because they
- are directly supported with the language and/or runtime
- allow greater flexibility and freedom of interaction between different layers
- are accustomed way of thinking about software
Tiers, in turn, are more difficult to deal with, because they
- require more upfront design
- require complex and/or restrictive and/or expensive (un)marshalling
- require different way of thinking
- deployment and execution independence
- development, language independence
- reuse independence
I sincerely believe that having more tiers is beneficial and it would be great if there was a way of making tiers easier to use in a way similar to layers. And so, guess what, this is one of the ideas behind the Pythomnic (Python framework for building reliable services) - to allow fast and easy way of converting layers into tiers - to mix and match modules in any way.
For example, if there is a cleanly separable function (ex. CPU intensive XSLT transformation) currently allocated to a module or a set of modules in a layer, you may also take one step ahead and declare that this function can possibly be separated to a different tier. For example, instead of calling
pmnc.execute.on("xslt_transformer").xslt.transform(...)the key thing to note is that the way execute.on works, if "xslt_transformer" RPC channel is not configured in an appropriate configuration file, the pmnc call will still be local, but as soon as you modify the configuration file and save it, the very next call will go to the specified server. There is no need to restart Pythomnic on this machine, all you need to do is to copy the xslt module to a separate server and start it there in its own Pythomnic thus turning a layer into a tier.
I do believe that such a feature is beneficial to a middleware development framework.