Acme Air List Of Links

Acme Air is a open source sample application and benchmark designed to be cloud native, mobile enabled, and has been run at Web Scale (over 4 billion mobile and browser client requests per day).

Acme Air is currently implemented in both Java and Node with a variety of NoSQL data tier implementations.  The workload has been run across a few IaaS clouds, PaaS platforms and bare metal deployments.  Feel free to learn from the code, documentation and the user community.   We encourage you to contribute your own implementations of different runtimes, data tiers, and cloud providers.

Below is the information that continues to be updated over time.  If you have further questions, add some comments to the blog or jump into the user group discussion.

Blogs

Introduction and Open Source Release - This blog cover the basic ideas of Acme Air.

Web Scale Part One - Historical Perspective and Functional Thoughts - This blog covers how this benchmark differs from other standardized benchmarks in scaling and performance.

Web Scale Part Two - Performance and Scaling Results - This blog covers a single "Web Scale" run of over 50,000 requests per secong (over 4 billion requests per day).

Acme Air Goes To The (Streaming) Movies - The AcmeAir / NetflixOSS Port - This blog covers a side project of Acme Air where we ported the application and operational approach to the NetflixOSS cloud platform.

Main Project Resources

Acme Air Open Source
Acme Air Wiki Documentation
User Group Discussion

Related works

Netflix OSS version of Acme Air
Netflix OSS version of Acme Air ported to WebSphere Liberty Profile
Netflix OSS Acme Air AMI's
Netflix OSS Acme Air running on the IBM SoftLayer cloud


Last Updated:  2013-07-14

Web Scale with Acme Air (Project Scale) - Part Two

In the last blog post, I talked about the thoughts that went into why we created a new workload called Acme Air and the fundamental functional thoughts that went into the performance and scaling work of the benchmark we called internally Project Scale.

Now I want to share results.  You can view the summary report of one of our large scale runs we talked about at Impact 2013.  This report was created by a project called "acmeair-reporter" (not yet open sourced) that takes all the log files across all the instances and processes to calculate throughput, number of errors, latency and per node performance metrics.

Now, let me summarize the results.  The results were collected for a time span of 10 minutes.  While it would be better to run for an hour or two to ensure this is no variability in results over longer runs, we have proven that internally the throughput is sustainable and we wanted to simplify the report.  Also note that (a) the throughput over the 10 minutes is very constant (ignore the beginning and end which is an artificial artifact of the JMeter tool and our reporter) and (b) this was after thirty minutes of warm-up and a second run of 10 minutes repeated the results.

As a top line number we achieved roughly 50,000 requests / second.  These requests are end-to-end mobile client and Web 2.0 browser requests, which means that each request has mobile enablement aspects, REST endpoints, business logic, and data tier interactions involved.  The lightest request requires at least one deep data tier read (to validate the user's session) along with a flight query cache query and all the REST enablement to expose this to a browser and/or mobile client.  When calculated out to 24 hours, this is roughly 4.3 billion requests per day.  As mentioned in the previous blog post, this puts this benchmark run in the "Billionaire's Club".  This means on average for every second of the benchmark run, the application was serving the same order of magnitude previously documented by Google, Facebook, and Netflix.

While many internet companies are talking about the technology they are using to serve such throughput at Web Scale, I don't believe there are any publicly available workloads in open source that someone can run and repeat web scale results.  With the open source application source code, the documented results should be repeatable by someone willing to work with the application and enough operational expense to try the workload on a cloud.  To be fair to the internet companies, their applications are likely far more complex.  That said, the Acme Air application is as complicated as most other traditional benchmarks and far more complete in breadth (especially in cloud first and mobile architectures).  We believe this balance between repeatable benchmark and real world sample application should be beneficial to the world and help us start to focus open community conversation around web scale and cloud workload benchmarking.

We released the results of the "Java" implementation which is based on the WebSphere Liberty Profile application server (a light weight and nimble app server that is well suited to cloud deployments), WebSphere eXtreme Scale (an advanced data grid product that is also suited well to cloud), IBM Worklight (which gave us not only the development and deployment platform for our natively deployed Android and iOS mobile applications, but also gave us a server to mobile enable our application services), and nginx (a popular cloud http proxy with load balancing features).  We used 51 WebSphere Liberty Profile servers, 46 WebSphere eXtreme Scale data containers, 28 IBM Worklight servers, and 10 nginx servers.  We ran the 50,000 requests/sec using 49 JMeter load driver instances all coordinated to run emulated mobile and desktop browser traffic.  We ran all of this on the IBM Smart Cloud Enterprise cloud mostly in the Germany cell.  This is a sum total of 185 "copper" instances.  While the numbers are likely far smaller than the number of servers used in any internet company, for a web scale enterprise application this was a significantly sized application.

Digging deeper into the results, it is worth noting that the report covers many aspects of the performance of the systems (not only overall throughput but also latency distribution, per node system performance, error rate, workload distribution).

Some cool numbers taken from the report:

1. The run had 30 million requests.  Of those 30 million requests, only 4 requests reported errors.  That is 100 thousandths of a percent of all requests.
2. The 90th percentile response time never peaked over 300 ms for these end-to-end requests.  On average we were averaging around 70 ms per request.
3. The main workhorse in the benchmark (the application server) averaged 91% CPU utilization across all 51 application servers.  Likely CPU utilization was actually higher as some outliers at the run start/end are averaged in.  The other workhorse tiers (the data grid containers and the mobile servers) averaged 83% and 62% respectively which means with cluster resizing we could have used fewer servers.
4. We ran both browser traffic and mobile traffic.  In this run we decided to focus more on the browser traffic emulating an application that was just starting to take on mobile users.  On average we ran 5 to 1 more browser traffic than mobile traffic.

One last final cool number - PRICE!

In the previous blog post I talked about the cost of some of the largest scale standardized benchmarks.  I mentioned how one of the largest documented standardized benchmark runs cost approximately thirty million dollars to procure the base system needed to run the workload.  That specific publication ran an order of magnitude larger number of transactions per second than shown in this Acme Air performance result, but the transactions were purely database focused.  The standardized benchmark did not contain the end-to-end mobile app and browser enablement.  The standardized benchmark was also monolithic in nature meaning the failure of the database would mean zero throughput (all or nothing high availability).  With the cloud architecture and breath of features of the Acme Air application, it does not suffer from these legacy shortcomings.  In comparison to this $30 million for the existing standardized benchmarks, our cost was a few thousand dollars in cloud spend per month to produce this Acme Air performance number.  We didn't get an exact cost as we tore down the workload once the performance tests were over, but you can (and should) do your own math of the number of instances we used running 24/7 for a month.  We also achieved this with a team of five people at IBM.  I believe this dramatic reduction in expenses and required human resources is significant and this is the key reason why performance work needs to focus on cloud first deployments going forward.  The cloud and cloud first application architectures have fundamentally changed the world of computing.

Next up .. some words about our availability and transactionality.  Stay tuned!

Some tips/tricks with gradle builds

Blog post is under construction ...

Dependencies

Understanding dependencies ...

./gradlew -q acmeair-webapp:dependencyInsight --dependency javax.servlet

I looked at the output and then saw the exact package it was bringing in:

org.eclipse.jetty.orbit:javax.servlet:2.5.0.v201103041518

And added this to providedRuntimes in my packaging:

providedRuntime 'org.eclipse.jetty.orbit:javax.servlet:2.5.0.v201103041518'

And finally, the specific jar was gone from my war

By adding something to the providedRuntime, you can break things as this instructs the packager to treat the runtime and its dependencies as not required.  I ran into the issue when I told it not to include aws-java-sdk which depends on commons-logging-1.1.1.  Without being more specific, I ran into Spring not starting with the infamous error which was actually this.

You can be more specific in exclusion by adding .jar like:

providedRuntime 'com.amazonaws:aws-java-sdk:1.3.27@jar'

Plugins

Using the application plugin

To use the application plugin here are all four steps for getting it to work with arguments in a multi-project build:

project(':somesubproject') {
  apply plugin: 'application'
  mainClassName = 'org.spyker.MainClass'
  run {
    args = ['someargument', 'asecondargument]
  }
}

./gradlew :somesubproject:run

Notes:  If you only have a single argument remember to put it in an array args = ['singlearg'].  I eventually need to find out how to pass in args via a -P parameter.

Web Scale with Acme Air (Project Scale) - Part One

This blog post is part one of a post about the work we've been doing in the performance space around applications scalability.  While the second part will talk to the results we can share on Acme Air, this first part will cover some of the history and context.

Over the last year, I have been looking at the benchmarking space and how current benchmarks are useful to show scaling of the technologies.  If you look at some of the most popular standardized benchmarks, the scaling aspects are less relevant than they used to be.  In the past it was interesting to prove that certain middleware and data technologies could scale up to larger SMP systems and across clusters of SMP systems.  However, as the hardware systems have gotten larger some of the current approaches to scaling applications have become less relevant (pinning processes to network cards, CPU sockets, memory subsystems, etc.) as most single applications don't need to scale to the size of modern large scale systems and most users can't afford to replicate such complex tuning.  These complex tunings are very error prone for general users and if not applied properly can lead to worse performance than not using them at all.

Also, from a middleware perspective high availability isn't usually tested fully.  Many of the benchmarks do not require realistic high availability in the middle tier, which allows for stateful implementations that wouldn't work under failure.  Meanwhile the data tier remains monolithic and non-distributed.  This means the benchmark competition isn't based on technical merit, but who can buy and optimize the largest database.  In fact some of the most popular standardized benchmarks have documented costs ranging from a few million dollars to in one case thirty million dollars.

For these reasons, we have chosen for existing middleware benchmarks to focus on number of transactions per processing processor core as (a) this reflects true engineering performance work in our products regardless of scale and (b) this is directly related to how people pay for products - any improvement in this metric means cost savings for end users.  Keep this history in mind as we discuss the performance of Acme Air and most specifically the scaling work on Acme Air.  We call the scale up work using Acme Air "Project Scale".

When I looked externally to see who was gauging scale in the world, I found the programmable web's "Billionaire's Club".  This study documents the trend of supporting Web API calls of what used to be browser facing clients and now more and more is not only browsers, but also mobile and business to business Web API's.  If you look at the web and cloud today, the list of use cases and billionaires presented in this presentation better document the scaling that matters today than standardized benchmarks.  I agree with the motivating factors listed in the presentation for why this modern scaling is occurring - mobile and partner web API enablement many times driven by consumer facing applications.  I would add to that the sensors and the internet of things based use cases.  Consider the number of sensors in automobiles, those tracking your bags during airline flights, traffic monitoring, streams of point of sales purchases, etc.  When you put mobile together with the internet of things, the scale of applications growth with new bounds not yet known in typical enterprise applications.  Also, you will note that almost every current billionaire is a "born on the cloud" application.  Cloud is the more typical approach to deployment these days in large scale systems.  Deployment on the cloud changes the approach to running and tuning workloads dramatically over approaches in standardized benchmarks.  Finally, if you look at some of the top billionaires they are documenting through blogs and open source how they are getting there (NetflixOSS and Linkedin for example).

As I looked to see what it takes to scale middleware to the levels shown by this billionaire's club my experience told me it would be important to consider typical enterprise qualities of service - high availability, security, transactionality (when required).  There are many real world examples and benchmarks that did not consider those aspects and when the world discovered the end result was usually a black eye to any existing performance claims.  First on the "billionaire's club" side, many of the companies born on the cloud found success greater than their initial expectations and failed under increased load at some point in time.  On the technology side, a great example was some of the initial MongoDB benchmarking which were not run with more advanced durability and replication configurations.  A funny (and NSFW) video that documents this is the MongoDB is Web Scale video.  To be fair to MongoDB, since those times the benchmarks have been re-run with better levels of durability and availability.  In any benchmark of large scale, the benchmark and technologies employed must consider high availability, security, and transactionality.

Given all of this my team set out to create a workload (that is embodied in the OSS released recently called Acme Air) and run it to levels of scale that would put it in the billionaire's club reaching a few billion mobile and browser requests per day.  We decided early on to do the scaling work in the cloud.  We also made sure we continuously looked at the requirements for security, high availability, and transactionality.  We also decided to do the work in the open (through open sources, discussion forums and blogs) to get the same level of worldwide understanding that the similar billionaire's club members have.

In the next post, I'll document our scaling results of Project Scale.  I hope this context will give you enough background to understand why we are doing this work in the way we are.

Northwest Raleigh Wifi Speeds

Likely not much interest to others, but if you're a remote worker in the NW Raleigh area, feel free to contribute speedtest results.  I'm personally doing this to prove that the Brier Creek Caribou is getting poor service from their ISP.

Brier Creek Caribou Coffee

• 6/10/2013 - 9:45 AM
• Test 1 - Ping 299, Download Speed - 0.44 Mbps, Upload Speed - 0.23 Mbps
• Test 2 - Ping 183, Download Speed - 0.51 Mbps, Upload Speed - 0.36 Mbps
• Test 3 - Ping 193, Download Speed - 0.44 Mbps, Upload Speed - 0.27 Mbps
• 6 other laptops, using www.speedtest.net website

• 6/11/2013 - 10:56 AM
• Test 1 - Ping 53, Download Speed - 0.74 Mbps, Upload Speed - 0.56 Mbps
• Test 2 - Ping 55, Download Speed - 0.75 Mbps, Upload Speed - 0.48 Mbps
• Test 3 - Ping 53, Download Speed - 0.74 Mbps, Upload Speed - 0.67 Mbps
• 3 other laptops, using www.speedtest.net website

• 6/14/2013 - 12:21 PM
• Test 1 - Ping 80, Download Speed - 0.13 Mbps, Upload Speed - 0.52 Mbps
• Test 2 - Ping 102, Download Speed - 0.76 Mbps, Upload Speed - 0.55 Mbps
• Test 3 - Ping 67, Download Speed - 0.51 Mbps, Upload Speed - 0.56 Mbps
• 6 other laptops, using www.speedtest.net website

• 6/14/2013 - 12:41 PM (these tests failed and had to be restarted)
• Test 1 - Ping 380, Download Speed - 0.10 Mbps, Upload Speed - 0.39 Mbps
• Test 2 - Ping 152, Download Speed - 0.09 Mbps, Upload Speed - 0.25 Mbps
• Test 3 - Ping 106, Download Speed - 0.09 Mbps, Upload Speed - 0.59 Mbps
• 6 other laptops, using www.speedtest.net website

• 6/18/2013 - 10:20 AM
• Test 1 - Ping 100, Download Speed - 0.16 Mbps, Upload Speed - 0.63 Mbps
• Test 2 - Ping 93, Download Speed - 0.16 Mbps, Upload Speed - 0.60 Mbps
• Test 3 - Ping 97, Download Speed - 0.30 Mbps, Upload Speed - 0.36 Mbps
• 6 other laptops, using www.speedtest.net website

• 6/19/2013 - 9:15 AM
• Test 1 - Ping 44, Download Speed - 0.69 Mbps, Upload Speed - 0.50 Mbps
• Test 2 - Ping 44, Download Speed - 0.47 Mbps, Upload Speed - 0.43 Mbps
• Test 3 - Ping 45, Download Speed - 0.51 Mbps, Upload Speed - 0.54 Mbps
• 0 other laptops first test, 3 by last test, using www.speedtest.net website

• 6/20/2013 - 1:51 PM
• Test 1 - Ping 52, Download Speed - 0.51 Mbps, Upload Speed - 0.60 Mbps
• Test 2 - Ping 44, Download Speed - 0.49 Mbps, Upload Speed - 0.58 Mbps
• Test 3 - Ping 45, Download Speed - 0.44 Mbps, Upload Speed - 0.37 Mbps
• 3 other laptops, using www.speedtest.net website

• 9/8/2013 - 7:37 AM
• Test 1 - Ping 52, Download Speed - 0.74 Mbps, Upload Speed - 0.66 Mbps
• Test 2 - Ping 52, Download Speed - 0.77 Mbps, Upload Speed - 0.61 Mbps
• Test 3 - Ping 52, Download Speed - 0.53 Mbps, Upload Speed - 0.67 Mbps
• 0 other laptops, using www.speedtest.net website

At Earthfare Brier Creek

• 6/18/2013 - 2:04 PM
• Test 1 - Ping 62, Download Speed - 2.79 Mbps, Upload Speed - 0.65 Mbps
• Test 2 - Ping 64, Download Speed - 2.82 Mbps, Upload Speed - 0.66 Mbps
• Test 3 - Ping 64, Download Speed - 2.86 Mbps, Upload Speed - 0.66 Mbps
• 1 other laptops, using www.speedtest.net website

• 6/20/2013 - 10:22 PM
• Test 1 - Ping 55, Download Speed - 2.63 Mbps, Upload Speed - 0.69 Mbps
• Test 2 - Ping 56, Download Speed - 2.85 Mbps, Upload Speed - 0.68 Mbps
• Test 3 - Ping 56, Download Speed - 2.84 Mbps, Upload Speed - 0.69 Mbps
• 0 other laptops, using www.speedtest.net website

At Bruegers Bagels

• Test 1 - Ping 203, Download Speed - 2.84 Mbps, Upload Speed - 0.12 Mbps
• Test 2 - Ping 297, Download Speed - 2.56 Mbps, Upload Speed - 0.10 Mbps
• Test 3 - Ping 163, Download Speed - 1.85 Mbps, Upload Speed - 0.08 Mbps
• Test 4 - Ping 163, Download Speed - 1.85 Mbps, Upload Speed - 0.08 Mbps
• Test 5 - Ping 1533, Download Speed - 2.66 Mbps, Upload Speed - 0.07 Mbps
• Test 6 - Ping 1433, Download Speed - 0.81 Mbps, Upload Speed - 0.09 Mbps
• Test 7 - Ping 190, Download Speed - 2.45 Mbps, Upload Speed - 0.07 Mbps
• Not sure how devices were connected, using speedtest app on friend's phone

At home (Time Warner Cable)

• 6/10/2013 - 8:22 PM
• Test 1 - Ping 59, Download Speed - 13.62 Mbps, Upload Speed - 0.70 Mbps
• Test 1 - Ping 57, Download Speed - 5.44 Mbps, Upload Speed - 0.77 Mbps
• Test 1 - Ping 45, Download Speed - 8.76 Mbps, Upload Speed - 0.96 Mbps
• Many other devices connected, using www.speedtest.net website

• 6/14/2013 - 2:50 PM
• Test 1 - Ping 28, Download Speed - 13.11 Mbps, Upload Speed - 0.97 Mbps
• Test 1 - Ping 28, Download Speed -  17.18 Mbps, Upload Speed - 0.99 Mbps
• Test 1 - Ping 28, Download Speed -  17.02 Mbps, Upload Speed - 0.98 Mbps
• Many other devices connected, using www.speedtest.net website

My phone (3G)

• 6/14/2013 - 12:31 PM
• Test 1 - Ping 205, Download Speed - 0.3 Mbps (386 kbps), Upload Speed - 0.029 Mbps (29 kbps)
• Test 2 - Ping 203, Download Speed - 0.3 Mbps (325 kbps), Upload Speed - 0.041 Mbps (41 kbps)
• Test 3 - Ping 243, Download Speed - 0.1 Mbps (116 kbps), Upload Speed - 0.071 Mbps (71 kbps)
• Sprint network using speedtest.net android application

My phone (4G)

• 6/14/2013 - 12:35 PM
• Test 1 - Ping 108, Download Speed - 1.182 Mbps (1182 kbps), Upload Speed - 0.745 Mbps (745 kbps)
• Test 2 - Ping 102, Download Speed - 1.716 Mbps (1716 kbps), Upload Speed - 0.796 Mbps (796 kbps)
• Test 3 - Ping 103, Download Speed - 1.555 Mbps (1555 kbps), Upload Speed - 0.733 Mbps (733 kbps)
• Sprint network using speedtest.net android application

Announcing Acme Air .. Performance Sample/Benchmark showcasing Mobile and Cloud at Web Scale

I am happy to announce a project I've been working on at IBM for some time today - The Acme Air Performance Sample and Benchmark.

Background and History

A year or so ago, we started to consider what the future of performance and benchmarking should be.  We specifically considered the following new architectural areas - Mobile, Cloud and Web Scale.  In looking at the standardized benchnmarking space and our own existing benchmarks many aspects of these technologies were missing.  Also, the existing benchmarks were created well before these industry trends existed and after some consideration, we decided it would be better to start from a clean slate than try to adjust existing workloads to these models.  In trying to come up with a story line for the new workloads, we looked for a compelling industry examples of a system of engagement (a term made popular by Geoffrey Moore).  After some consideration, we picked the airline industry.  Consider how the airline industry has already changed with in air connectivity, paperless boarding, and mobile applications that alert you of changing flights plans, etc.  We believe this industry (much like many others -- automotive, insurance, banking, energy, hospitality, health care -- to name a few), has dramatically changed its approach to business process in transformative ways already powered by the always-on mobile connection with their customers, employees, and partners, cloud hosted services, and analytics of the big data streaming from social, mobile and the internet of things.

Inside of IBM we have been looking at an implementation of this sample application within the context of performance and scalability.  We have talked with our customers on how to replicate similar implementations, best practices, and performance lessons learned.  Today we are starting to take that message external hoping to drive customer and partner collaboration around an open source contribution of the implementation at github.

Over the new few weeks now that this is public I plan to blog about the lessons already learned and the future contributions in this space by IBM and our partners.  Let me touch quickly on three core areas and hopefully this will spark interest in others to collaborate.  Feel free to leave comments if areas of this interest you.

Multi-Channel (Mobile)

We have designed the Acme Air services to be multi-channel.  What I mean by this is that we have the same core services offering up similar services to mobile, classic desktop browser and business partner Web API channels.  This means a Acme Air customer would get a consistent experience when interacting with Acme Air regardless of if they were using their laptop, the mobile Acme Air application, or through partners like Travelocity.  We accomplished this with well defined REST API's and leverage the IBM Worklight server technology (a technology component that can offer a secure, scalable native mobile facing environment to the traditional enterprise).

We also have implemented a hybrid mobile UI design across Android and iOS that leverages these services.  The hybrid approach means we can leverage web standards (HTML5, CSS, JavaScript) to provide a natively looking application to the Acme Air customers regardless of smartphone/tablet platform.  We also leverage technologies such as Apache Cordova to get access to mobile unique features (such as location, camera, etc) within the web standard programming model allowing the application to fully take advantage of the mobile decide aspects.

Cloud-First

Cloud is a pretty vague word these days.  It can mean something different to each person who uses the term.  We have deployed Acme Air in about seven different cloud environments.  We have shown it using IaaS plus roll your own services, IaaS plus cloud provided services and PaaS (like CloudFoundry) based approaches.  We have even looked at advanced Web Scale platforms on top of IaaS such as Netflix OSS.  Acme Air has proven itself to be a versatile research tool for cloud given it has adapted well to each of these environments with elastic scalability.

Given how broad this term is, for now let me explain what each of these cloud environments gave us that was similar.  First, our development team around the application never wants to go back to asking for hardware, maintaining that hardware, and paying for the hardware for more than the time we use it.  We have gotten to a point where we expect the environment to be infinite in scope and readily available.  Also, with each level of abstraction provided by the cloud starting at IaaS and growing up through PaaS, we get more and more value from the underlying platform that provide us shorter time to value (less time focusing on the plumbing and more time focusing on our application and it's data).  Truly we have arrived at a model where the computing resources are a utility that can be turned on and off, are always there, and can scale up to our needs easily.

Web Scale

Web Scale is another term that has been thrown around pretty generally in the industry - so it's important to define what we mean.  We looked to the Programmable Web definition.  They have, for the past few years, documented which companies are handling more than a billion Web API calls per day calling this "club" the "Billionaire's Club".  While many of these companies are serving API's that are consumer facing and likely less transactionally critical than class enterprise applications, we believe the enterprises are moving into this space due to the systems of interaction, mobile, and internet of things.  We further believe that we need to refine this space to prove as we demonstrate web scale, that we do it with security, transactionality (when required) and reliability.

Looking at the performance world, lessons learned from web scaling applications are coming from born on the cloud companies such as Google, Twitter, Netflix and Facebook.  The lessons learned are being expressed at conferences between practitioners - not through known reference open source workloads.  In the standardized benchmarking space scale up has become more of a game of how much money can be spent by a vendor both on hardware and esoteric tuning and therefore less valuable to real world customers. By releasing Acme Air to open source along with performance papers over time we hope to fill this void of information helping the industry as a whole understand how to web scale most effectively.

Summary

I'm happy to be able to start to release this story.  I have so much to talk about based on what we have already learned.  I also know that we've only started to scratch the surface of this mobile, cloud performance and scalability story - which keeps me interested every day to show up at work and experiment further and learn.  On our open source github project page you'll find the start of this implementation.  We will have much more to add to this over time (our mobile application, our cloud devops enablement, our load testing scripts, our performance reporters, etc.).  If you are interested, I suggest you go ahead and download, build, deploy and play with what we have already released.  Currently you can try out an implementation written in an all Java stack including the WebSphere Liberty Profile and the WebSphere eXtreme Scale data grid or an all JavaScript version using the MongoDB NoSQL database.  Doing this evaluation now will give you the opportunity to learn before we start adding on to the story.

Essential Apps for Family Communications

Recently I had the need to spend some time at the N.C. Children's Hospital at UNC. I don't want to go into details of the personal aspects of this, but I do want to tell you that this hospital was amazing and I'm a big fan of their nurses and doctors. If you want to read some reports of the amazing things they do, I encourage you to like them on facebook. The stories of what they are doing there will blow you away.  Also, every year I run in the race that benefits them, the Krispy Kreme Challenge, and I encourage you to experience that race as a runner or spectator once in your life.  The K2C is a true bucket list event.

In getting ready for this visit, I loaded up my phone (Android) and Nexus 7 tablet (again Android) with three essential applications to make our stay more enjoyable.  I had games as well, but I wanted to tell you about the "communications" applications I used.  It is worth noting that most of these applications are network greedy.  This wasn't a problem as the NC Children's hospital had great Wifi in the rooms.  I would strongly recommend each of these apps to anyone.  I now also use them to stay in touch with my family when I travel.

Netflix

I am one of the last people I know to have tried Netflix.  In the hospital, they had local TV, but some of the channels were grainy and while they had the typical kids channels, the fact is you can't always expect to find age appropriate TV on.  With Netflix, whenever we got bored, we were able to load up just about every kids television series and first off episode after episode.  I was impressed with such a shared Wifi network that we almost never saw buffering issues.  We did see some freeze-ups maybe twice per day, but it was easy enough to just stop the app and restart.  The Netflix app keeps track of where in the show you are at, so upon restart we were off and watching again.  I'm not sure if the freeze-ups were due to the Wifi or not, but it is worth noting that the Wifi was pretty aggressive about kicking people off (requiring re-signin) that were idle.

Since the visit, I use Netflix to watch some of their original series.  Currently I'm watching Lillyhammer as I'm a big Steven Van Zandt fan.  I have to admit the choices, other than the original series, for an adult are a bit light.  Certainly the kids programming is much more extensive than what appeals to me as an adult.  I look forward to Netflix streaming to expand into more original series as well as movies and television shows.  I personally hope that Hollywood and the TV broadcasters start to release more control of their programming following the digital path to the money like the music industry did.

Install Netflix

Google Talk

Both my older son and I have a Nexus 7 tablet.  While doing cross iOS/Apple and Android video chat is still hit or miss, doing Android to Android through Google Talk works very well.  We used this application to do video chat during the stay to keep the rest of the family.  There was even a point where my sons watched TV together.  They had been planning on watching the Kids' Choice Awards previous to the hospital stay and they were able to watch it together with us in the hospital and my older son on the couch at home.  Even though doing this was a bit of a waste of network, being able to do this made my son's very happy as it was almost like they were at home together.

Since the visit, I have given my son tours of the Las Vegas strip and other interesting locations via this app.  I use this to show live videos of places where a picture isn't enough to convey life in motion.

My google talk was installed as part of base Android.  I assume it would be on your Android device as well.

Voxer

My older son isn't old enough for a cell phone.  We don't want him making phone calls nor doing text.  I do want him to be able to contact the family, so I set his tablet up with Voxer to keep in contact with just our family.  Voxer is the audio over the Internet (and text and pictures) equivalent the old Nextel click to talk.  If the person you are talking with isn't online at the time, you send a short audio message and they will get it once they get online.  If they are online, they can hear it live streaming.  Many times the conversation gets started and it's a quick back and forth set of audio messages, but much like text messages, if there is a few minutes before I respond, the conversation keeps going.  With the uncertain timing of events at a hospital having such a voice based, but asynchronous, communication application was very nice.

Since the visit, I have used Voxer for more than text tours of airports and locations for my family.  I have done walking tours of San Francisco, Washington DC, and Detroit leaving a string of voice and picture messages for my families to consume later.  Sometimes I sent these at times where they are at school or on another coast's time zone so this being asynchronous was key.

Install Voxer

The Cloud

Also note that all three of these applications are either entirely public cloud hosted or have substantial cloud aspects.  I think this shows that the cloud is ready for massively social applications that have strong needs for network speeds and feeds (all of these include video and audio).  Given my focus on cloud I find this very encouraging.  I think the end user commercial world is cloud based and I believe the enterprise is very close behind.