[JAZZ MUSIC]
PRIYANKA VERGADIA: Hi, I'm Priyanka Vergadia, a developer
advocate for Google Cloud, and in this video,
I will unbox Google Cloud for you.
Let's say, you are a Cloud architect for foo.com.
How would you build foo.com on Google Cloud?
There are many different ways of achieving the same goal,
and no one way is right or wrong.
Let's use this example to unbox Google Cloud
and to see some of the approaches.
By the end of this demo, you will
understand how to navigate the Google Cloud console
and locate components needed to build any common application
to just compute, storage, database options, and more
such things.
All right, let's get started.
Well, first thing's first.
If you're logged in to the console for the first time,
create a project.
A project is required to use Google Cloud
and forms the basis for creating, enabling, and using
all the Google Cloud services.
I'm going to use this one for our demo today.
On the left navigation, select Billing,
and link your billing account.
You can go to billing any time for an accurate,
up to date picture of your Cloud spend.
You can view all products and learn more about them,
read documentation, work on a quick start,
and even navigate to the individual products.
If you prefer to use the command line
interface from the top right corner,
you can activate Cloud Shell, which
is an online terminal preloaded with utilities
such as the G-Cloud command line tool, kubectl, and more.
Now that we know how to navigate through the console, let's look
into unboxing a generic internet facing application,
foo.com, on Google Cloud.
First, you need a virtual private cloud, WePC Network,
which provides managed networking
functionality for all our Google Cloud resources.
You can see one created here called foonet
with an automatic subnet.
Inside this network, we will create our application
infrastructure.
For our app infrastructure, the web and app servers,
we have multiple options depending on different factors.
Your options are Cloud Run, App Engine, Kubernetes Engine,
Compute Engine, and Anthos.
If I choose to deploy serverless,
then it means more time spent coding
and less time spent worrying about infrastructure
and scaling.
The Cloud Run offers the ability to run serverless containers,
and App Engine is a managed app platform.
If you want to run containerized apps,
but with more configuration and flexibility,
then we would pick GKE.
It helps us deploy containerized apps with Kubernetes
without much of a learning curve,
while giving us the control over the configuration of nodes
we want in our infrastructure.
GKE also offers Autopilot for when
you need the flexibility and control,
but have limited ops and engineering support.
For an application in hybrid and multi-Cloud platform,
use Anthos.
The maximum control option is Compute Engine.
It is straight up virtual machines,
so we can define the configuration of our machines,
depending on the amount of memory and CPU we need.
But this control also means more responsibility
to scale, manage, patch, and maintain them as needed.
In this demo, we chose Compute Engine for our web
and application server.
Now, let's see how we set up Compute Engine to globally auto
scale our foo.com service.
We will see an instance template,
which we call foo-template.
Instance templates are saved virtual machine configurations
used to create identical VMs.
We need a template, because we need
the service to be created in multiple parts of the world as
needed.
In this template, you can see the type
of machine, networking, storage, disk information,
and any custom metadata.
We can either create these identical VMs
individually or as a part of managed instance groups.
Here, you can also see that this instance
template is used by three managed instance groups.
If you click on any of them, or navigate to instance groups
on the left, you will see all the managed instance groups
in three different zones--
Asia, Europe, and US.
Autoscaling is set to HTTP load balancing utilization
of 80%, which brings me to our load balancing.
Load balancers distribute traffic to the servers.
They can be applied to both external web
servers and internal application servers.
Under Network Services, you will see load balancing.
Here, we have created a load balancer with our three
instance groups as backends.
While setting end data in this video
may be different from the demo project,
the concepts and guidance apply.
Cloud load balancing is a fully distributed
and software defined system.
It can literally respond to over millions queries per second
and is based on any past IP address.
What does that mean?
Well, it means that we can define our frontend
infrastructure with a single IP address.
And our global users coming from Asia, US, and Europe
will be served their request from a server that is
as close to them as possible.
This is what our service looks like behind that single load
balancing IP address.
It also offers internal load balancing
for our internal application servers
and offers layer four TCP and UDP load balancing.
Right at the load balancer, we have an option
to enable Cloud CDN to cache the frequently requested media
and web content closer to the user and the nearest edge
location.
This reduces latency and optimizes
for last mile performance for our users.
It also saves cost by fielding the request right at the edge
without needing to send to the backend.
And Cloud CDN would be caching content
stored in Cloud Storage, our object store, where
we store all of our media assets, CSS,
JavaScript-- basically, everything static in nature.
This means that the image we used on our web page
is being served from cache.
While we are on the topic of network services,
Cloud DNS is Google's infrastructure
for high volume authoritative DNS serving,
which offers 100% SLA, meaning it never goes down.
It uses our global network for any past name servers
to serve the DNS zones from redundant locations
around the world, providing high availability
and low latency for the users.
Foo.com might have some media processing functions
for processing images and video files.
It can be deployed on Cloud Functions, which
is a serverless function as a service that scales as needed
and can be triggered via HTTP, Cloud
Storage, and other services.
For asynchronous messaging services,
we will use hubsub, send messages to a topic.
And servers could subscribe to that topic
to receive those messages and send out the notifications.
Now, coming to databases, we have a few choices here.
For relational databases, we have Cloud SQL and Spanner,
which are both managed.
For generic SQL needs, MySQL, Postgres, and SQL
Server Cloud SQL is perfect.
Spanner is best for massive scale relational databases
that need horizontal scaling.
It also supports strong consistency and asset
transactions.
I would say, you use Spanner when
you need the benefits of both relational
and non-relational databases.
For non-relational databases, we've
got three major options, Filestore, Bigtable,
and Memory Store.
The Firestore is a serverless document database that can be
used as DB-as-a-service, easy to set up,
and provides fast results to complex queries in real time.
It also supports offline data and syncs,
which make it a great choice for mobile use
cases along with Web, IoT, and gaming.
Bigtable, on the other hand, is a wide column
no SQL database that supports heavy
reads and writes with extremely low latency.
This makes it a perfect choice for events, time series
data from IoT devices, click streams,
add events, fraud, recommendations,
and other personalization related use cases.
Memory Store is a fully managed in-memory data
store service for Redis and Memcached at Google Cloud.
It is best for in-memory and transient data stores,
offers extremely low latency and high performance.
Memory Store is great for web and mobile gaming,
leaderboards, social, chats, and newsfeed type applications that
require in-memory database caches as well.
Next part of the puzzle is analytics.
We usually have real time and batch data to ingest.
Real time data could be content from servers,
such as click stream data or from IoT device sensors.
Batch data could be from your logs.
Now, these are, obviously, just examples.
Once the data is ingested, we process and enrich it
to clean it up and make it ready for downstream systems,
then store it in a data warehouse for further analysis.
A data warehouse is a storage where you keep processed data.
The data analysts then analyze the data
and create dashboards for broader consumption.
Data scientists can pick up that data from the data warehouse
and use it for creating machine learning
models to generate predictions.
You could also directly ingest data
from storage systems for ML models.
We can ingest the batch data from Cloud storage
and real time data from applications using Pub/sub,
which is a serverless messaging service that scales to ingest
millions of events per second.
Now, data flow can then be used for processing and enriching
the batch and streaming data.
It's based on open source Apache Beam.
If you are in the Hadoop ecosystem, then use Dataproc.
It is managed Hadoop and Spark platform
that is set up to analyze the data faster,
instead of worrying about managing
and standing up your own Hadoop cluster.
It literally spins up a cluster in 90 seconds.
BigQuery is a serverless data warehouse
that can also act as long term storage and a data lake.
We can run SQL queries to analyze our data
within BigQuery, and it literally queries over
petabytes of data and responds in seconds
due to the underlying separation of storage and compute,
which is unique to BigQuery.
We can use this data from BigQuery
to create a dashboard in Looker and Data Studio.
It also offers machine learning capabilities,
so we can create machine learning models
and make predictions by just writing some SQL statements.
Now, for ML and AI projects, we can use the data in BigQuery
or Cloud storage to train our models in Vertex AI.
Or we can import our media files, image,
and other unstructured data from Cloud storage as well.
In machine learning and AI, our options
depend on whether we want to create our own custom model
or use a pre-trained model.
My recommendation is to always start with a pre-trained model,
see if it works for your use case.
The most common use cases are all
covered, including images, text, video, and tabular data.
If a pre-trained model does not work for your use case,
then use the AutoML model in Vertex AI
to train a custom model on your own data set.
AutoML supports all the common use cases.
You can evaluate the model and look at metrics
to improve your model.
It deploys the model for you and provides you
with an EPI endpoint.
In case you have lots of machine learning and data science
expertise in-house, that is only when
I would say, write your own custom model
code in the framework of your choice,
such as TensorFlow, PyTorch, and then
train your model on a prebuilt or a custom container.
For operations, monitoring, debugging, and troubleshooting,
Cloud Operations Suite offers all the tools
needed to keep track of the resources and applications.
When it comes to security, understand
that security in Cloud is a shared responsibility.
Google Cloud offers the inherent infrastructure security
and the tools that you would need
to protect your application, data, and your software.
The data is already encrypted at rest and in transit.
You can also bring your own custom keys for encryption too.
For data loss prevention and protecting PII information,
you have DLP, which helps mask and tokenize sensitive data
in BigQuery, Cloud Storage, or even on premises.
For user authentication, you have Cloud Identity,
which checks if the user is who they say they are.
And for authorization, you have Cloud IAM,
where you can define who has access to what.
Security Command Center continuously
monitors your Google Cloud environment for visibility
into the system, discover vulnerabilities,
detect threats, and show that, so you
can take actions on them.
There are lots of other security features
that I did not dive into here.
But go ahead and play around when
you create your own project.
We just took a tour of most of the Google Cloud services
for an example application, foo.com.
We looked at some services for networking, compute storage,
databases, data analytics, machine learning, security,
and operations.
There is definitely a lot more to explore.
But I am confident this will get you started
with the right background.
Now, it's your turn.
I encourage you to sign up for a free trial
and follow this tutorial yourself.
[JAZZ MUSIC]