By now, everyone has seen the big news – VS2005 Beta 1, Express versions and the new VS2005 Dev Center. I’m provisioning a new VPC to install it on. I’d love to move to VS2005 for all my dev work, but I’m writing a few apps that need to be working in a production environment long before we get to Beta 2, so I’m going to leave those on VS.NET 2003…at least for now. However, there are a few longer-term things that I’m working on that I’ve been wait to start coding on for VS2005 that can now get started.

On the architecture side, we launched a new SOA resource page. As part of the launch, we are featuring an updated version of Pat’s Metropolis presentation and a new SOA whitepaper. The version of Metropolis that has been a part of the Architecture Strategy Series was one of the first times Pat had presented it. Like many presentations, Pat refined his delivery with each new time he delivered the talk. The new version provides a new section that describes SOA as well as a section drilling down on the guidance that the Metropolis model provides. Even if you’ve seen the previous version, you should check out the new version.

We also published a new whitepaper on Service Orientation and Its Role in Your Connected Systems Strategy. It takes a Crawl/Walk/Run approach to describing the approach and technology for service orientation today, next year with SQL 2005 & VS 2005, and further out with Longhorn and Indigo. It also covers such areas as Service-Oriented Analysis, Designing for Change and Extensibility, Service Management and Pattern of Service-Oriented Solutions.

You can discuss the new whitepaper, the new version of the Metropolis presentation or any other aspect of our SOA content on TheServerSide.NET.

Streaming producer presenations from TechEd US have been posted. However, the streaming presenation site has the same lack-of-url-addressability issue that TechEd Breakout session list had. Is it so hard to just post a simple HTML file with a list of all the sessions in a track? <sigh>

Anyway, here are links to the top 5 sessions from this year’s architecture track. For those who could not make it to TechEd (or were there, but missed these sessions) enjoy!

1. Realizing SOA by John deVadoss & Ron Jacobs
2. Data in SOA by Harry Pierson (i.e. yours truly)
3. Patterns in the Enterprise by Gregor Hohpe
4. Improving Application Perf & Scale by Chris Kinsman
5. Building Apps with P&P App Blocks by Wojtek Kozaczynski

Update: The streaming site has been taken down, so none of the links work anymore. Sorry about that. We will be updating the Architecture Strategy Series at some point in the future with at least the Realizing SOA and Data in SOA talks.

Since this blog is now being syndicated on Architecture Center, I thought I should repost links to a recent pair of entries I wrote entitled “Is the Middle-Tier Endangered?” and “The Endangered Middle-Tier, Part 2“. The basic premise of the posts is that as computer hardware gets faster and service-orientation aims to carve our course-grained applications into finer-grained services, the value of running the business logic on a separate tier diminishes greatly. Add an improved programming model to the database (such as the CLR’s addition to SQL 2005) and I feel that, eventually, it will make more sense to run the services in-process with the database instead of on a separate tier. We’re not there yet – in addition to continued hardware improvements, we need a major improvement to the overall management infrastructure – but I think it will happen. The question is, do you think it will happen?

Among the responses to my endangered middle-tier post was this one by Ed Draper, architect evangelist for MSFT. While Ed makes some interesting points, on the whole his argument doesn’t hold much water.

First off, his point about Moore’s law is accurate, yet irrelevant. While Moore’s law does relate to CPU speed, I was using it as an example of the rate that overall computing power improves. Storage capacity and network speed improve along a similar trajectory. 64-bit machines are at the early stages of becoming commonplace. And while it’s true that scalability doesn’t equal performance, having better performing hardware can significantly improve scalability.

(Side note – if we’re going to be truly picky, Moore’s law actually refers to rate of improvement of the number of transistors per IC, which only roughly equates to performance. Intel’s Centrino technology is all about using those increasing numbers of transistors for other things like wireless networking and battery management.)

Ed spends quite a bit of time covering very low level computing concepts such as threads, locks, instruction cache, registers and the stack. I’m not sure why he does this. It almost feels like he only read the first part of my post, stopping right before he got to the part where I wrote: “Of course, it will be a long long time before Moore’s law can provide a single machine to run a BIG enterprise app”. In other words, I don’t expect to run my ERP, SCM, CRM or other BFD enterprise-scale app on one machine!

Ed has missed a basic point of my post that I didn’t spell out as I thought it was obvious: the independent services that make up a BIG enterprise class app can all run on different machines. I’m guessing he missed that point by the way he ended his post:

“Yes, distributed computing is a good thing.”

As Ted points out, it’s not just a good thing, “distributed computing is a necessary thing.” And a system of 100′s or 1000′s of independent services – which is what I’m describing – is significantly more distributable than the multi-tier monolithic applications we build today.

Of course, it is guaranteed that a small percentage of services will continue to need to use scale out techniques to reach their scalability requirements. For example, it will be a very very long time (if ever) before a single piece of hardware could handle the order processing load Amazon.com generates a week before Christmas or the tax return filing load at the IRS on April 15th. This problem isn’t unique to application design. To draw a parallel to the database design world, there are a small percentage of tables that benefit from using filegroups to isolate them on separate drives from the rest of the database. It happens – but it doesn’t always happen. It doesn’t even usually happen. I like Josh’s comment that “the vast majority of people who think they have workloads which require partition for scale are actually indulging in delusions of grandeur.”

The point I was making is that computers are going to continue getting faster and service-oriented systems are likely to consist of boatloads of independent services with only modest scalability requirements. The combination of these two forces drastically reduces the number of scenarios where you need to use multi-tier scale out techniques to achieve the scalability requirements. If you don’t need a multi-tier deployment, then there is a huge performance and scalability benefit to running the service logic in the database process. If you don’t need to scale-out to achieve your requirement, why would you take the performance and scalability hit to run your code outside the database?

It’s pointless to argue that computer aren’t getting faster or that running the code in process with the database doesn’t perform better. Ed (and Ted and Josh and everyone else reading this), I’d love to hear you opinions on the following:

• 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?

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?