Follow Us

We use cookies to provide you with a better experience. If you continue to use this site, we'll assume you're happy with this. Alternatively, click here to find out how to manage these cookies

hide cookie message

Cloud

Programming Software

Part of a Group Review

Google App Engine review

Article comments

There's something warm and comfortable about using Google's App Engine. What began as a fairly radical tool has slowly matured into an asset that's easier to understand and use, if only because the world has adopted many of the ideas.

The basic architectural themes have remained the same. You upload a small kernel of code with your business logic, and App Engine deploys enough instances to satisfy the demand. If you want to store data or synchronise your work between sessions, you have to use Google's proprietary data stores and caching, but everything else feels fairly standard. The first versions of App Engine used Python, but now you can push up Java WAR files filled with JSPs, servlets and server-side logic. The administration is handled through a separate web interface. Command-line issues are pretty much relegated to the past.

While the architecture and data store haven't changed, the tools are more sophisticated and richer, with more features and buttons to juggle quotas and tune performance. I used the complete set of Eclipse plugins to build applications, but there are similar offerings for NetBeans and IntelliJ. These tools also integrate the Google Web Toolkit with the App Engine, making it possible to do all of your programming in Java. If you can't stand JavaScript or just want to use the same code on the server and the client, the Google Web Toolkit will translate your Java for the browser.

I think the biggest challenges for programmers will be adjusting to Google's non-relational data stores. When App Engine first appeared, there weren't so many NoSQL projects around, and the idea of storing collections of name-value pairs was more of a novelty. Anyone approaching App Engine with a bit of experience with NoSQL won't be shocked at all by the simple solution that App Engine forces upon everyone who wants to keep data around. But anyone who still thinks of JOINs and normalised data will need to break from the table-oriented, relational past and adjust to a new way of doing things.

App Engine offers two classes of the data store, so the architect must decide whether to pay for additional power. The basic model makes one data centre the master and all others a slave. If the data centre fails or starts up a scheduled maintenance, your data can't be stored. You must be ready to live with a "planned read-only period". Many modern web applications (think Facebook) can easily survive these kind of glitches, but applications requiring banklike levels of availability and consistency will need to look elsewhere.

The low rent, master-slave configuration is supposed to be about one third the cost of the "high replication" version, with each low rent write costing about five eighths of the high rent equivalent. The low rent version may be twice as slow on writes as the high replication cloud, then again it might not. You have to be careful with some of these numbers because the mechanism includes lots of hidden overhead. Each name-value pair, for instance, includes all the names as overhead because there's no schema. That's the price you pay for the flexibility to store any old thing in any old row.

For some reason, I found myself fretting about the lack of access to the file system. I realise that the idea is to store the bits as blobs so that App Engine can optimize everything, but I still like the ability to write to the file system for some projects.

One of the biggest changes in App Engine is the appearance of economic reality. While Google heavily subsidised the first crop of applications by offering so much for free, it has slowly been squeezing the free apps and pushing people to pay for what they get. Free apps can now access the data store 50,000 times a day, which adds up quickly if you keep more than a few items in the data store.

The new price list includes a long set of quotas and rates. All seem tiny and reasonable, but I have no easy way to compare them. Is 1 cent per 10,000 reads from the data store a good price? Should I hold out for 1 cent per 12,000 reads? Somehow it seems easier to go to the boss and ask for a box with two quad-core processors, a ton of RAM and some fast disks, then cross our fingers. It's not very scientific, but it's so much easier than thinking through all of the details.



Share:

More from Techworld

More relevant IT news

Comments

Send to a friend

Email this article to a friend or colleague:

PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.


Techworld White Papers

Choose – and Choose Wisely – the Right MSP for Your SMB

End users need a technology partner that provides transparency, enables productivity, delivers...

Download Whitepaper

10 Effective Habits of Indispensable IT Departments

It’s no secret that responsibilities are growing while budgets continue to shrink. Download this...

Download Whitepaper

Gartner Magic Quadrant for Enterprise Information Archiving

Enterprise information archiving is contributing to organisational needs for e-discovery and...

Download Whitepaper

Advancing the state of virtualised backups

Dell Software’s vRanger is a veteran of the virtualisation specific backup market. It was the...

Download Whitepaper

Techworld UK - Technology - Business

Innovation, productivity, agility and profit

Watch this on demand webinar which explores IT innovation, managed print services and business agility.

Techworld Mobile Site

Access Techworld's content on the move

Get the latest news, product reviews and downloads on your mobile device with Techworld's mobile site.

Find out more...

From Wow to How : Making mobile and cloud work for you

On demand Biztech Briefing - Learn how to effectively deliver mobile work styles and cloud services together.

Watch now...

Site Map

* *