Google Cloud Platform offers a range of machine types optimized to meet various needs. Machine types provide virtual hardware resources that vary by virtual CPU (vCPU), disk capability, and memory size, giving you a breadth of options. But with so much to choose from, finding the right Google Cloud machine type for your workload can get complicated.
In the spirit of our recent blog on EC2 instance types, we’re doing an overview of each Google Cloud machine type. This image shows the basics of what we will cover, but remember that you’ll want to investigate further to find the right machine type for your particular needs.
Predefined Machine Types
Predefined machine types are a fixed pool of resources managed by Google Compute Engine. They come in five “classes” or categories:
Standard machine types work well with workloads that require a balance of CPU and memory. The n1-standard family of machine types come with 3.75 GB of memory per vCPU. There are 8 total in the series and they range from 3.75 to 360 GB of memory, corresponding accordingly with 1 to 96 vCPU.
High memory machine types work for just what you’d think they would – tasks that require more system memory as opposed to vCPUs. The n1-highmem family comes with 6.50 GB of memory per vCPU, offering 7 total varieties ranging from 13 to 624 GB in memory, corresponding accordingly with 2 to 96 vCPUs.
If you’re looking for the most compute power, the n1-highcpu series is the way to go, offering 0.90 GB per vCPU. There are 7 options within the high cpu machine type family, ranging from 1.80 to 86.6GB and 2 to 96 vCPUS.
Share-core machine types are cost-effective and work well with small or batch workloads that only need to run for a short time. They provide a single vCPU that runs on one hyper-thread of the host CPU running your instance.
The f1-micro machine type family provides bursts of physical CPU for brief periods of time in moments of need. They’re like spikes in compute power that can only happen in the event that your workload requires more CPU than you had allocated. These bursts are only possible periodically and are not permanent.
Memory Optimized (n1-ultramem or n1-megamem)
For more intense workloads that require high memory but also more vCPU than that you’d get with the high-memory machine types, memory-optimized machine types are ideal. With more than 14 GB of memory per vCPU, Google suggests that you choose memory-optimized machine types for in-memory databases and analytics, genomics analysis, SQL analysis services, and more. These machine types are available based on zone and region.
Custom Machine Types
Predefined machine types vary to meet needs based on high memory, high vCPU, a balance of both, or both high memory and high vCPU. If that’s not enough to meet your needs, Google has one more option for you – custom machine types. With custom machine types, you can define exactly how many vCPUs you need and what amount of system memory for the instance. They’re a great fit if your workloads don’t quite match up with any of the available predefined types, or if you need more compute power or more memory, but don’t want to get bogged down by upgrades you don’t need that come with predefined types.
About GPUs and machine types
On top of your virtual machine instances, Google also offers graphics processing units (GPUs) that can be used to boost workloads for processes like machine learning and data processing. GPUs typically can only be attached to predefined machine types, but in some cases can also be placed with custom machine types depending on zone availability. In general, the higher number of GPUs attached to your instances, the higher number of vCPUs and system memory available to you.
What Google Cloud machine type should you use?
Between the predefined options and the ability to create custom Google Cloud machine types, Google offers enough variety for almost any application. Cost matters, but with the new resource-based pricing structure, the actual machine you chose matters less when it comes to pricing.
With good insight into your workload, usage trends, and business needs, you have the resources available to find the machine type that’s right for you.
Over the past year or so, we have spoken with quite a few prospective users who have defined their responsibilities as site reliability engineering (SRE). If, like me, you’re not familiar with the term, I’ll save you the Google search. SRE is a discipline that incorporates aspects of software engineering and applies that to IT operations problems. Practitioners aim to create ultra-scalable and highly reliable software systems. According to Ben Treynor, founder of Google’s Site Reliability Team, SRE is “what happens when a software engineer is tasked with what used to be called operations.” And its origins can also be traced back to 2003 and Google when Ben was hired to lead software engineers to run a production environment.
The site reliability engineering footprint at Google is now larger than 1,500 engineers. Many products have small to medium sized SRE teams supporting them, though not all products do. The SRE processes that have been honed over the years are being used by other, mainly large scale, companies that are also starting to implement this paradigm, including ServiceNow, Microsoft, Apple, Twitter, Facebook, Dropbox, Amazon, Target, IBM, Xero, Oracle, Zalando, Acquia, and GitHub.
The people we talk to on a daily basis are typically charged with operational management of their company’s cloud infrastructure, and thus governing and controlling costs (that’s where we come in). I got to wondering, how is this approached differently by, say, a site reliability engineer vs. someone who labels himself as “DevOps”?
How Does Site Reliability Engineering Compare to DevOps?
In simple terms, the difference between SREs and DevOps seems clear based on our conversations with folks. SREs are engineers focused on production environments, while DevOps is a philosophy as well as a role. DevOps folks are definitely less concerned with production vs. non-production, and more concerned with the overall cloud management and operations. Side note, DevOps was coined around 2008, so an SRE actually predates a DevOps engineer.
A site reliability engineer (SRE) will spend up to 50% of their time doing “ops” related work such as issues, on-call, and manual intervention. Since the software system that an SRE oversees is expected to be highly automatic and self-healing, the SRE should spend the other 50% of their time on development tasks such as new features, scaling or automation. The ideal SRE candidate is a highly skilled system administrator with knowledge of code and automation.
When I first encountered it, site reliability engineering just seemed like another buzzword to replace “IT” or “Ops”. As I read more on it, I understand that it’s more about the people and the process and less about the technology. There is rarely a mention of the underlying infrastructure or tools, and it seems like the main requirement is just the desire to improve. With that, you can align your development and operations (funny, right – DevOps) around the discipline of SRE.
Should Your Company Implement a Site Reliability Engineering Approach?
So while all the hype is around implementing DevOps in your organization, should you really be adopting the idea of site reliability engineering? It certainly makes sense based on the name alone, as “site reliability” is synonymous with “business availability” in our modern internet-connected culture. Any downtime for your service or application means lost revenue and dissatisfied customers, which means the business takes a hit. Using site reliability engineering to keep things running smoothly, while employing DevOps principles to improve those smooth-running processes, seems to be the best combination to really empower your company.
Among the many announcements made at Google Cloud Next last week was a new option for Google Cloud discounts: resource-based pricing.
This new option, which Google will roll out in the fall, expands their idea of “pay per use pricing”. For resource types n1-standard, n1-highmem, and n1-highcpu, Google will no longer charge based on machine types. Instead, they will now aggregate across resources and charge based on the quantity of vCPU and GB of memory you use.
This new addition to the family of Google Cloud discounts will have its biggest effect on Sustained Use discounts.
Sustained Use Discounts are Even Better
We recently asked the question, do sustained use discounts really save you money? The answer was yes, although depending on the situation, perhaps not the maximum amount of money possible.
With the resource-based pricing change, Sustained Use Discounts will be based in regions instead of just zones, so you can rack up “percentage of the month” usage and therefore discounts faster and easier. For example, if you have a single busy week in the month, during which you run several VMs with varying amounts of vCPU, the vCPU will all be counted together before the sustained use amount is calculated, giving you potential for a better-optimized discount.
For some customers, the biggest impact of this change will be in Autoscaling Managed Instance Groups. In the old system, if a group of instances scaled up and down over time (especially daily), the new instances that were created and then shut down a short time later never had an opportunity to accumulate enough hours to reach a sustained use discount tier. In the new system, the aggregated use of these systems counts toward the sustained use, giving a much higher likelihood of getting the Sustained Use Discount.
Billing Simplicity (…Hopefully)
While this should make your bill lower, it may not make your bill “easier to understand” as Google claims. Since discounts will apply at a regional level, and there’s now yet another step going on behind the scenes to calculate your bill, some users may find it harder to predict their monthly bills. You will no longer be able to see the machine types that you are using in your invoice, although you can obtain them via Billing BigQuery. Keep this in mind, and be sure to dig into your first few invoices after the change is made to see how it’s affecting your particular environment.
It’s All About Automation
One thing we appreciate about the change is that Google Cloud customers do not need to take any action to receive these discounts – it’s all done automatically. The same has always been true for Sustained Use Discounts, something that makes Google Cloud stand out from its immediate competition – neither AWS nor Azure offers something directly equivalent.
Google Cloud Discounts are Good for the Customer
Here’s what people are saying about the update.
It shows flexibility as a priority:
And AWS would be wise to do the same:
We’re glad to see another addition to the Google Cloud discounts that go directly toward improving the customer experience. It’s clear to see that GCP is focusing on a customer-first experience – which is good news for all of us.