Candy Crush is migrating to Google Cloud, marking its first major cloud migration as decided by the online game-maker, King. Starting in early 2019, Candy Crush will be hauling a substantial amount of big data from on-premise to Google Cloud Platform.
A cloud migration is no easy feat, and for a company that provides online gaming to over 270 million people globally, choosing the right cloud provider to navigate the challenges of such a move is crucial. Aside from “even richer online gaming experiences,” Sunil Rayan, managing director of gaming at Google Cloud, makes a good case for why Google was the best choice for Candy Crush:
“It will continue to innovate and demonstrate its leadership position as a global innovator by utilising our big data, AI and machine learning capabilities to give its engineers the next generation of tools to build great experiences.”
But with the potential for better gaming, higher speed, and scalability, a cloud migration also comes with a few big risks. Here are 3 things Candy Crush can do to make their cloud migration sweeter:
1. Don’t rush data transfer
Transferring data from on-premise to the cloud is a huge undertaking, especially for a company that claims to have the largest Hadoop cluster in Europe. Transferring massive amounts of data is not recommended because it slows download speed, so it would be best for Candy Crush to make the move in parts, over time, and with the anticipation of potentially massive transfer costs associated with moving data out of or into a cloud.
2. Prepare for potential downtime
Downtime is a huge risk for any application, let alone a game played by millions across the world. Candy Crush can’t afford for downtime on a game. Users say is downright addictive, so it’s important to account for inconsistencies in data, examine network connections, and prepare for the real possibility of applications going down during the cloud migration process.
3. Adapt to technologies for the new cloud
Since choosing a cloud provider means committing to a heavy amount of time reconfiguring an application for the move – it’s important to evaluate that the technology is the best fit. Technology is a big reason for Candy Crush moving their monolothic, on-premise environment to Google Cloud. Asa Bresin, FVP of technology at King, listed innovations in machine learning, query processing, and speed as drivers for cloud migration, and with technology known for speed and scalability, Google has met their requirements.
Bonus: Keep costs in check. Whether it’s heavy transfer costs, losing money during downtime periods, or the time and manpower needed to reconfigure an application to the cloud – cloud migrations come with costs. The time and costs of a cloud migration are easily misunderstood or drastically understated. For ease and efficiency of keeping costs in check throughout and after the migration process, it’s important to have an understanding of cloud service offerings, pricing models, and the complexity of a cloud adoption budget. Evaluate all of these costs and look into options that will help you save post-migration, like optimization tools.
With a gradual shift, planning for risks of downtime, and the patience and flexibility to reconfigure for Google Cloud, Candy Crush can win at cloud migration.
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.
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.
In this blog we will look at the Google Cloud Committed Use discount program for customers that are willing to “commit” to a certain level of usage of the GCP Compute Engine.
The Committed Use purchasing option is particularly useful if you are certain that you will be continually operating instances in a region and project over the course of a year or more. If your instance usage does not add up to a full month, you may instead want to look at the Google Cloud Sustained Use discounts, which we discussed in a previous blog.
The Google Cloud Committed Use discount program has many similarities to the AWS and Azure Reserved Instances (RI) programs, and a couple unique aspects as well. A comparison of the various cloud providers’ reservation programs is probably worth a blog in itself, so for now, let’s focus on the Google Cloud Committed Use discounts, and the best times and places to use them.
Critical Facts about Google Cloud Committed Use
- The Committed Use discount is best for a stable and predictable workload (you are committed to pay – regardless of whether you use the resources or not!)
- Commitment periods are for either 1 or 3 years.
- Commitments are for a specific region and a specific project. Zone assignment within a region is not a factor.
- Discounts apply to the total number of vCPUs and amount of memory– not to a specific machine or machine type.
- No pre-payment – the commitment cost is billed monthly.
- GCP Committed Use discounts are available for all of the GCP instance families except the shared-core machine types, such as f1-micro and g1-small.
- Committed Use discounts do not apply to the premium charges for sole-tenants, nor can they be used for Preemptible instances.
- The commitments for General Purpose instances are distinct from those for Memory Optimized instances. If you have some of both types, you must buy two different types of Commitment. These types are:
|General Purpose||Memory Optimized|
- Standard – n1-standard
- High Memory – n1-highmem
- High CPU – n1-highcpu
- General purpose sole-tenant
How much does it cost?
Each Committed Use purchase must include a specific number of vCPUs and the amount of memory per vCPU. This combination of needing to commit to both a number of vCPUs and amount of Memory can make the purchase of a commitment a bit more complicated if you use a variety of machine types in your environment. The following table illustrates some GCP machine types and the amount of memory automatically provided per vCPU:
|Machine Type||Memory per vCPU|
|custom||0.9 – 6.5 GB|
While the vCPU aspect is fairly straightforward, the memory commitment to purchase requires a bit of thought. Since it is not based on a specific machine type (like AWS and Azure), you must decide just how much memory to sign-up for. If your set of machine types is homogeneous, this is easy – just match the vCPU/memory ratio to what you run. The good news here is that you are just buying a big blob of memory – you are not restricted to rigidly holding to some vCPU/memory ratio. The billing system will “use up” a chunk of memory for one instance and then move on to the next.
Looking at a specific example, the n1-standard-8 in the Oregon region that we discussed in the Sustained Usage Blog, we can see that the Committed Use discount does amount to some savings, but one must maintain a usage level throughout the month to fully consume the commitment.
Recall from the earlier blog that the base price of this instance type in the GCP Price list already assumes a Sustained Usage discount over a full month, and that the actual “list price” of the instance type is $277.40, and Sustained Usage provides up to a maximum of a 30% discount. With that as a basis, we can see that the net savings for the Committed Use discount over 1 year is 37%, and over 3 years, rises to 55%. This is close to the advertised discount of 57% in the GCP pricing information, which varies by region.
The break-even points in this graph are about 365 hours/month for a 3 year commitment, and 603 hours/month for a 1 year commitment. In other words, if you are sure you will be using a resource less than 365 hours/month over the course of a year, then you probably want to avoid purchasing a 3 year Commitment.
Allocation of Commitments
Because Commitments are assigned on a vCPU/RAM basis, you cannot simply point at a specific instance, and say THAT instance is assigned to my Committed Use discount. Allocation of commitments is handled when your bill is generated, and your discount is applied in a very specific order:
- To custom machine types
- Sole-tenant node groups
- Predefined machine types
This sequence is generally good for the customer, in that it applies the Commitment to the more expensive instances first. For example, an n1-standard-4 instance in Northern Virginia normally costs $109.35. If an equivalent server was constructed as a Custom instance, it would cost $114.76.
For sole-tenant node groups, you are typically paying for an entire physical machine, and the Committed Use discount serves to offset the normal cost for that node. For a sole-tenant node group that is expected to be operating 7x24x365, it makes the most sense to buy Committed Use for the entire system, as you will be paying for the entire machine, regardless of how many instances are running on it.
Commitments are allocated over the course of each hour in a month, distributing the vCPUs and RAM to all of the instances that are operating in that hour. This means you cannot buy a Commitment for 1 vCPU and 3.75 GB of RAM, and run two n1-standard-1 instances for the first half of the month, and then nothing for the second half of the month, expecting it all to be covered by the Commitment. In this scenario, you would be charged for one month at the committed rate, and two weeks at the regular rate (subject to whatever Sustained Usage discount you might accumulate for the second instance).
Thank you for….not…sharing?
Unlike AWS, where Reserved Instances are automatically shared across multiple linked accounts within an organization, GCP Commitments cannot be shared across projects within a billing account. For some companies, this can be a major decision point as to whether or not they commit to Commitments. Within the ParkMyCloud platform, we see customers with as many as 60 linked AWS accounts, all of which share in a pool of Reserved Instances. GCP customers do not have this flexibility with Commitments, being locked-in to the Project in which they were purchased. A number of our customers use AWS Accounts as a mechanism to track resources for teams and projects; GCP has Projects and Quotas for this purpose, and they are not quite as flexible for committed resource sharing. For a larger organization, this lack of sharing means each project needs to be much more careful about how they purchase Commitments.
Google Cloud Committed Use discounts definitely offer great savings for organizations that expect to maintain a certain level of usage of GCP and that expect to keep those resources within a stable set of regions and projects. Since GCP Commitments are assigned at the vCPU/Memory level, they provide excellent flexibility over machine-type-based assignments. With the right GCP usage profile over a year or more, purchase of Google Cloud Committed Use discounts is a no-brainer, especially since there are no up-front costs!
Today, we share the latest update in ParkMyCloud, which highlights new types of GCP resources you can park, and updates for new and existing users alike.
Park GCP Groups
Now in ParkMyCloud, you can manage and optimize costs for your GCP Managed Instance Groups, both with and without Autoscaling. You can set parking schedules on these groups, but rather than simply turning them “on” and “off”, you can set “high” and “low” stages for your groups, for which you set a maximum and minimum number of resources, respectively. Some additional details:
- GCP Managed Groups with Autoscaling can have a minimum size of 1 instance in the Low/Off state, and thus they can never be fully shut off to zero instances.
- GCP Managed Groups without Autoscaling can have a minimum size of 0 instances in the Low/Off state, and can be fully shut off.
- The Console will show the members of GCP Unmanaged Groups as “regular” resources, allowing them to be scheduled/controlled individually. You wish to assign them to ParkMyCloud Logical Groups in order to start and stop them as a set.
In order to allow ParkMyCloud to support management of GCP Instance Groups, please update your ParkMyCloud Access Role to include the latest set of permissions defined here in the User Guide.
What about other cloud service providers? ParkMyCloud already supports parking for AWS Auto Scaling groups. Management of Azure’s equivalent, Azure scale sets, is coming later this month.
Schedule “Snooze” is now “Override”
ParkMyCloud has long allowed you to “snooze” parking schedules — as in, snooze the on/off actions of the schedule, not the resource. But it was confusing — when people heard “snooze”, they incorrectly assumed it meant, “put the resource to sleep”.
So we’ve renamed it “override”. When you override a schedule on a resource, you can set it to your preferred state of running or parked, either for a set duration (e.g., override the schedule for 3 hours) or until a set time (e.g., override the schedule until 8:00 a.m. on May 16). After that time, normal schedule actions will resume.
For Existing Users…
This release includes a number of other updates that will interest existing users of ParkmyCloud:
- Recommendations Export: The recommendations screen can now be exported to CSV, via a new Export button, for easy sharing and analysis.
- Online Help: Each page on the console now has a “?” link to context-sensitive help from the PMC User Guide.
- Teams: Superadmins now appear as greyed-out users on all team lists, showing their visibility into all teams.
- Notifications: User-level notifications are now more obvious with a link from the org/team-level notifications screen.
- Resources Screen:
- The Schedule/Start/Stop/Team/Group buttons are now always visible, and only enabled when appropriate instances are checked, depending on the function of the button.
- The resources screen is now more mobile-device friendly. There used to be an issue with how the screen scrolled, which is now fixed.
- Performance improvements for customers with large numbers of schedules and recommendations.
For New Users…
Don’t tell the existing users above, but we’ve improved the ParkMyCloud free trial for new users. When you start a 14-day free trial, you will now be given Enterprise tier access to the product – that means unlimited instances, teams, users, and cloud accounts across providers in your trial ParkMyCloud account, access to the user import/export feature, database parking, SmartParking, and more. Check it out with a free trial.
Whether you’re just getting started on public cloud, or you’ve gotten a bill that blew your budget out of the water, it’s a good idea to research ways to get discounts on cloud resources. There’s no reason to pay list price when so many cost-savings measures are available (and your peers are probably taking advantage of them!) Here are our top five ways to get discounts on cloud.
1. Buy in Advance
By purchasing your compute power in advance, you can get a discounted rate — the notable examples being AWS Reserved Instances, Azure Reserved Instances, and Google Committed Use Discounts.
So will these save you money? Actually, that’s a great question. There are several factors that weigh into the answer:
- How much you pay upfront (for example AWS offers all-upfront, partial-upfront, or no-upfront)
- Contract term: 1-year or 3-year term – the longer term will save more, but there’s risk involved in committing for that long
- If the cloud provider cuts their prices during your contract term (and they probably will), you’ll save less
This blog post about AWS Reserved Instances digs into these issues further. Bottom line: paying in advance can save you money, but proceed with caution.
2. Use Your Resources More
The primary example of “spending more to save more” in the cloud computing world is Google Sustained Use Discounts. This is a cool option for automatic savings – as long as you use an instance for at least 25% of the month, GCP will charge you less than list price.
But just like the advanced purchasing options above, there are several factors to account for before assuming this will really save you “up to 60%” of the cost. It may actually be better to just turn off your resources when you’re not using them – more in this post about Google Sustained Use Discounts.
3. If You’re Big: Enterprise Agreements and Volume Discounts
Anyone who’s shopped at Costco isn’t surprised that buying in bulk can get you a discount. Last week, Twitter announced that it will be using Google Cloud Platform for cold data storage and flexible compute Hadoop clusters — at an estimated list price of $10,000,000/month. Of course, it’s unthinkable that they would actually pay that much – as such a high-profile customer, Twitter is likely to have massive discounts on GCP’s list prices. We often hear from our Azure customers that they chose Azure due to pre-existing Microsoft Enterprise Agreements that give them substantial discounts.
If you have or foresee a large volume of infrastructure costs, make sure to look into:
4. If You’re Small: Startup Credits
Each of the major cloud providers offers free credit programs to startups to lure them and get locked in on their services – but that’s not a bad thing. We’ve talked to startups focused on anything from education to location services who have gotten their money’s worth out of these credits while they focus on growth.
If you work for a startup, check out:
So far, history tells us that if you wait a few months, your public cloud provider will drop their prices, giving you a built-in discount.
If you stick with the existing resource types, rather than flocking to the newer, shinier models, you should be all set. The same AWS m1.large instance that cost $0.40/hour in 2008 now goes for $0.175. We’ll just say that’s not exactly on pace with inflation.
It’s Okay if You Don’t Get Discounts on Cloud
What if you’re not a startup, you’re not an enterprise, and you just need some regular compute and database infrastructure now? Should you worry if you don’t get discounts on cloud list prices? No sweat. Even by paying list price, it’s still possible to optimize your spend. Make sure you’re combing through your bill every so often to find orphaned or unused resources that need to be deleted.
Additionally, right-size your resources and turn them off when you’re not using them to pay only for what you actually need – you’ll save money, even without a discount.