Is the Middle-Tier Endangered?

Via Udi and Tiago, I found an article on DevX called “Kiss the Middle-tier Goodbye with SQL Server Yukon“. While that article should have been titled “XML Technologies in SQL Server Yukon”, both Udi and Tiago have interesting posts about SQL Server as a platform and the role of the database going forward. Personally, I see two primary forces at work that I believe will drive the middle tier into extinction: Moore’s Law and Service-Orientation.

Why do we distribute applications across multiple systems today? Is it because we like managing multiple systems? No! It’s for scalability. We exploit the fact that tiers of a multi-tier app have different processing loads and scalability methods. Typically, we scale the web/app tier by throwing more servers at the farm while we scale the data tier with bigger servers. However, as Moore’s law increases the performance of these machines, the need to scale becomes reduced, From my experience, many smaller apps could easily run a single machine today (esp. when you consider the increased efficiency of eliminating the network and process hops). Moore’s law will continue increase the headroom these machines provide and expand the definition of “smaller apps”. If you can run the app on a single hardware node, there’d be little reason not to run as much of it as you can inside the database, other than “we might want to scale this out someday”.

Of course, it will be a long long time before Moore’s law can provide a single machine to run a BIG enterprise app (think something like SAP). This is where service-orientation comes in. While some people see services as a way to interoperate BIG apps, I think the future of services is to free us from building BIG apps, or at least from build BIG apps as monoliths. If you figure a BIG app like SAP has hundreds or thousands of business process or resource management operations, you could build that system where each operation is implemented as an independent service. The benefit of this approach is that it is orders of magnitude more flexible in the face of process change than the BIG app approach. If you haven’t seen it, check out the Technology Roadmap session from the Architecture Strategy Series. One of the points that the presenter Norm Judah makes is that “it is the business processes in an organization that are unstable, but the individual things that people do…are the things that are stable.” (He says that during Slide 9 – “Why Do Architecture Projects Re-Occur?”) If you accept that, then having your business processes hard coded in a BIG inflexible app starts to look like a bad idea. These “individual things that people do” (such as sending out invoices) get mapped to services and are aggregated into business processes by some tool we haven’t seen yet (though I think BTS 2004 is a good start).

If service-orientation shreds your BIG app into many pieces, it is highly likely that those pieces will be small enough to run on a single hardware node. In addition, as services communicate with asynchronous messages, they tend to have lower scalability needs than synchronous systems. And since these services all need a database (Pat refers to the database as the soul of the service) it makes sense to run the service inside the database itself. It even makes sense to build a both an application and a messaging infrastructure directly into the database engine. SQL Yukon provides the application infrastructure by hosting the .NET framework and provides the messaging infrastructure with the SQL Service Broker.

However, we need more than faster computers and service-oriented systems to eliminate the middle tier. We also need better management. And not incrementally better, orders of magnitudes better. If you’re going to replace a single BIG app with hundreds of independent services, incremental manageability improvements are not going to cut it. Because we realize this too, Microsoft is investing heavily in the Dynamic System Initiative. If you’re a developer, you’ve probably seen the Whitehorse designers coming with Whidbey. That’s just part of DSI. We’ve got a great architectural overview of DSI as part of our Architecture Strategy Series or you can read more on the DSI homepage.

Do you think the middle-tier will become extinct? If it does, is that a good thing? Obviously, it’s an unknown and a big change, which makes it hard to gauge. But what does your gut tell you?

3 thoughts on “Is the Middle-Tier Endangered?

  • Kent Tegels

    While I agree a lot of what you say, there’s just a couple of points to consider: First, I would opt for a cluster of two or three of really big servers if you’re going to do this. Its too easy for a single failure to take one machine out for too long. Even something as seemingly simple as a network adapter for the backup SAN going out can cause an intolerable downtime in a single server environment.

    Second, you really don’t need Yukon to make this work, you could do it with COM+ and MTS. But you’d have to drag me kicking and screaming to such a place. :)

    I am anixous to see how such systems really work out.

  • John Lam

    I think the technology that will make the middle tier go away is dynamic repartitioning of logical data across physical DB nodes. I believe that Jim Gray at MSR wrote a presentation a while back where he speculated about database servers running inside of HDD controllers.

  • Stephen Johnston

    No. It’s not endangered. Service Architectures are another tool in the kit, it is far from replacing the utility of the middle tier. The service architecture is an interface to the app, not the app itself. The app may still require a 3 tier architecture to run at its best, while the interface may not. Your taking a single aspect of an application, refining it in a void, then saying your conclusion on the refinement of that aspect applies to whe whole which is a quite dangerous way of designing systems.

Comments are closed.