Google Onboard Event in Copenhagen
Earlier this week I participated in the “Google Onboard” event in Copenhagen. Not much embedded here – but on the other hand, there is no IoT without a cloud. It was one of the biggest events I have attended in Copenhagen for many years – possibly because it was free. It was marketed as a “Training Event” on GCP (Google Cloud Platform) but it was unclear to me – and many others – whether it was a hands-on programming thing with exercises or a general application overview. It turned out to be something in-between. Jerry Jalava did a fantastic job, going through almost all of the major tools in the “Google Cloud Platform” universe. It was not possible to code-along, but we did see a lot of code.
I would have liked some more context. Luckily, we did get a few good application examples – e.g. “Pokemon Go”. Imagine that you had developed this game to run on some local or normal hosted server, and then – in weeks – the whole world starts to play. What a scale challenge! How to avoid people dropping out due to extended waiting?
Scale, Scale
“Scale” is my key takeaway from this event. Google Cloud Platform (GCP) clearly is about scale in several dimensions. I really liked how a small startup company can begin with a free solution with traffic under a certain limit, and then scale and scale as they get more customers with more traffic – in some scenarios without changing anything in the code. This is the “price-wise” scaling.
Technically you can start with a simple “blob”-like database without thinking much about SQL, and then move over MySQL to the huge “Spanner” and finally to real Big-Data solutions – like the one used for mapping the DNA on 10000 people.
Similarly when it comes to “Program-Containers”. In one end you can allocate a virtual machine running your application in Windows, Linux or whatever – with just the amount of RAM and SSD/HD you need. This is IaaS – Infrastructure as a Service. This allows you to leverage existing desktop applications and may be cloned as more users connect – e.g. using Remote Desktop or an http-connection. Here you pay for capacity – the size and number of allocated virtual machines. At the other end you can deploy applications, written in Java or Python, without thinking about the environment they run in. Here you pay per second (or fraction hereof). These applications can benefit from many Google libraries – e.g. Google Translate or Maps. This is PaaS – Platform as a Service.
While the various databases and program-containers are the most visible parts, Google also promises some nice virtual network solutions for tying applications together as well as “EndPoints” which is a way to manage API’s. You may e.g. create a https-based front that handles security and then forwards requests in standard http to servers created in the various technologies – without bothering with keys here.
Tools
We also saw some nifty tools. Developers like to use breakpoints, but how do you do this on a running server? Surely you can debug in a local solution, but it is also possible to use “breakpoints” in production. This is in reality “snapshots” where all variables etc are copied at the given breakpoint. This may be handy in a situation where e.g. regional settings or network-issues makes it difficult to recreate problems locally. The obvious tool is the web-based IDE (see figure), but there is also an SDK with a commandline. If you are used to git or other Linux tools you will feel at home here. It is possible to assign only a percentage of user-traffic to the new version – effectively using customers as testers – without hurting too many!
Context
Surely all this cloud-technology is mainly about the servers that execute your code – whether it is web-server plugins, databases or business model-code with a REST-API – used from phones or PC’s. This means that you are not tied into any specific content-creating environment, generating HTML, CSS or any other form of GUI. Still, I would have liked to see an example of how this integrates with what we saw. We briefly did see a one-button installation of WordPress that was not run. One way to work is to let content, UI and application developers share a git repo. Code is extracted from this and tested locally, before it is deployed from the SDK with a simple command into the Google Cloud. This handles regions, load-balancing etc. The Google Cloud Platform has an advanced “admin” part that allows different people to do different things.
All-in-all I saw an impressing amount of building blocks that are used by Google in their own solutions, but are now also available for the mere mortals. It seems like Google started the whole Cloud-thing, but have been so caught up in their own solutions (gmail, documents, YouTube, Map, Drive, Photo etc) that they are late to the party when it comes to a standard developer platform. The way I see it, AWS from Amazon (primarily) and Azure from Microsoft has gained popularity while Google looked away – and now Google are trying to make up for this. Even though they are the latest, they have a tremendous advantage from the fact that they can standardize on already existing infrastructure. I really don’t know the other platforms, but if I were to start on “something Cloud” I wouldn’t mind starting with Google Cloud Platform.
Final Words
The overall morale was repeated at regular slides with a quote from Rupert Murdoch:
“The world is changing.
Big will not beat small anymore.
It will be the fast beating the slow.”