A ‘Web Scale’ platform for all. May 16th, 2011 @tomkarren

I’ve spent the better part of the last 15 years creating web applications and SaaS oriented solutions for customers with a broad range of business models.  Together with various talented team members, I’ve been involved in creating projects for customers ranging from large financial institutions, Fortune 500 Enterprise companies like Oracle, Cisco, HP, EMC, and Microsoft, to solutions for SMB’s. Most recently here at MokiNetworks, we’ve created a consumer productivity application called Todo Online, for Appigo.

While the projects have varied in scope and audience, there have been some obvious constants to deal with in every web-based project I’ve worked on. Reliability, scalability, speed, and delivery/support costs are the obvious front-runners as key factors for success in these kinds of projects. Which languages, platforms, servers and systems can be leveraged to maximize the advantages and minimize the pain? For cloud-oriented developers like myself, it’s kind of a quest for the Holy Grail of Internet Computing.

Even as systems have matured for this relatively new model for delivering applications to customers, new problems have emerged. One such problem is the issue of scale. Modern web applications typically work fine with thousands, or sometimes even hundreds of thousands of users. But what happens when your application needs to service millions, or even (gulp) hundreds of millions of users? Even better, what if your application has a fluctuating or global usage pattern? This is what people are referring to when they talk about ‘Web Scale’ types of problems.

It may be easy to roll out a LAMP (Linux, Apache, MySQL, PHP) stack in your office or local co-location, but that doesn’t mean your solution will work for today’s global users. The truth is, to create systems, which can dynamically and reliably scale from small or nominal amounts of traffic to ‘Web Scale’ is not a trivial affair. Oh, and by the way, to make it reliable brings in a whole new set of challenges, like distributing the traffic and data over regional areas which are not subject to the same power, internet and even geological outage issues.

So how does a person or business go about solving these problems without spending a lot of time and money creating the team, process and infrastructure to handle these issues? One promising solution to the problem is found in the emergence of Cloud Computing Platforms from Amazon, Microsoft, Google and others. Cloud Computing Platforms aim to solve the problems of reliability, redundancy, scalability and cost, by combining the massive infrastructure and expertise of these already ‘Web Scale’ businesses, with the cost savings that can be achieved by sharing these large systems with lot’s of customers. It’s a new model for web based computing that creates economies of scale by bringing large, complicated and expensive systems to even larger groups of customers in a shared or ‘utility’ computing model.

Since we started MokiNetworks in the late fall of 2009, we’ve been hard at work studying these new platforms, and putting them to work in various projects. This week, I had the opportunity to attend Google I/O 2011 (#io2011) in San Francisco. My primary focus at the event was GAE (Google App Engine), a topic I’ve blogged about on our site and many other places. GAE is Google’s PaaS (Platform as a Service) based Cloud Computing Platform. Initially launched as a preview solution in 2008, GAE will come out of preview later this year. Based on my experience with it, and the new services which have been launched this month, I can confidently say that it’s a very interesting option for developers and companies to leverage to create the their next killer web applications.

Some of the notable improvements (which I’ll break down later in the post) include the HRD (High Replication Datastore), server Backends, and 99.95% SLA’s for paid applications from Google. Before making these enhancements GAE was notable, but still lacking in some of the necessary elements most developers need. HTTPS support for privately owned domains is still missing, but is anticipated in the not too distant future.

The big news with the HRD is that Google now provides geographically redundant data storage for applications. The HRD improves reliability by distributing data storage across more than 2 (often 3) geographically redundant Datastores. This means that if a Datastore goes offline for planned or unplanned events, your application continues serving data. According to Google Engineers, HRD improves data storage reliability for GAE apps from 99.9% to 99.999%, which is like going from almost 9 hours of unplanned outage in a year to just over 5 minutes. The system uses some heavy-duty computer science (Paxos Algorithm) and infrastructure from Google including ‘Megastore’ which can reliably replicated data between locations in near real time.

The new Backends feature enables developers to implement long running and or high memory oriented processes and requests. Up until this point, developers using GAE have had to use complicated offline processes and other cumbersome techniques when use cases called for tricky, memory/processor or overhead intensive processes to run. This long awaited feature rounds out a very big gap in functionally and enables developers to leverage shared infrastructure for the majority of their tasks, while using dedicated hardware for less frequent intensive uses cases.

Last but not least, for developers and owners of paid applications, once GAE comes out of preview, Google will offer Service Level Agreements and Operational Support. This is welcome news to those of us that would like to use GAE for the enterprise, or for anything that requires a little vendor backing. I’ve been remise to get too dependent on the system without this, and will be happy to pay a little more for the extra assurances.

Google App Engine is poised to become a ‘Web Scale’ platform for all. It’s free to try and cost competitive for paid applications. Here at MokiNetworks, were excited about leveraging Google’s App Engine platform to do good things for customers. As this platform comes out of preview, look for exciting new applications coming from MokiNetworks. We’ve got some interesting solutions in mind tying Cloud and Mobile Computing even closer together. It’s going to be an exciting year!

What is Google App Engine good for?

Talking to people about the kinds of projects we’ve been working on for the last 18 months, a certain kind of question tends to come up. What can you do with Google App Engine (GAE)? Or, could I run my project on GAE? The answer, is a qualified ‘probably’.

Let’s start by understanding what it is and what it isn’t. GAE is not a traditional web stack usually comprised of a database, application server, and or web server. Instead, GAE is a shared, hosted cloud platform, comprised of a ‘datastore’, autoscaling shared servers, and a management console.

I say platform, because with GAE, you don’t even have a defined server. You write your code to be uploaded to the platform and run as a set of scripts in a sort of RESTful hosting configuration. You leverage data storage through a hosted implementation of BigTable referred to by Google simply as the ‘datastore’. Google handles all of the platform and virtualization details so all you have to do is write the code.

The primary difference is instead of a deployed relational database and a defined application server, the Googler’s have provided a virtual serving platform with a programming interface for storing data (called entities) and a grid of servers awaiting requests to be handled for your users.

In a sense, GAE is a highly scalable, request processing platform with managed object based storage. You get auto scaling, managed storage and a nice management console to see what’s going on with your applications.

The main benefit to web application owners and developers is that there are no servers to manage, no databases to worry about supporting and scaling, and you get to tell people that your operations guy is named Google. The potential for cost savings is certainly attractive, especially for new projects or concepts. Without the upfront investment and operational management headaches, ideas and new projects can launch faster and cheaper.

There are however some limitations. First, the application servers are ‘stateless’, which means that they really don’t remember information in-between web requests. This requires developers to use caches and datastores to remember information or to keep server state between requests.

Additionally, since the datastore is really just an object persistance API, you don’t have all the relational and strong query power and consistency that more traditional web systems have come to count on. In almost every case this requires different architecture and design considerations. In some cases, it simply won’t work for your application.
There are of course various other advantages and disadvantages to consider such as low startup costs vs shared platform constraints, and feature limitations (GAE is still pretty new).

So will it work for your project? If your project is a new web solution or API, is mobile related, leans toward RESTful API’s (a topic for another conversation), GAE might be for you. We’ve had some very interesting successes with the platform and we’d be happy to talk to you about our experiences and your project.
-Tom Karren

Google App Engine Project Pays Off

In early 2010 we had some great collaboration meetings with Calvin Gainsford and Boyd Timothy of Appigo about what they call ‘Cloud Sync’. The Appigo team has a very popular iOS (iPhone & iPad) app called Todo. Users of Todo often want to synchronize their tasks off the phone or iPad to ensure they don’t loose their current tasks, retain their history of accomplished tasks and allow their tasks to follow them on the many devices they use (iPhone, iPad, Mac, PC).

At the time we first discussed ideas with Appigo, their customers only had generic options for syncing their tasks off their devices. These generic services do not provide a full feature set compatible with Todo’s and can be complicated to setup and difficult to navigate for users.

Appigo wanted to have its own Cloud Sync service and web user interface. It would give their customers a branded option that is fully compatible with Todo’s feature set, has a similar navigation model and is available on any computer on any network any time. Appigo wanted a new product called Todo Online.

In our early research we considered implementing the sync service and web application that are Todo Online on several different cloud platforms but in the end we selected the Google App Engine. At the time, App Engine was not really open for business but it was progressing well and we were confident that Google would deliver on it promises to make it commercially viable by fall 2010.

While our use of App Engine to deliver Appigo’s Todo Online has not been without a few platform issues, App Engine has greatly improved in the 5 months since we launched and it is providing great value in the delivery of the service.

Todo Online takes advantage of the auto-scaling, high-availability hosting at extremely affordable prices that is provided by the Google App Engine. As of this blog entry, Todo Online has accomplished some amazing things in such a short time. Users have synchronized more than 3,000,000 tasks into the system. It is servicing customers from 166 countries/territories with more than half of the customer base outside of North America. Nearly 200,000 unique visitors have come to the site with a significant percentage of them creating accounts and most importantly, it has already paid for its initial development costs and is running profitably.

While Google App Engine is not the only cloud hosting option and not all applications lend themselves to be written and hosted on App Engine, our experience has caused us to move nearly all projects we do to this great new cloud platform.
Ty Allen