Latest News from Technical Growth.

Google’s App Engine….mind you don’t get hooked!

The pitch for Google App Engine is both simple, and on the face of it, very compelling. You concentrate on using the App Engine API to write software that solves your business problem and we, Google, take care of all the scaling and operational issues.

What company wouldn’t want to hand over all the boring, complicated stuff to someone else and just concentrate on developing the software that will provide that critical competitive advantage? But life is never that straight forward. There are numerous, sometimes surprising limitations and risks that complicate the task of developing new applications or translating existing applications into the App Engine.

So what are the potential drawbacks you need to be aware of when considering developing applications using the App Engine?

One of the first difficulties I would highlight to companies is the lack of a relational data model. In place of this model, that has served the industry very well for over twenty years (think Oracle,Sybase, DB2, MySQL…), Google have introduced a technology they call ‘Bigtable’ which according to one of their white papers is…”a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an un-interpreted array of bytes.”

So now, when you want to move an existing application to App Engine, or develop a new one, you are going to have to describe your problem in terms ‘Bigtable’ understands. This is not necessarily a bad thing, after all Google run Google on Bigtable and we know how well it runs. It is simply different to how the majority of enterprise developers have been working for a long time now, so there will be at least a period of transition.

Next there is the language choices, or rather the limited language choices, you have available. At the time of writing Google App Engine is limited to Python or Java. That’s it. So if you have a company full of Perl, Php, Ruby, ASP developers they’ll need replacing or retraining. If a new killer bit of development technology comes along on anything other than Java or Python you won’t be using it.

But hey, life is good! You’ve written your software in a way that will run on Google App Engine in one of its two supported languages, gone live, you’re not worrying about data centres, servers and networks, and business is booming.

Then one morning you arrive at the office and find an e-mail from Google in your inbox about a new pricing scheme… ‘You’re putting prices up by how much!! We can’t afford that.’

Only trouble is, there isn’t really anywhere you can turn Your business is completely dependent on Google. You can’t easily move the software anywhere else. No-one else is offering app engine hosting and it’s going to take you months to re-write the software to use traditional relational databases. You’ve no choice but to stay put in the short term and it’s probably going to be costly to get off App Engine in the long term. To make matters worse you now have to explain that to the board and shareholders.

I know I have painted an overly pessimistic picture. It is unlikely that Google will hike prices to a level that will make all their customers leave. However I hope it illustrates that you are beholden to Google, whether it be on pricing matters or technology decisions. You aren’t in charge of your own destiny any more than you were using proprietary technologies in years gone by.

In contrast an approach using cloud server instances, like Amazon EC2 or Rackspace Cloud, offers many of the same benefits. You still don’t have to build data centres or buy and provision networks, storage and servers but if your supplier suddenly ups charges you can move easily to a different provider. Indeed by combining services like Rightscale with EC2 and Rackspace cloud you could even automate this process to the point where you could take advantage of price movements on a monthly, weekly or even daily basis to keep your costs down.

In summary Google App Engine is clearly a fantastic system. The technology behind it has allowed Google to become who they are, but think carefully about the impact using it might have both in implementation costs and future lock in before jumping in with both feet. There are viable alternatives that keep you in the driving seat.

Posted in Articles

Posted by Dean Smith

Website Disaster Recovery Planning – 3 Easy Steps to Help Protect Your Company

Website outages do happen, occasionally even to the biggest, best organised companies so it’s critical for the protection of your revenues that you have plans in place for how to deal with problems. You’d be surprised how many companies do not have a suitable plan in place in the event of their website hosting failing despite deriving some or all of the revenues from their website. The first step is easy… start developing a disaster recovery plan today.

The key in this first step is to create a disaster recovery plan that explains how your company would deal with the complete and permanent loss of the infrastructure that hosts your website. In many cases when something does go wrong it won’t be quite as serious as ‘complete and permanent’ but the plan will allow you to deal with everything up to and including total disaster.

For small sites this may as simple as renting a new hosting package and putting the site onto this new package. For larger sites this might have to include a temporary solution using rented systems whilst new permanent solutions can be purchased and setup. For some sites hosting in multiple places and spreading to the traffic across them provides protection, the loss of one site doesn’t mean the loss of the website.

The disaster recovery plan should identify all the tasks, equipment, people and information you would need to enable you to do this. This will certainly include backups of the existing site (you are taking backups aren’t you?), the software running the site, installation instructions and a whole host of other things specific to your business. It should also include all the contact details for key staff, suppliers and other useful people.

If you haven’t already got a company IT disaster recovery plan it might be an idea to produce this plan in conjunction with a wider business continuity plan that looks at broader issues that might affect your ability to do business such as loss of administrative buildings, pandemics that take out key staff, systemic transport failures that prevent staff reaching their normal place of work etc.

Step two is simply to store the plan securely in multiple locations and review it periodically keep it up to date. Your business environment is dynamic, constantly changing and your disaster recovery plan needs to reflect this.

Finally step three; you must test the plan, preferably once a year, to ensure that everything works. There should be no need to actually turn the live site off to do this but testing the invocation of the plan and allowing everyone to practice their roles will pay dividends in the event of a real incident. In our experience we have hardly ever come across an annual test of a plan that doesn’t highlight some issue, however slight that would have impacted recovery from a real disaster.

So….Plan now. Review regularly. Test annually.

Posted in Articles

Posted by Dean Smith