The Endangered Middle-Tier, Part 2

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?
This entry was posted by DevHawk on April 22, 2004. It was posted in Architecture. It was tagged SOA.

Comments:

I can't quote you the exact statistics but I think I can safely say 90% of North American companies are less 100 employees. With that size of company you should easily be able to host a ERP, SCM or CRM type of app on a single server. A disproportionate amount of media space is consumed by trying to resolve the scalability issues of Amazon and Google! Interestingly enough, horizontally partitioned departmental applications, each installed on seperate servers starts to make large companies look like many smaller interoperating companies.
This comment was posted by Darrel Miller on April 27, 2004 at 4:32 AM.
While I agree with Darrel on the numbrer of 'small' companies, I disagree with the conclusion. While these companies have low scalability need now, as the quantity and quality og 'network enabled applications' and the use of Web Services et al, will make scalability and reusability very important topics for the small enterprise. large organizations are already architecting to scale, but the small company is ignoring it, and they will be the ones that will get caught short. We live in a global economy, and the well connected mud hut in lower Slobinia will take business from Main Street if they present a better electronic face. My Conclusion? Architecting and scalability is MORE important to the under 100 member comnpanies then to the Fortune 100 companies. The fact that this represents 90% of American companies just points to the importance to our National economy not to ignore these 'not so low hanging fruit' companies. We need to look at small company architecture as more of a structured approach, where processes will more likely impact the companies processes then in big companies where we try to make the systems work like the users, rather then the other way around. We need to start looking at Small enterprises as nothing more then small node on the larger network, and position ourselves and our clients to capitalize on that. In any case we can be sure that the needs of our small business will be met, either by us, or by our (international and national) competition.
This comment was posted by Tom Vande Stouwe, MCT, MCSD on May 11, 2004 at 1:41 PM.
"While these companies have low scalability need now, as the quantity and quality og 'network enabled applications' and the use of Web Services et al, will make scalability and reusability very important topics for the small enterprise. " I'm confused! Why would the quantity or quality of network enabled applications affect the scalabilty requirements of a small business? Scalability is about the number of transactions, the number of users, the number of clients a company has. The majority of small companies are not small because they are budding Ebay's that are just waiting for their big break. Many are small because that's how the like it, some are small because they don't have the management capacity to grow, some are in a business that just naturally doesn't scale. Most companies don't fail to grow because their IT infrastructure can't handle it. Don't get me wrong, some startups have every intention of becoming big, quickly and need to plan for that. But that is a small percentage of companies. Trust me when I say that I will not be ordering pizza over the web from a 10 man outfit in lower Slobenia any time soon!
This comment was posted by Darrel Miller on May 14, 2004 at 3:58 PM.

Categories

Tags

Series

Disclaimer

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.