ROGER MARTINEZ: There are thousands of applications
that you can run on Google Cloud Compute Engine, each
with different requirements.
To meet those requirements, Google Cloud
offers VM families, each optimized for specific needs.
I'm going to help you make sense of it
by reviewing some important factors to consider
when choosing the right Compute Engine VM.
If you want to choose the right VM,
first let's review how VMs are organized in Google Cloud.
All VMs are categorized into either general-purpose or
workload-optimized families.
General-purpose machines provide the best price performance
ratio for a variety of workloads.
As of right now, there are three machine types
within the general-purpose family.
Efficient machines deliver reliable,
sustained performance, the lowest total cost of ownership
of any VM in Google Cloud.
They're about 31% cheaper than N1 machines.
Balanced machines offer more customization
and a wider feature set.
And tau, which represents torque in physics,
puts the pedal to the metal for industry-leading price
performance.
Tau is recommended for scale-out workloads,
such as web servers, containerized microservices,
and media transcoding.
T2D is our first offering in the Tau family
and provides full x86 compatibility on third-gen AMD
EPYC processors.
As you go through the three types
of general-purpose machines, efficient, balanced, and Tau,
they each have different levels of price performance,
where efficient achieves the best price,
balanced sits in between providing the most feature
flexibility, and Tau has a best price-performance ratio.
As for those workload-optimized machines,
there are three families here, too.
Compute optimized machines will offer the highest consistent
performance per core, ideal for users
with performance-intensive workloads.
C2 VMs are built on architecture that utilizes features
like non-uniform memory access to achieve the highest
performance.
Memory-optimized machines are best
suited for memory-intensive applications,
providing the largest ratio of compute
to memory and the lowest cost per gigabyte of memory.
They provide the largest SAP-certified machines
with up to 12 terabytes of storage.
And accelerator-optimized machines--
they offer the highest GPU performance
for those heavy artificial-intelligence
machine-learning workloads.
Google Cloud is the first platform
to be able to attach 16 A100 GPUs to a single VM,
allowing you mega performance to scale up and out.
OK, that's how they're organized,
but that won't help you choose between a general-purpose
n2d-highcpu-64 and a memory optimized m1-megamem-96
for instance.
These names don't exactly roll off the tongue.
But understanding the naming convention going on here
is a valuable step towards making the right choice.
It's pretty simple.
The first part of the name refers to the machine series.
This will tell you the category of machine.
For example, n2 machines run Intel, and n2d denotes AMD.
And both are categorized as general-purpose.
Each series is available as different machine types.
That's there in the middle.
Each type has a different virtual-CPU-to-memory ratio
to fit different workload requirements, like highmem,
highcpu, standard, et cetera.
Lastly, the name ends the number,
which refers to the number of virtual CPUs for that machine.
So now you can deduce that an n2d-highcpu-64
has 64 virtual CPUs.
And as part of the highcpu type, it
has one virtual CPU to 1 gigabyte
of memory ratio in the n2d series, which is
in the general-purpose family.
In contrast, the m1-megamem-96 has 96 virtual CPUs.
And we know it'll have a higher ratio of memory,
because it's in the memory-optimized family
of m1 machines, which is a workload-optimized family.
At the end of the day, the right VM
will largely be based on what you're
going to use that virtual machine for, and then
from there, figuring out how much CPU and memory
you'll need.
This can help distinguish the machine needed.
For example, AMD machines come in larger configuration sizes.
Or, if you require high memory value,
memory optimized is the way to go.
If you're migrating an application
from an on-prem system, we recommend some benchmarking
and data collection to understand the application
characteristics or testing the application on the machine type
before deploying it in production.
When choosing your CPU and memory requirements,
you should also be sure to pay attention
to the flip side, the CPU and memory that you don't need.
That is, you should be careful not
to over-provision your machine.
For example, a general purpose n2-standard-2
will provide you with two virtual CPUs and 8
gigabytes of memory.
But let's say the application you're
going to run on the instance uses
most of the CPU most of the time but never
really uses more than about 2 gigabytes of memory.
Well, in that case, you might be better off
on an n2-highcpu-2 instance.
That way, you're not getting billed for 6 extra gigabytes
of memory that you don't need.
Making sure you're provisioning just the right machine
for your needs ensures that you're not
overpaying for resources that you may never use.
If you're not sure, no worries.
Google Cloud provides rightsizing recommendations
based on your usage data to get the sizing just right.
These recommendations are available within the Compute
Engine instances page or within the Recommendations Hub.
If none of the available machine types fit your requirements,
keep in mind, there's always custom machine types.
With custom machine types, you can
configure just the right amount of CPU
and memory for your particular needs.
In some cases, you could expect to save 50% or more
compared to predefined types on other public cloud providers.
With all things considered, if you're still not
sure what machine type to choose,
start off with something small.
You can always move your workload
to a larger machine at any time.
Besides CPU and memory, another performance metric
you should consider is disk performance.
If your application needs the best disk IOPS,
you're going to want to make sure
that you choose an instance type that
will be compatible with one of two
high-performance exclusions, local SSDs
and extreme persistent disks.
Local SSDs have the advantage of being physically
attached to the server that hosts your VM,
so you can get higher throughput and lower latency
than standard persistent disks.
They offer local block storage that is ephemeral and great
for processing space, buffers, caches,
and other temporary data.
And for high-end, performance-critical
applications, extreme persistent disks
will offer higher maximum IOPS and throughput
than other options.
But keep in mind, they'll require
at least 64 virtual CPUs.
Beyond disks, there are other features
that you may need to check compatibility
for when choosing your VM.
There's confidential computing.
This is a service that encrypts data in use
while it's being processed.
The transition to confidential VMs is seamless.
All workloads we run today can also run as confidential VMs--
no extra code changes to applications, just one checkbox
to protect against rootkit and boot kits.
But if you plan on using confidential computing,
you'll have to choose an n2d from the general-purpose family
of VMs or a c2d from the compute-optimized family.
Another feature is sole tenancy.
This lets you have exclusive access to a physical Compute
Engine server that's dedicated to only
the VMs in your project.
This can be required for licensing
of certain applications.
With any Compute Engine feature, be
sure to check out the documentation for VM
compatibility when you're deciding on what VM to choose.
So now that we know how to choose a VM, let's choose a VM.
Let's say that my only requirement as of right
now is a virtual machine with 16 virtual CPUs.
With only that requirement, let's see what options I have.
The workload-optimized machines could be a good starting point.
c2-standard-16 will give me the CPU that I want.
It's a standard type, so it's got standard CPU-memory ratio.
What about general-purpose machines?
What do they have to offer?
We'll start with seeing if e2's will be a fit.
Well, an e2-standard-16 has similar specifications,
16 virtual CPUs and 64 gigs of memory.
And it's priced a bit lower than the workload-optimized c2.
We'll add that as a possible choice,
noting that this would save us some cost over time.
OK, now what if the performance of our application
will need some block storage?
Local SSDs are an excellent solution here.
According to the documentation, we
can't attach a local SSD to an e2, nor a t2d machine,
but we can attach one to a c2.
We still want a general-purpose option.
That's not a problem.
There's n2-standard-16, n2d-standard-16,
and the n1-standard-16.
All these general-purpose machines
offer the same specifications on different microarchitectures
and are compatible with local SSDs.
All right.
Now, what if we did some testing and found out
that while we can't budge on CPU,
our application actually runs pretty well with less memory?
This is our chance to optimize our cost by choosing
a high-CPU machine type.
n2-highcpu-16, n2d-highcpu-16, and n1-highcpu-16 all
have the same CPU as the other options,
but with only 16 gigabytes of memory.
c2 machines are highly performant,
so our application will run great on one.
But we'll be spending more on additional performance
and memory that won't be used.
So let's just remove c2 from our list.
Based on our requirements so far,
we've narrowed down our choice to any of these three choices.
As more machine families and series
are added to the Compute Engine lineup,
your available options might differ.
It's always a good idea to check the latest documentation
when researching what VM will work for you.
So what do you think?
What factors came into play when you chose the right VM?
Let us know in the comments.
Until next time.
[MUSIC PLAYING]