Harry has two interesting points at the end of his article which questions the middle tier as a necessary separate unit of physical deployment:

• Will a service-oriented approach likely result in of boatloads of independent services where today we have one BIG app?
• If yes, will the vast majority of these boatloads of independent services have modest enough scalability requirements to run on a single piece of hardware in the near future?

I'm personally not sure about the first one. Harry used the analogy of database tables which can run in one container if there are no special scalability needs, and which can be split out amongs multiple storage partitions if the need arises. In the services world - whatever that might be as of today - I don't see that we are there, or even near, yet. If you'd create the 100s or 1000s of services which Harry is referring to in his post, than you'll quite likely - as of today - and up in a maintainance nightmare. In fact, if a customer would walk up to me today to do a design review on an business application with 1000s of ASMX services, I'd quite likely point this out as a bad idea and would want to know about their motiviation for doing so.

However: I definitely see where Harry is heading to. I guess we'd need some sort of "container" - like the database server in his analogy - which manages the physical distribution of the services without changing any single bit of your implementation code. We'd need tools that allow administrators to do the equivalent of table partitioning to deploy the services.

This container however can not be IIS as it is today. It needs to allow the administrator to treat a service in a similar way a table is treated by a database server. As a unit of management and as a unit of deployment which might be concentrated on a single machine or split out amongs more of them if the need arises. (Just treating a service "as an ASMX file" is not enough) Furthermore, this new container must be *very* easy to use. A developer doesn't have to think too much (yes, I know, that's simplified and not 100% true) about the physical distribution of databases, logs, indexes, and tables amongst storage media when he issues his first "create table foo" command. If he follows sound development practices, a sysadmin will later be able to change this distribution depending on the scalability requirements. We'd need a similar container and administrative toolkit for service deployment.

For the second question, I think that, yes, most services which are used as backends for business applications don't have massive scalability requirements. But, you know, I still recommend most of my customers to run their services on a two-node W2K3 NLB cluster instead of on a single box. It's not that expensive. And it's not just about scalability. It's also about transparent failover and the ability to apply service packs and security hotfixes to single nodes in your cluster without taking down the whole application.

Your take on it, Harry?