John Reynolds's Blog

Is the End of Tiered-Based Computing in Sight?

This morning I came across a whitepaper from GigaSpaces entitled: Space-Based Architecture and The End of Tier-based Computing

Perhaps the most widely adopted style of software architecture is the N-Tier architecture... the separation of concerns based on stacked tiers of functionality. The "Three-Tier" architecture is perhaps the best known N-Tier approach, with functionality separated into Presentation Logic, Business Logic, and Data Access Logic.

The premise put forward by GigaSpaces is that N-Tier solutions are hitting a wall in terms of scalablity, or more specifically that the increasingly complicated schemes necessary to scale an N-Tier solution are hitting a roadblock.

The basic approach to scaling an N-Tier solution is to deploy multiple instances of any Tier that is having trouble meeting the necessary performance goals. For example, if the EJBs in your Business tier can't keep up with the requests from your Presentation tier, then deploy copies of the EJBs on additional servers.

This approach to scaling an N-Tier application works pretty well unless you need to deploy many copies of your Business tier... the middleware necessary to deploy the EJBs and to load balance requests becomes increasingly complicated, not to mention the overhead incurred when sending messages to remote tiers.

GigaSpace suggests a different approach to scaling, which they have christened Space-Based Architecture:

"Space-Based Architecture (SBA) represents a new model that combines distributed caching ("Data Grid"), content-based messaging ("Messaging Grid") and parallel processing ("Processing Grid") for transforming existing tier-based applications into linear, dynamically scalable services. These new middleware components are implemented on top of a distributed shared memory space that provides common clustering, high availability, location transparency and consistency services across all tiers."

Radically simplifying SBA (you really ought to read the whitepaper), the gist seems to be that tiers are not deployed separately. The tiers required to process the application logic are grouped into a single logical processing unit, and scaling is achieved by running multiple instances of those units on multiple machines. To contrast this with the typical approach to scaling an N-Tier application, instead of creating multiple instances of the tiers, the approach is to create multiple instances of the application:

"The power of spaces comes from not having to separate various parts of an application into discrete physical runtimes — and then wiring those together in complex, hard-to-scale, and performance-consuming tangles of middleware. A space doesn’t care if an application has been “tiered.” Whether it has or not, the same program code will instantiate multiple times on the same machine or on multiple machines automatically — and even dynamically - in response to runtime parameters like CPU utilization." - Nati Shalom - CTO, GigaSpaces Technologies

So what do you think? Is Space Based Architecture and the emergence of Grids and Service-Oriented Architecture going to change the way most software architects approach their designs... or is this just a niche that won't make much of an impact?

Comments

• It is certainly something well worth considering. A while ago I drew some architectural diagrams where the space-based one came out a lot cleaner. The main advantage is that you just post a task-defining object to the space and trust that the right service picks it up, i.e. no wiring, not even a name of a service needed, just the "message".
  The flip side is the space itself becoming a SPOF. You may have several instances, but if one goes down, the tasks in it are delayed, so you need to monitor for that happening. Also, you would need to monitor for pile-ups of certain tasks and start instances to handle them, which may not be entirely trivial.Another variation of the same pattern is to use messaging brokers with discovery mechanisms.So to try and answer your question, I believe that asynchronous computing is an important tool in the toolbox, as are discovery mechanisms, but there still is no golden hammer.

  Posted by: tobega on August 15, 2006 at 11:12 PM

• it's just new names for the same thing...

  Instead of a web tier, a business logic tier, and a database tier, you get a web service, a business logic service, and a database service.
  

  Posted by: jwenting on August 16, 2006 at 10:42 PM

• Many enterprise deployments with application servers actually have a copy of the app (web, bl and database logic) all together. Probably they have a separate physical database server but I don't see that changing with SBA.

  App server vendors have also started to catch on to this and are now providing better partitioning support (WebSphere for example) precisely so one can replicate the app stack and potentially split the database too.

  I think SBA is a bad name because it's hinting at the underlying technology used by GigaSpaces rather than describing the architectural pattern that is really the big deal. Further, it looks like the app vendors and others (Tangosol) have also caught onto this and are doing similar things. So the question becomes, which programming model and associated API's do you prefer?
  

  Posted by: dancres on August 17, 2006 at 07:24 AM

• Dancres,Your posting mirrors my own experience... We always deployed the full application stack on each app server.The difference really seems to lie in how easilty an application stack can be deployed on an additional server, and if this process can be automated to add and remove servers in response to the current load.This will become more important if SOA catches on, since there will potentially be a lot of Services to dynamically deploy-JohnR

  Posted by: johnreynolds on August 18, 2006 at 09:00 AM

• JWenting,Very good point... I suspect the "End of Tiered Computing" title of the whitepaper was chosen to attract attention.The issue is more about deployment of components, rather than advocating a return to monolithic applications.-JohnR

  Posted by: johnreynolds on August 18, 2006 at 09:02 AM

• The "space-based" pattern proposed by GigaSpaces shares some qualities with some other well-known
  solutions to scaling but adds some interesting side-effects.

  In my view, Space-based architecture can be compared to other architectural choices that share some common qualities:

  Transparent Partitioning and Co-location of:

  Events
  Work (logic and effort)
  Data

  
  Such a pattern might be dubbed TPC-based architecture.

  One of the things I often mention when I speak about using spaces is the reduction in mapping logic and effort when the space is used to enable distributed applications.
  For instance in many cases databases can be partitioned and can contain stored procedures, giving them some of the TPC-based architecture qualities.
  In addition, databases are sometimes used as shared memory where the primary pupose of a particular write to the database is to place some data into a shared environment as a layer of interoperability between application constructs.
  The resulting mapping code between all the cooperating constructs to and from the database can be a burden. (not to mention the overhead of using a database for this purpose)
  I have also seen databases used as a checkpoint mechanism for transient data that has no long-term place in the system.
  This use of a database as a state-management solution "guarantees" reliability of state during a business transaction but at the cost of extra code and extra connections to perhaps the wrong kind of resource.

  When an application leverages a space or similar vehicle as the state-management and interoperability platform, the constructs involved are able to share Objects.
  This can reduce the mapping issues often associated with other shared resources. Reducing the lines of code you write. Behavior exposed through those objects can also be leveraged in terms of construction of legal instances and even work logic to be performed.
  It is these additional things that begin to encompass the totality of the space-based architecture. The breadth of what we offer almost demands that we use a specific term such as space-based when we refer to what it is people do with our technology. (Owen takes a breath)

  As enabling technologies, our implementation of the TPC-based architecture utilizes:

  
  Mobile code through a code-base enabled master-worker pattern where tasks containing work can change over time and be routed to the optimal location based on their state (allowing transparent co-location and partitioning)
  Intelligent, Adaptive, Service deployment and runtime management (allowing transparent yet deliberate co-location through our declare-able
  clustering/co-location of managed services [not to be confused with our space clustering]).
  An easy to configure and highly abstracted clustered JavaSpaces implementation. (allowing transparent yet deliberate partitioning and co-location of state, events and work)

  Note the use of "Transparent" seems to focus on the developer role and to what is visible to the author of the compile-able code artifacts. "Deliberate" refers to the author of the non-compiled code such as the various XML descriptors used to wire services together.

  
  Orthogonal to the TPC-based architecture we have additional features and benefits including:

  Integration with Spring (allows transparency of implemention)
  JDBC, MAP, JMS, HttpSession, etc APIs (allows increasing transparency of implemention)
  Space API (allows extremely powerful and simple programming model)
  C++, .NET support (allows increasing transparency of language)
  policy-driven dynamic service management (allows additional scaling and fault-tolerance for the entire system)

  
  The combined effect is the success story of choosing GigaSpaces. It is sometimes all of this that we attempt to encapsulate in the term: "Space-Based Achitecture".

  John, you mention an interesting point with regards to complexity and the redistribution of it.

  I agree that complexity never quite goes away in a distributed environment and if it seems to go away
  it is usually at the cost of some critical capability to influence the behavior of the stuff that makes up the application and the supporting infrastructure.

  I write more about that topic here

  Owen Taylor

  Director: Worldwide Technical Communication
  GigaSpaces Inc
  http://jroller.com/page/owentaylor

  Posted by: owentaylor on August 26, 2006 at 11:33 AM

• Owen,Thank you for the overview... If I might spin things from my own warped viewpoint:TCP-based architectures are seeking to completely separate application functionality concerns from scaling concerns.Write the application logic to accomplish the designated task, and leave it to the runtime infrastructure to figure out the best way to deploy the components across the available processing nodes (based on processing load).This is a tall order to accomplish, but it certainly does seem worth pursuing.-JohnR

  Posted by: johnreynolds on August 26, 2006 at 02:59 PM

• Nicely done! You have a gift for brevity and concentrated expression.
  Just be careful, we do not confuse anyone by using the well-established acronym TCP -as in TCP-IP. If we can agree, let us use the term "TPC-based architecture" in our discussion.

  : )
  
  Owen.

  Posted by: owentaylor on August 26, 2006 at 10:41 PM

• SBA in a nutshell

  Hi All

  I apologize for being late in my response – I was a way for a long family vacation and I was quite surprised to see all the comments about things related to SBA (Space Based Architecture) and how this relates to what I refer to as, "End of Tier Based…"
  
  Since most of the comments that I saw was based on one or more interpretation of what we referred to as SBA I thought that it would be best if I'll clarify what stands behind it rather than responding to the specific comments.
  
  SBA is a combination of patterns that we have seen chosen by different users using different technologies: Java EE, JavaSpaces/Jini, SOA, and Caching to build highly scalable applications.

  The purpose of the SBA in general is to provide a new and common architecture based on the experience of writing scalable *stateful* applications.

  The architecture itself is generic and is not necessarily tied to a specific product, however as you can imagine we (GigaSpaces) happen to implement that model ourselves which is also used as a proof of concept.
  I personally don't believe that anyone could talk intelligently about any architecture without experiencing it himself with real customers and real applications.

  The main idea behind the SBA model is to build the application out of set of processing units and scale it out by adding more processing units without changing the application code and without forcing the client to be aware of any changes in the amount or location of the processing units i.e. from a client perspective the set of processing units looks like a single server.

  One of the important elements in achieving this goal is to make each processing unit self sufficient. Self-sufficient means that once a user request has been assigned to a processing unit the processing unit will be able to address that request within its own VM without going to any other server/tier.

  The fact that we consolidate the tiers into a single VM is only a small part of the concept behind SBA and is very far from just bundling an existing tier-based model into a single container.

  Here are few of the concepts that makes SBA unique:

  The middleware is virtualized" – by means of middleware I specifically mean data, messaging, and processing. By means of virtualization I mean that the physical location of all middleware components is abstracted from the application. Routing and load balancing of users requests to the appropriate destination (processing unit) is managed implicitly by the middleware, the same goes for the collocation optimization that is handled implicitly by the middleware. and the distribution of the data across all the units.
  Common clustering – The clustering and high availability model is common to all middleware components (This one of the main differences between SBA and a simple bundling approach).
  Partitioning of data, messaging and business logic in a consistent way.
  Virtual deployment - The use of a SLA driven container which consist of a service management system ensuring the best use of all resources and intelligent fault-tolerance where the backup for a primary server will not ever run on the same box as the primary, nor the act of failing over ever cause undo load to be placed on an already busy server. These kinds of policies and more are monitored and made possible to enforce through the virtual deployment of all services including our space.
  
  
  So where does the space fit ?
  The space is the ideal technology for implementing the virtual middleware. i.e. a middleware that will not be bounded to a specific physical location. The fact that the space can be used for sharing data, messaging, and parallel processing makes it ideal for that purpose. Once the space itself becomes virtualized it can provide the common clustering services to all the tiers.
  

  I find it extremely interesting that a great deal of the above can be abstracted from the application developer using Spring:

  - Spring-Remoting – space based routing – handles the transparent routing of users' tasks and data
  - Spring – DAO and declarative caching – provides abstraction from the data-tier
  - Spring – Transaction – provide abstraction from the transaction implementation
  - Spring Virtual Container – provides a virtual container for a spring application context and enables dynamic deployment of spring applications into a pool of machines

  
  Does all of this mean that you need to re-write your entire application?

  The answer is no – at least not right away. You can do it gradually, in a step by step basis. SBA defines a road-map and a structure of how to do that. In fact, many start by addressing one of their bottlenecks (mostly the data tier) and only then move to the end to end approach. The applications in question are refactored, placed into production with improved throughput and lower latency and then refactored and improved again.

  SBA can therefore be applied to existing applications and with a combination of spring, it can be done with relatively low impact on existing programming models. (especially if you already use Spring)

  It is beyond the scope of this forum (or at least a single post) to provide an exhaustive analysis of SBA as an architecture and implementation.

  In an effort to make this more concrete, I will be posting a demonstration of how you can build a simple SBA application using Spring and also will provide code examples.

  I believe that this will address many of the questions of what SBA really means, stay tuned…

  
  Nati S
  CTO GigaSpaces
  "Write Once Scale Anywhere"

  Posted by: natis on August 27, 2006 at 12:08 AM

• > The basic approach to scaling an N-Tier solution is to deploy multiple
  > instances of any Tier that is having trouble meeting the necessary
  > performance goals. For example, if the EJBs in your Business tier can't
  > keep up with the requests from your Presentation tier, then deploy
  > copies of the EJBs on additional servers.
  > This approach to scaling an N-Tier application works pretty well
  > unless you need to deploy many copies of your Business tier... the
  > middleware necessary to deploy the EJBs and to load balance
  > requests becomes increasingly complicated, not to mention the
  > overhead incurred when sending messages to remote tiers.

  With modern provisioning & application servers, it's as simple as a push-button to roll out additional servers. I don't think this is the point that the paper was trying to make. Most of the scalability issue comes from stateless architectures scaling _too_ well, and the "state manager" behind it (e.g. the db) not scaling to match.

  Peace,

  Cameron Purdy
  http://www.tangosol.com/
  

  Posted by: cpurdy on August 30, 2006 at 07:20 PM

• Next time I'll try the preview button ;-)

  With modern provisioning & application servers, it's as simple as a push-button to roll out additional servers. I don't think this is the point that the paper was trying to make. Most of the scalability issue comes from stateless architectures scaling _too_ well, and the "state manager" behind it (e.g. the db) not scaling to match.

  Peace,

  Cameron Purdy
  http://www.tangosol.com/

  Posted by: cpurdy on August 30, 2006 at 07:22 PM

This work is licensed under a Creative Commons License.