/dev/websphere

Extreme write behind with JMS

I've been working with one of our biggest customers and they have a high quality problem in that under extreme load, the grid (WebSphere eXtreme Scale) is holding up just fine. but there is a problem. The issue is the database the grid runs on top of. They are using write behind to asynchronously write changes made to the grid to the database. This basically will only write changes to the database every 5 minutes or 1000 entries depending on what happens first.

The issue is even with this batching occurring, the database cannot keep up with the write load. They could buy a bigger database but all they really use their database for is a disk based log for whats in the grid. They load the grid from the database and then all applications use the grid as the system of record for that data. The updates made to the data in the grid and written back to the database asynchronously.

If the database cannot keep up even with the batching then it starts to fall behind and more importantly, the buffered changes not yet flushed from the grid also build up in memory.

Buying a bigger database box is also kind of pointless as the whole point of the grid was to avoid having to buy a large SMP box to run the database. Scaling up is expensive and database boxes with their SANs that can keep up with extreme loads are not really what we want to purchase. We want the grid to act as a shock absorber so that a smaller database can be used. But, this is proving a problem at this customer just using normal write behind techniques.

The real problem here is databases are not designed to be used like this. WebSphere eXtreme Scale is basically using a SQL database as a write only disk store and frankly, databases are not very good at this.

So, what is designed as a write only disk based store? Believe it or not, a messaging system is. JMS queues are designed to implement two operations. PUT to the queue and GET from the queue and they can do this very efficiently. More efficiently than a database. This is all the grid really needs here. Flushing the writes from memory to disk through a database doesn't make a lot of sense.

The idea here is to put the JMS queue between the grid and the database. This way, the grid can flush the changes to 'disk' faster than before and then we can apply the changes from the queue at our leisure to the database. This decouples the database and the grid. The grid can now deal with flash loads or tsunamis of load when they occur and flush the changes to disk using the messaging system. The database can apply those changes at it's own slower rate because the JMS queue is buffering the changes in a durable way to disk. Thus, we don't need to spend a lot of money on an expensive vertical or horizontal scaling DBMS.

This is very like a seat belt in a car. We're trying to absorb a shock by stretching it out over a longer period of time. The JMS queue allows this to happen. While the flash load is happening, the queue is able to keep up with the grid and everything stays stable. The database is emptying the queue as fast as it can which is slower than the grid. Once the flash load is gone then the grid goes back to normal load while the DBMS can keep applying changes for another couple of hours if need be.

The implementation of this could be a Loader that writes the changes to the JMS queue. A JMS listener can then pick up the changes are apply them to the database. This is basically like the write behind built in to WXS but implemented instead with an external JMS queue.

Best practices for setting up an IBM WebSphere eXtreme Scale Grid

I'm maintaining a live google document with the best that we're seeing. You can see the document at this link http://bit.ly/wxsbestpractice.

There's more to configuring ThreadPools than thread pool size

We just found a customer issue and it's worth talking about. The customer was preloading data into WebSphere eXtreme Scale. They were multi-threading the preload to speed it up. They were using a default fixed size ExecutorService as the pool. They were fetching records from the database and then doing a submit call on the pool to hit the grid.

They were running out of memory on the preload client. The reason is as follows. The thread pool size was fixed. Once those threads are busy then queueing additional items just puts them in the queue. The queue was getting longer and as a result holding more items. Items in a preload case might be 10k records to push in to the grid. Items are big, they can take a lot of space. A lot of space if you are able to grab stuff from the database very quickly.

This means if the thread pool is undersized then the pool will queue up lots of items and when the items are big, your preload client can run out of memory pretty easily. There are a couple of things to do here. But, the first is to fix that thread pool so that this can't happen. If you initialize the pool like this then you'll get a better behavior:

// this means that once there are 3x numThreads jobs queued waiting for
// a thread then it will start running jobs on the submitting thread.
LinkedBlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>(numThreads * 3);

// Once the queue reports that it is full, the CallerRunPolicy will run job
// on the submitter thread.

ExecutorService p = new ThreadPoolExecutor(numThreads, numThreads, 2L,
                TimeUnit.MINUTES, queue,
                new ThreadPoolExecutor.CallerRunsPolicy());

This shows us creating a LinkedBlockingQueue with a specific maximum capacity. I used 3 times the thread pool size but you need to figure out what works best. The major change here is the CallerRunsPolicy parameter. Now, that the thread pool uses a fixed size queue then if the queue fills then normally the pool will throw exceptions when this happens. We'd have N threads + M items on the queue at that point. CallerRunsPolicy means that instead of throwing an exception, the job is instead executed on the submitter thread. This will prevent the memory runaway that was happening in the case I described earlier and will throttle the preload operation itself rather than let it go crazy.

The other things to watch here would be to use larger batch sizes. If you are using WXSUtils.putAll_noLoader to bulk load the items in to the grid then make sure you have around 1000 key/value pairs PER partition. This is a good rule of thumb to start from when tuning things. If you have 200 partitions and a batch size for PutAll of 1000 items then thats only 5 per partition which isn't enough to really start to get the benefits of batching the puts. A number per partition in the hundreds is probably better.

If you have a grid with 200 partitions then a thread pool size of 32 isn't great either. You should at least have the same number of threads otherwise you'd overrun the pool instantly when doing any bulk operation. The default pool size for WXSUtils is indeed 32 and is too low for production. You can specify the size of the pool using a constructor parameter or by editing wxsutils.properties if thats how you are connecting to the grid.

I've already updated wxsutils to configure the threadpool as described above given recent experience. I have not changed the default thread pool size from 32 but thats something I'm considering also. Maybe, I'll default it to one or two times the number of partitions in the grid but bounded by some 'reasonable' number.

Anyway, it's worth pointing out the problem and how it's resolved just for every bodies education. An unbounded thread pool happens not just because of a growable thread pool for example but they can be memory unbounded pretty easily as in this case when the pool cannot service the pool queue fast enough.

Creating disk snapshots of an IBM WebSphere eXtreme Scale grid and why they are really useful

I've been working with a few customers who are using WXS to load large quantities of data in to the grid from a database. This can be quite time consuming as fetching the data from the backend is usually the bottleneck. Loading hundreds of gigabytes of data can take well over an hour. This means that a full grid restart is not something such a customer wants to do a lot given the cost of reloading the data.

The bottleneck here isn't WXS, it's the source data system. Many of the customer scenarios I see use the grid as the system of record. If the grid is down then the data doesn't change. We'll discuss when it does change later.

I've written a utility as part of wxsutils (if you're not using this with wxs then you are missing out...). It will make a disk based snapshot of a grid map. It writes each partition for each map to a file by writing the key/value pairs as JSON strings. Each physical box hosting the grid container JVMs will store all the partitions hosted on that box in files in a particular folder on that boxes file system. The current code does it for the maps you specify. So, just execute the code once for each map you want 'snapshotted'.

Later, the customer can execute the read snapshot code to reload that data set from those files in to the grid. This will happen at grid speed. Each box in the grid will read the local files and load them in to the grid as fast as possible. The bottleneck here will likely be network depending on the boxes.

This approach can save a lot of time in many scenarios:

• The customer wants to cycle the whole grid for maintenance on the WXS runtime or the application artifacts. The customer should snapshot the grid before stopping it and then read the snapshot after restarting the grid post maintenance. This is much faster than a reload from the backend.
• The customers wants during testing to have a grid with a well known start data set. Load it once, snap shot it and then use it to reset the grid every time you want to run a test case from a well known start state.

If the data is changing all the time even when the grid is down then we can deal with that also. Probably the 'best' (and best is a loose word here) way to synchronize a grid with a database is by using a change data capture type product. For example, here is IBMs link. These products watch the transaction logs of a database and allow an application to intercept changes in the data without slowing the database down or using triggers etc. The application listener would then typically make a message about the change and send it to the grid where the grid will process the message and apply the change. This keeps the staleness between the database and the grid to a minimum.

If this listener stores these messages in a JMS queue or MQ series queue then even if the grid is down, these changes are tracked. Thus, when the grid is restarted, do not start the msg listener straight away. Instead do the read snapshot and then start the listener which will down apply all changes since we wrote the snapshot. This allows a delta update of the data in this case keeping the snapshot useful.

You can see how to use this snapshot capability on github at this link.

You will need to add the PerContainerGrid definition to your objectgrid.xml and deployment.xml files and put wxsutils.jar and the jackson json jars also on your container classpaths.

Mobile Applications and FlashLoads, corporations need more modern IT architectures yesterday

I speak all the time to corporate customers with well known and busy web sites. Typically, they see under 200 page views/sec. Maybe, a large one has a million logins per hour. The load curves for those systems usually resemble a repeating bath tub with a peak in the morning then a long trough until lunch time, another peak, then a trough till they leave the office and so on.

The advent of mobile browsers and mobile applications on devices like the iPhone, Android and Blackberry are changing this load profile. The trough isn't so deep any more. There is more average load simply because people on an impulse can bring up a mobile application and check something out. They don't need to be sitting at a desktop anymore.

A higher trough isn't so bad. People who were betting on consolidation will get a slightly smaller payback because as average utilization of servers rise, the potential to consolidate them falls. This is a small negative. The higher trough is small news though compared with whats going to happen to peaks. We have a new phenomenom here, the FlashLoad.

FlashLoads

We've all heard of flash floods. The stars align, the heavens open, and we get severe sudden massive flooding of a piece of land. The advent of wide spread smart phones and the availability of corporate mobile applications to make accessing their infrastructure easier is about to invent a new IT term. The flash load event.

Imagine the following scenario. A bank has a mobile application. It's a big bank, 20 or 30 million customers. They have a successful iPhone application downloaded to 6 million iPhones. Sounds great? But, lets say the stock market crashes. Everyone sees it instantly, CNN's mobile news application sends up real time notifications to their iPhone, they don't even need to be watching TV or listening to a radio. The phone is all they need to be aware of whether Kim Kardashian wore green as soon as she stepped out just now or that there is a stock market crash. What do the people do? Why, they crack open the banks mobile application to check the brokerage application. The problem is all 6 million are doing it at almost the exact same time. They were all synchronized through mobile notification technology and other media if they are observing. It's a flash load.

Corporate IT systems are usually not designed to handle a million concurrent logins let alone 6 million. They are usually not designed to handle 6 million concurrent users pulling up their brokerage account details or entering sell orders from mobile phones at the same time. The velocity of a flash load event will be fierce. The load will ramp up almost vertically if it's triggered by a media event (Cable show, Twitter, Facebook, TV, Radio, mobile notification service). Companies with auto provisioning systems won't be able to keep up. Provisioning more virtual machines takes time, minutes for the virtual machines to start, operating systems to boot, middleware to start up and so on. Meanwhile, you are getting beaten with a massive surge in load and it's likely not going to be pretty. By the time those extra resources are provisioned in, it's already over. Companies that consolidated resources have a lot less headroom than those who don't. You can't expect the headroom when non consolidated resources run at 10% while consolidated ones run at 50-60% load. The headroom just isn't there until the extra provisioned resources arrive and it won't be instantly.

Caching is a possible solution to some of these problems. The closer to the user that you can service a transaction using a cache then the less of the infrastructure you will touch with each 'transaction'. Caches can usually handle a lot of load, tens of thousands of requests/sec even on blades. A little investment here and having the data preloaded or warm in the cache could be the difference between a severe outage and a working site. I don't think it's a question of whether to cache or not, it's a question of cache or crash.

The cloud may not save companies here either. Very few corporate applications can run in a hybrid cloud/private data center mode. The cloud also has limited capacity. If the major banks used Amazon EC2 to host servers, a flash load event may even strain their ability to provision ec2 instances to try keep up. They are all looking for extra capacity at the same time. It's like the recent credit crisis but it's a mips crisis instead.

I think mobile applications will allow customers to check their accounts and details in a much more accessible and convenient way than the Web ever did. But, with the availability of instant information in our society through mobile devices, they also bring the potential for a new phenomenon. The flash load. Be prepared once you start shipping mobile applications for your public facing services. It's great to see a successful smart application getting millions of downloads but remember as your success measured by the number of downloads grows, the potential of a flash load is also rising fast too. Be prepared before you discover the limitations of a traditional multi-tiered architecture. It's not just a matter of adding REST services or similar, you need a flash load strategy also because it's guaranteed to come along eventually. It's cache or crash.

State of the art multi-master replication in IBM WebSphere eXtreme Scale 7.1

IBM WebSphere eXtreme Scale already supported a single grid running in multiple data centers, even over a WAN. This was an implementation of CP (see the CAP theorem for details). We've just released V7.1 and are now the only product on the market implementing both single grid across multiple data centers as well as now supporting mirroring independent grids over WAN links.

Multi-master Replication

This new feature allows a customer to host a grid in multiple locations connected through user defined links. Each grid is fully independant and runs it's own catalog service. The locations need to have the same grid defined with the same number of partitions and map/template definitions. The customer can create a link between two locations and from that point forward, WXS will try to make both locations identical. You may also see locations referred to as domains in the documentation. This isn't just a trigger forwarding changes from one side to the other like the competition, this is true replication. If you create a link between a location with data and another empty location then WXS will copy the data from the non empty location to the empty location automatically.

These replication links are bi-directional. Changes made on either side of the link will be propagated to the other side. Besides, the simple topology of two locations, more complex topologies can be constructed. For example, a 'line' topology is easy to implement. If we have 3 locations, A, B and C then make a link between A and B and B and C and all three locations will be replicating to each other. C will get changes from A through B and A gets changes from C through B. A ring topology can be readily constructed also by closing the loop by creating another link between A and C. A ring has the advantage over a line in that changes can be pulled either way around the ring (we do both ways simultaneously actually). This means a link can fail and data can still be pulled the other direction. Rings are more durable than lines for this reason. Changes are sent around the ring in both directions and the latency before changes from a node A appears on another node is dependent on how many links are between them.

Hub and spoke topologies can also be constructed using the same approach. Imagine a location H as the hub. Locations around the hub can simply create a link between themselves and the hub. For example, three locations A, B and C. We would make links A-H,B-H,C-H and this gives us a simple hub/spoke topology. You can use links to create almost any topology you want. If a link goes down then replication is suspended along that link until it restarts.

This is not queue based replication

WXS does not use a queue for replication. We use an approach using constant memory independent of how far back a location becomes out of sync as well as the number of links defined to other locations. This basically means you don't need to worry if a link is down for a while, you won't run out of memory buffering changes like some of the competitors would.

No gateways for replication

Each container JVM communicates directly with like shards in the other location. There are no gateways to define. If you want to define a concentrator then just make a 'fake' location with a link to the left grid and the right grid and presto, it's a gateway but you don't need to make one.

Collision Handling

Collisions are a way of life with a distributed system using AP characteristics. WXS uses a arbitrator to resolve collisions. It has a default arbitration algorithm which simply picks the change from the lexically lower location name. Very simple but will likely be enough for many customers. WXS can also use an application provided arbitrator that makes a new version reconciling the conflicting versions received. You should designate one location as the principal arbitration location so there is a single 'truth' resulting from any collisions.

Summary

The multi-master support in IBM WebSphere eXtreme Scale V7.1 complements the existing state of the art single grid multi-data center support already proven in the product. It allows data centers to be more independent and still provides application level consistency through arbitration. It's implementation is very scalable and it's designed to use constant resources regardless of the topology or reliability of the links between locations. It's also built in to the product.

I'm looking forward to working with customers to exploit both styles of multi-data center replication.

You can read more about multi-master replication in the V7.1 info center.

Bloom Filters for efficient fraud detection with IBM WebSphere eXtreme Scale

I've written and uploaded a Bloom Filter implementation and uploaded it as part of the wxsutils library I keep on github. You can look at the source code here. If you want to use it with your WebSphere eXtreme Scale project just grab the jar from here and add it to your class path.

A bloom filter is best explained elsewhere in terms of how it works. The use cases for where it's useful are worth going over again here though.

Cassandra uses a bloom filter to track all the keys where are stored on disk in a space efficient data structure, i.e. the bloom filter. It uses this to avoid disk I/Os that would otherwise be used looking up keys definitely not on the disk.

Another more customer friendly example is a fraud detection scenario. Lets say you're a credit card company that has the spending history over 6 months of all your customers. You want to catch purchases to vendors that are not in that history. One way would be to keep all the customer vendor history in a database or in a datagrid and check if a new transaction is for an existing relationship. If not then you'd escalate it for scrutiny. For a large credit card company, this can easily be billions of rows. Lets say 200 million credit cards with 200 vendors each? That could be a lot of memory.

A better approach would be to create a custom bloom filter for each customer. The bloom filter is initialized for the number of actual vendors the customer deals with, maybe 200 vendors on average. Each vendor is then added to the bloom filter. This filter is a byte array when this is done. It's about 256 bytes. Pretty small to store 200 vendor strings, no? This filter can then be loaded in to a DataGrid and when a new transaction comes in, the filter for that customer can check with a 97% accuracy whether the vendor was used before by the customer. This is very accurate and was achieved with a huge memory saving and we can improve the accuracy further at the expense of memory if needed. This is the beauty of bloom filters. This example can be used for:

• Tracking unusual telephone numbers for cell phone fraud
• Cities/zip codes that the card was used in
• Categories of vendor the customer deals with (i.e. electronics is common but not motorsports)
• and so on.

Basically any time you want a check a list of things for whether something is present or not present then it's a very memory efficient way to do this.

Another use case would be a security system that wants to track every password every used by a user and try to prevent them using one every again or prevent a customer from using banned passwords. A bloom filter could be used to track existing passwords or the list of banned passwords and allow those lists to be checked quickly without taking a lot of memory or disk space. It has huge advantages in the existing password case as the passwords are not physically stored, the bloom filter is like a fixed size set of password hashes.

IBM WebSphere eXtreme Scale customers can create Maps keyed by customer name whose value is a Bloom Filter. A WXS agent can be used to quickly check if a vendor or some related entity probably not in the 'list' of valid things for that customer. A batch job can generate the bloom filters from the actual vendor data and the grid can be preloaded with the resulting bloom filters periodically. The actual vendor data stays out of the grid.

Security is also improved with a Bloom filter. The grid is not storing any sensitive information. The actual vendors the customer deals with are NOT there. The bloom filter is just a bit array that can be used to check if a vendor is not there, it's not a list of vendors that could be hacked.

Bloom Filters are a very useful data structure to save memory as well as CPU path when checking lists of things for exclusion. Applications can use DataGrids such as IBM WebSphere eXtreme Scale to build extremely scalable, high performance systems exploiting techniques like BloomFilters for fraud detection as well as other scenarios.

memcached versus DataGrid, dumb server versus smart server...

Memcached is a pretty popular free open source distributed cache. It's pretty unique compared with the commercial data grids in that it has a completely unique design.

Memcached is basically a dumb server. This means it's a process running on a Linux box typically which accepts client requests for keys and returns the data. Updates and deletes are also supported. This is ALL the function in the server, hence, dumb server. The client is the only piece which is 'distributed' or even knows about other servers. The clients typically get a collection of host:ip addresses (they all NEED to use the same list) and the clients hash the key over the set of online servers. If there were 4 servers running then all clients will hash data for a key over these 4 servers. Clients will write data for a key K to a particular server using this hash algorithm. One server.

Now, thats what memcached does out of the box. Note, there is no replication on the server side. If a server fails then the clients will hash keys over 3 servers but this changes everything from a hashing point of view so it's likely you'll get a very high miss rate as it's unlikely keys still hash to the same server as before given the modulo part of the hashing is now 3 instead of 4.

Clients work around this by adding a consistent hashing layer on top of the normal client. This works better and writes may be written to a server and the next server in the hash ring. This slows down writes by 2x but allows some recoverability when a server fails. The next server in the ring has the data from the dead server so it's not as bad as before BUT if this server also fails then now the cache has lost the data. It's not replicated remember, it's just written twice. After the first server failed, the clients write changes to the next server and the following server in the hash ring. The new next server in the ring does not have a copy of all the data. It was never written there. It will just have new changes since the failure. There is no active replication going on here.

Most of the materiel on the web shows various workarounds to try to make memcached 'reliable'. A lot of the facebook engineering blog entries focus on this aspect. What they had to do to make it reliable. This works for facebook but won't work in general because I don't think the majority of customers are structured like they are from a build your own mentality. I was talking to someone from one of the big internet shops last week and they always run two memcached clusters for HA. If a server in cluster A fails then they stop using cluster A and switch to B. This works but thats a 50% loss in hardware because of a single failure.

Smart servers

Commercial data grids like IBM WebSphere eXtreme Scale are very different. They handle making the data fault tolerant on the server side with built-in replication and elastic scale out and scale in. Their clients understand the server side data layout or routing. If a server fails with WebSphere eXtreme Scale then no data is lost. The software actively maintains replicas on other servers. Clients that stored an entry with a key K before will still find it. It just works. You don't need consistent hashing on the client, our client does it using routing tables instead. Adding more server processes causes the product to automatically redistribute the minimum amount of data to leverage the new memory/CPU and network available through the new JVMs.

The smart servers allow proper replication which means that the cache isn't as brittle as the memcached cache when servers come and go. If nothing ever fails then the memcached approach works but the potential cache hit rates over time if multiple failures occur mean it can be a liability. The last facebook entry I read on this showed them crawling the logs to try to recover lost data to make the 'next server' more complete. They get this issue and are jumping through hoops to handle it but again, most commercial customers won't do this. They expect the product to do this sort of stuff like replication and they view it as table steaks.

So, memcached for sure has its uses but it's got some limitations which need a fair bit of work by its users to handle correctly if its not exactly what you want or risk some bad scenarios as the cache hit rate climbs. It's very, very fast but you gotta remember, it's not doing much either... No transactions, no consistency, no replication, no isolation and so on. If you don't need these features then it's pretty fast but if you do need this stuff then it starts to slow as you add code on the client side to try and compensate for the limitations.

Cool site: http://www.highscalability.com

Lots of cool articles on large web sites here. Recommended. Click here.

Classifying XTP systems, scale up and scale out transaction processing

A lot of people may think that eXtreme Transaction Processing (XTP) is a new thing. I disagree. XTP systems have been around as long as computers have processed transactions and the definition of what extreme is has been changing with Moores law. In the 70s/80s/90s, TPF/CICS/Tandem/Encina/Tuxedo systems defined XTP and still are. They handle thousands of flight reservations, credit card authorizations per second, bank account deposits/withdrawals. Mainframes were viewed as the ultimate transaction processing systems and for certain type 1 workloads they still define state of the art even today. In the last ten years a new style of XTP has emerged with companies like google, yahoo etc using tens of thousands if not millions of servers provided hyper scalable applications for the web. Investment banks doing algorithmic trading have similar issues with a market data event explosion. Exposing corporate business applications on an ESB as a corporate service or on the web has also caused workloads to increase to surprising levels. This doesn't redefine what XTP is or make the other systems suddenly not XTP any more. It's a new style of XTP. I'm going to try to define XTP as two basic types, Type 1 and 2 with Type 2 having two further subtypes, 2a and 2b.

I think the market for transactional systems can be classified as follows:

Type 1: Non partitionable data models
This is implemented using traditional big iron systems with stateless application servers fronting them. The data model isn't cleanly partitionable and the only way to scale up the datastore as a result is a large SMP or mainframe. Applications can run adhoc queries or joins over the data model making partitioning difficult if not impossible. The data model doesn't fit a constrained tree schema. This is what I call type 1. These will scale until the database saturates. This is just fine for a lot of customers. It's your classic 2 tier architecture. The kink here is that if the data model isn't partitionable then it's extremely difficult to convert to a Type 2 system. But, for a lot of customers, the load level will not reach that point so again, thats fine. If there is no business need to provide hyper scaling then thats great and traditional client/server, two tier architectures have, are and will continue to work perfectly for these workloads. These systems can still process thousands of transactions or maybe tens of thousands of transactions per second. They just may not be able to process hundreds of thousands or millions of transactions per second and they probably will never need to so there is no need to redesign (if even possible) or architect these systems.

Type 2: Partitionable data models
Here, the data model is a constrained tree schema. This means it can be relatively easily scaled out as the data model and transactional data access pattern fits on to a partitioned architecture cleanly. We can divide type 2 in to 2 further sub types.

Type 2a: Partitionable data models, limited need for scale out

Just because the datamodel is a CTS doesn't mean we have to run out and build these applications with products like extreme scale. These systems can start off looking a lot like a classic type 1 and may never need to evolve past that. The big thing with a type 2 system is that moving from a type 2a to a type 2b style architecture is relatively easy given the data model and transaction types suit partitioning and so can leverage modern technologies like Extreme Scale or its competitors. Other technologies in this space are Apache Hadoop HDFS/HBase, Amazon SimpleDB, or Microsoft Azure scalable data services. There are two types here which I call 2a and 2b.

Type 2a are applications that don't need hyper scale out. Even if their business grows to its maximum size, a large SMP box or 390 can host the database for the application. The implementors of these applications have choices. They can write them traditionally with a SMP database and a stateless front end. This will work just fine for a lot of applications. As the load increases then they may switch to an in memory database and keep going but eventually that box will max out also. Next, they could shard the database and run multiple instances with application level routing. This requires a lot of infrastructure to automatically handle failures and database shard placement etc as described in the blog entry. Another option is to use a Extreme Scale like product between the traditional database and the application in combination with write behind and scale out the app tier and extreme scale tier. This will provide most customers in 2a ALL the scalability they would need. A small percentage of customers may still saturate the database on a large SMP and technologies like SolidDB could be used or a manually sharded database/SolidDB could be used.

The transistions are:

• Database + stateless app tier
• Sharded database/In memory database + stateless app tier 
• Database + eXtreme Scale (IMDG) + grid collocated or front end stateless app tier 
• Sharded database/in memory database + eXtreme Scale (IMDG) + grid collocated or front end stateless app tier.

Type 2b: Partitioned data model, full on hyper scale out
Finally, we have 2b. 2b is full on scale out architectures. I think the biggest difference between 2a and 2b is that the relational or sharded relational database gets replaced with Amazon SimpleDB or Hadoop HBase etc. The architecture and all it's middleware components are fully elastic. These are designed from the ground up for hyper scalable systems. These are architectures which automatically can scale to thousands of boxes while managing their availability and elastic scaling automatically. Products in this space are automatically sharded databases (don't exist right now to my knowledge), Extreme Scale and its competitors, Couch DB, Apache HADOOP, HDFS,HBase and for lower qualities of service, caches like memcached etc.

Scale out companies (over the last 5-10 years) traditionally have started with 2a systems. That was easiest and as their business became more successful and grew, they transitioned to 2b. Today, if someone was starting a business like that then given the availability of cloud services like Amazon EC2 etc then such companies would likely start with a 2b from the start given the availability of these technologies.

Summary

So, in conclusion, having these classifications for XTP workloads is useful. It clarifies and separates the various types of applications in to two broad camps. It also shows where technologies like WebSphere eXtreme Scale fit most cleanly and it's in 2a/2b. It can be used in type 1 systems but the lack of a partitioned data model etc complicates this significantly.

Cloud is an interesting trigger in that it's current availability moves the starting point for from 2a to 2b for many startups I think.