Google Cloud tutorial: Get started with Google Cloud

Google Cloud tutorial: Get started with Google Cloud

From virtual machines and Kubernetes clusters to serverless functions and machine learning APIs — how to navigate Google’s cloud riches

Google Cloud tutorial: Get started with Google Cloud 

When people think of the word Google, they think about search and the immense computational infrastructure that converts your words into a list of websites that probably have exactly what you’re looking to find. It took Google years to hire the engineers, design the custom computers, and create the huge collection of hardware that answers web queries. Now it can be yours with just a few keystrokes and clicks.
Google rents out much of that expertise and infrastructure to other web companies. If you want to build a clever website or service, Google is ready to charge you to run it on its vast collection of machines. All you need to do is start filling out some web forms and soon you’ll have a big collection of servers ready to scale and handle your chores.

Step 1: Set up your account

This is the easy part. If you’ve got a Google account, you’re ready to go. You can log into cloud.google.com and head right to your Console and Dashboard. There won’t be much to see here when you begin, but soon you’ll start to see details about what your vast computing empire is doing. That is, the load on any server instances you’ve created, the data flowing through the network, and the usage of APIs. You can assure yourself that everything is running smoothly with a glance.

Step 2: Identify your need for structure

There are two ways to use Google’s infrastructure: their way and your own way. If you want to leverage all of the genius from Google’s development team, you can pick the tools that offer you plenty of handholding. The Google App Engine, for instance, allows you to build a sophisticated web application with just a few hundred lines of code, all by relying on Google’s curated collection of in-house and open source frameworks. App Engine is a fast way to spin up something quickly.
If you already have your own code or you worry about being locked into Google’s way, you can rent machines by the second using the Google Compute Engine. All you do is choose one of the major Linux or Windows distributions and a few seconds later, you get a root password, access to a command line, and no limitations.
There are options that lie in between. You can customize the App Engine with some of your own code if you like or you can choose some of the prebuilt images for the Compute Engine that already include all of the necessary files for popular applications like WordPress or Node.js. And then there are even more options that lie somewhere in between these.

You’ll probably end up with some mixture of support, perhaps using a fully structured App Engine app for one part and a bit of custom code running on commodity hardware for another. It’s more important that you decide how much you want to do by yourself and how much you’re open to building on Google’s tools.

Step 3: Consider non-traditional approaches

Not everyone needs to build web applications in the same way. Google offers so many options that can often produce great results without writing traditional code. One clever idea, for instance, mixes a Chrome extension with the user’s Google Drive account for storage. The only code runs on the client and Google handles all of the infrastructure. You should think twice to make sure your application can’t be solved by a simpler approach.

Step 4: Choose a machine

It’s almost a mistake to think of this as picking something physical like a tangible “machine.” You’re really just choosing how much CPU power, memory, and disk space you think you’ll need. The Compute Engine offers dozens of standard sized “machines,” or you can choose your own custom combinations.
If you’re looking for more than one machine to handle a heavier load, you’ll probably want to create a Kubernetes cluster with Google Kubernetes Engine. Google developed the tool to make it simpler to run containers across multiple machines. When loads increase, Kubernetes will spin up more instances, and when loads decrease, it will spin them down.

You may also choose not to choose by selecting a more automated path like Google Cloud Functions. Google handles the decisions about machine size for you and bills you by the unit of work that your app does. You pay for each customer’s click at fractions of a cent instead of writing one check for the month.
It’s worth noting that Google has automated other aspects of the process by offering sustained use discounts that kick in after your machine is used for a certain percentage of a month. Other cloud companies require you to commit to large chunks of time in order to get a discount. Google’s discounts appear automatically as your machine runs for a sustained time.

Step 5: Set up benchmarks for your code

One of the biggest challenges is finding the right size for your machine, and Google offers so many options that it can be daunting. I’ve found significant differences of performance that are hard to anticipate. Doubling the number of virtual CPUs rarely cuts the processing time in half. Adding more RAM can dramatically speed up your machine—until you have already added enough to safely hold your data.

The only solution is to benchmark your software with different configurations. One of the Google Compute Engine’s best options is the way you can mix and match the amount of RAM, CPU, and disk space. You’re not limited to predefined combinations. So start experimenting at the beginning and then remember to try again every few months in case the loads have shifted and your performance is different.

Step 6: Choose a data storage option

The Google Cloud offers at least five different options for keeping your data safe, and then you can always implement your own data storage model using its raw persistent disks. The first question is whether you want to use the structure of a relational database built to answer SQL or if you want the more unstructured freedom of NoSQL and object storage.
For SQL, Google has wrapped its own API around MySQL and Postgres. Google Cloud SQL automates your backups, replication, patches, and updates. You write the code that connects to these popular open source options. Google Cloud Spanner also delivers relational structure, but at very high levels of service. Google makes the bold promise of “99.999% availability SLA, no planned downtime, and enterprise-grade security.” (See InfoWorld’s review.)
If you’re more interested in less structured document models from NoSQL, there are multiple options including Cloud Storage, Cloud Bigtable, and Cloud Datastore.
And it’s important to check out Firebase, a sophisticated database that does much more than just store the information. It bundles together much of the infrastructure you need to authenticate users, sync the data with clients, serve files, send notifications, and keep an eye on what your app and the users are doing.
All of these options bill by the amount of data you put in them. The more you store, the more you pay.

Step 7: Browse the Google APIs

It’s almost scary how many APIs are available to the Google Cloud. Of course most of them are available to any computer on the Internet, but it’s hard not to believe (or just imagine) that they just work better inside Google’s cloud.
Many of these APIs can save you plenty of time programming. Google Maps, for instance, delivers detailed maps from around the world for your web application. Cloud Data Loss Prevention will comb through your documents and flag (or even redact) sensitive information like social security numbers. There are dozens of options and all of them bill on how often and how much you use them. Many have free tiers of service for smaller applications and new customers.

Step 8: Check out the data analysis tools

Google has expanded dramatically the number of data analysis and machine learning tools using all of its internal research. You can take any of the data you store and then apply Google’s Big Data or Cloud AI tools to find patterns and signals.
Many of these tools are good for analyzing all of the data gathered from your application. If you’re selling goods, you can look for correlations between the customers and the goods they choose so you can do a better job of anticipating your customers’ needs. If one part of the country loves one color, the algorithms will help you discover this—and less obvious connections as well.
These tools don’t require you to use the App Engine or the Compute Engine to gather the information. You can upload data from other systems.

Step 9: Choose your regions and zones

For many basic jobs, there is no reason to worry much about the actual location of the computer that does the work. It’s called the cloud, right? The metaphor suggests we don’t need to care exactly where the magic happens.
Some jobs, however, do require paying attention for legal or practical reasons. Google has data centers on all continents except Antarctica and Africa. Each continent is divided into “regions” and each region is divided into “zones.” If you want to be sure life will go on when trouble hits, you should rent machines in separate zones. If you want to be even surer, you should run your applications in multiple regions.
The individual products and tools generally work everywhere, but there are some gaps. The App Engine, for instance, is only available in three of the four US regions. Other products like Cloud Storage offer you the option of one or multiple regions.

Step 10: Start to code

Stop reading and get out the editor. If you’re going to be using the App Engine, it won’t take long to get something running. If you’re renting commodity hardware, you’ll have root-level access to the distro of your choice in a few minutes. It only takes a few seconds to turn on a massive amount of computing firepower. What you do with this power is up to you.

Courtesy = https://goo.gl/ovmkaq

Comments

Popular posts from this blog

7 free alternatives to Microsoft Office you can consider

How Google reinvented security and eliminated the need for firewalls