Should Your Company Adopt Google’s Site Reliability Engineering Approach?

Should Your Company Adopt Google’s Site Reliability Engineering Approach?

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.

Google Cloud Discounts Just Got Better For You with Resource-Based Pricing

Google Cloud Discounts Just Got Better For You with Resource-Based Pricing

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:

It’s pro-customer:

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.