Let me introduce myself first – I’m Dan, one of Sixth Story’s web developers. Back in December I went down to London to the Cloud OnBoard event hosted by Google. The main purpose of the event was to introduce the Google Cloud Platform, its’ varying products and provide professional demonstrations of each in production use. Although I already had an understanding of how some Google Cloud services worked, and had already used Cloud Compute to create VMs and Cloud SQL to create databases, there were some elements that remained a mystery.
Arrival & Registration
Having arrived 55 minutes early after severely misjudging the amount of time it takes to walk from Kings Cross to Kings Place, I had plenty of time to get myself acquainted with the venue, talk-locations and take a mooch around the trade fayre.
Now, the first thing to learn about me is that I’m a sucker for free stuff, I was sold the moment I was presented with my own lanyard and t-shirt. But what I especially liked was that the lanyard had the running order printed on the back; particularly handy to quickly find out which sessions were joined together and which had breaks.
With the self-inflicted lengthy venue lapping finished, it was time for the sessions!
Naturally, the first part of the day took care of the elephant in the room – those that had never laid eyes on Google Cloud Platform before and had no experience navigating around the plethora of options it immediately presents you with. Being led by instructor Ran Shiloni, we were given a demonstration that briefly highlighted the dashboard, each service and their use cases, and at which points of the day they’ll be discussed in more detail.
Even as someone with a small amount of experience with Google Cloud, this was something that I appreciated a lot. When you’re teaching yourself to use platforms such as Google Cloud Platform, Amazon Web Services, or Microsoft Azure, it’s very easy to become overwhelmed and no platforms do a great job of explaining where to start. This usually instills (in me, at least) a constant worry that you’re just not doing it right.
Moving on to “Virtual Machines in the Cloud”, the first service up for discussion, the training really began. As this was one of the services that I’d already used in my time with Google Cloud, it was a nice and easy start to the day. The trainer explained the varying virtual machine options within Cloud Compute and ran through creating a machine accessible via SSH; all whilst further explaining how the platform works behind the scenes.
Following on from this came “Storage in the Cloud”, another element of GCP that I had already (sort of) used. Now, it’s important here to understand that database storage works a little differently with cloud platforms – whilst traditionally for smaller applications you may host a database server on the same machine as your web server, this is heavily discouraged here. Instead, your database server lives inside a storage service such as Cloud SQL, Datastore or BigTable (all varying GCP database solutions) whilst your web server lives on a machine within a Compute Engine or App Engine instance. The two can then be configured to be a part of the same virtual network.
This section also explored two different aspects of storage: File Storage via Cloud Storage, and Data Storage via the varying database services. File Storage, as was explained, is fairly simple – It can be controlled programmatically and via user interface, and any files will be dispersed to various edge locations (different services around the world) so they are geographically close to any user attempting to access them.
For Data Storage, GCP offers a set of services that all accomplish the goal of data storage in various ways. These include –
- Google Cloud Datastore – NoSQL Document Databases (think MongoDB)
- Cloud SQL – Fully managed relational databases (think MySQL, PostgreSQL, MariaDB)
- Cloud BigTable – Integration for “Big Data”
- Google Firebase – A mobile and web application platform featuring authentication, realtime database, storage and machine learning features
The use cases for these aren’t platform-dependent, but application dependent. For example, you wouldn’t use Datastore for a WordPress website, as it’s not relational. Likewise, for applications that don’t need defined schemas, Datastore would be the more appropriate choice. Of course you could always spin up a Cloud Compute VM and run it as a MongoDB server if you’d prefer, but that’s a little outside this scope!
The latter section of the day focused on “Containers in the Cloud”, “Applications in the Cloud”, as well as ML and Monitoring. Containers within GCP are held within “Clusters” under the Kubernetes Engine. If you’re a fan of Docker, or using containers in production, then this is definitely something for you.
With regards to applications, “Containers” are packages for an application that provide a guaranteed environment no matter where the container is deployed. This gives the enormous benefit of having identical environments running in development, staging and production. “Kubernetes” is an open-source platform that performs “Container Orchestration”. In simple terms, containers hold your code, whilst Kubernetes is responsible for making your various containers work together and perform scaling and deployment automatically.
“Applications in the Cloud” refers to the Google App Engine. As explained by the instructor, many people are confused by the difference between Compute Engine and App Engine, whereas it’s actually quite simple: Compute Engine is an Infrastructure-as-a-service system that provides a managed virtual machine for the users to construct in whatever way they like. App Engine is Platform-as-a-service, and provides a fully managed platform with a pre-configured machine and environment. This allows apps to scale and deploy automatically, completely removing server administration from the process.
This system, whilst sounding fantastic so far, has some drawbacks. Mainly, applications deployed via App Engine need to be written in Java or Python, preventing a large proportion of existing sites from making the migration and pushing them towards Compute Engine.
A particularly useful feature similar to App Engine, and one that I have since used in projects, is Google Cloud Functions. This enables the whole “serverless” thing that everyone’s been talking about lately – singular functions with an attached endpoint, written in Node.JS, that are fully managed and run when called via the endpoint. These are incredibly useful in situations where you don’t want to create an entire server just for a singular endpoint, but need some form of server-side functionality such as data or payment processing.
So, what did I think of it all? Admittedly, this was the first event of its kind that I’d been to, I’d never been to a training event or a conference before, so I haven’t got a lot to go on in terms of comparison.
What I can say though, is that I came out of the venue at 6pm with a lot more ideas, plans and knowledge than when I went in with at 8am. Google Cloud Platform can seem overwhelming at first, but the complexity is mostly knowing which service is used for what purpose. I can wholeheartedly recommend further OnBoard training events throughout the year if you’re interested in learning more about how to effectively use Google Cloud Platform, as this drawback is something that the instructor did a spectacular job of highlighting.