Google Cloud Roadshow

googlelcoudplatform.pngYesterday afternoon I was at the Google Cloud Roadshow. It was mix of Google trying to sell their cloud services together with much deeper low level programming demos how to use the services, particularly on Android. If the Q&A at the end and my chatting with a few of the attendees are anything to go by, while I personally found the Android parts very interesting, the demos were probably too low level for the audience.

The demos demonstrated how easy it is to create an Android cloud endpoint using Android Studio or via the command line. The command line can also be used to create iOS and Javascript endpoints (libraries). As an aside, it was mentioned that (ADT) support for Eclipse isn’t going away and will be maintained along with Android Studio.


The demos made the generation and use of an Android endpoint look very easy. However, I suspect that, in the real world, as with alternative solutions, once you have to version endpoints, maintain (CRUD), backup and restore cloud data, things will get a lot trickier. It’s also largely proprietary and later swapping out to use some other backend, when the project is mature and complex, is likely to be difficult and maybe prohibitive. However, what you do get is easy development (initially at least), scalability, claimed resilience and affordability that Google said will continue to decrease in price in line with ongoing decreases in hardware costs. I suppose the question you have to ask is when might you ever want to change backends? Future security or service level concerns perhaps?

Google also explained that they have a new service called Managed VMs (currently in preview). Traditional cloud services require server side developers to choose from a limited set of programming tools, libraries etc. This means developers have to make difficult compromises. They often can’t use particular chosen languages, tools or libraries. At the other end of the scale, traditional on demand VMs allow you to run anything on a (Linux or Windows) server. Google’s Managed VMs are a mix of the two in that you can run Google’s tools/services in your own Google VM(s) together with your own choice of languages, tools and services. Google also manage the OS and Google tool updates.

The Q&A at the end was interesting in that just about every question along the lines "Will Google support xyz in its cloud offering and if so when?" produced the answer "We don’t have anything to say about that at the moment". The problem is that Google is predominantly engineering rather than customer driven. They have no medium or long term roadmap. Things might appear or be dropped at will. Therein lies the problem for the Enterprise trying to use Google services. Companies don’t really know if or when xyz will be supported by Google. In the past, enterprises, especially large ones, have relied on the likes of Microsoft publishing roadmaps through partnership programs. The way Google works means they can’t do this.

I think Google’s Managed VMs is a pragmatic response to this problem. It means Google now have an answer in that if they don’t support what you require then you can mix and match with a Managed VM. However, it doesn’t solve the problem of wasted effort if you go off and ‘do your own thing’ in a Google VM and Google then soon release a similar thing under their own tools.

Looking back over the projects I have worked on over the last few years it’s clear there’s no common way companies implement the server side. The number of different server side architectures used is nearly the same as the number of projects I have worked on. Google cloud endpoints add yet another another architectural possibility.