Why We're Moving to Google Cloud Platform
We’ve been running Bugfender for around three years now. What started as an internal project within Mobile Jazz to debug our applications turned into a widely adopted tool, running on over 10 million devices worldwide.
Over this time our needs have changed, and we quickly realized that we could improve things in the hosting department by switching to Google Cloud Platform.
We’re currently working with Amazon Web Services and - we want to make this crystal clear - AWS has served us well. But there are some compelling reasons to justify the move.
Disclaimer: We have in-depth experience as AWS customers. When it comes to GCP, we’ve only just scratched the surface through some experimentation. We’re keen to follow-up on this article post-migration; we may end up with buyer’s remorse!
Why the Switch to Google Cloud Platform?
There are three main drivers for the change:
- Cost: Long-term discounts
- Features: Privacy
- Features: MySQL
Let’s dive into the finer detail.
Cost: Long-Term Discounts
Let’s talk cash. Our last Amazon Web Service invoice was US $1,300.
For some, this figure is nothing to sweat about. But for a humble bootstrapped company such as ourselves it’s a significant amount of money; we’re not exactly swimming in VC funding.
We’d believe that investing in growth as opposed to spending on fixed costs is the way forward.
Whilst both Google Cloud Platform and Amazon Web Services offer very similar pricing, the key difference for us lies in their long-term commitment discounts.
Both of them offer a 30% discount when using the service for an extended period of time. There is, however, one fundamental difference:
- With AWS you need to commit in advance to at least 1 year of continued use of your chosen service and machine type.
- With GCP, on the other hand, you get the same discount after 1 month of use, and you don’t need to plan in advance since the discount is retroactive.
Of the dozens of machine types and services on offer, It’s impossible for us to know which of them we’ll be using in one year’s time.
We’re essentially unable to take advantage of any AWS discounts, whereas with GCP we’ll be free to get more savvy with our spending. Result.
How does this small detail make such a big impact?
- Platform evolution: Every now and then we make improvements that lead to increasing or decreasing machine sizes, splitting a machine’s task in two, and so on. Planning that in advance is only possible when the product is no longer evolving.
- Vendor lock-in: If you pay in advance for a full year of service, you’re essentially stuck there for at least a year. If you then commit to using another service within that one-year period, you’ve lost out on your discount and then some. Switching vendors for hosting is no trivial thing; still, it’s a good thing if that option’s on the table.
- Cash flow: If you want to take advantage of the full discount AWS is offering, you need to pay in advance. We could do it, but it’s not ideal.
Features: Privacy
Encrypted Storage by Default
While encrypting storage in Amazon EC2 is an option, it’s not always the case in other services offered by AWS.
You might, for example, come across a managed database type such as Redis that does not encrypt its data at rest. In contrast, encryption for data at rest is standard in Google Cloud Platform throughout all services. You can’t even manually disable it.
Bugfender customers trust us with their log data. We are committed to handling it with care, so this is a feature that we value extremely highly.
Encrypted Network Traffic Between Data Centers
Both GCP and AWS offer virtual private networks to interconnect your machines. However, all data going through that network is sent as is, logically separated from other customers and nothing more.
This means data on the wire is not encrypted. You either have to take special care to encrypt it properly, or accept the risk that privacy is not guaranteed.
This is often considered an “acceptable risk since there are other protections in place, like physical security measures at the data center and physical and virtual access control for staff.
That being said, in the case of inter-data center connections data travels through areas that are beyond the control of AWS and GCP, which makes it technically possible to tap their cables and sniff the data that goes through them.
Sounds like a farfetched movie plot? It’s already happened in real life. This is why Google Cloud Platform is now encrypting traffic between data centers. It’s not all traffic but it’s a start!
Features: MySQL
Managed MySQL Features
Anyone who’s worked on a big database knows that keeping it up to speed is a mammoth task: setting up, maintaining replication, monitoring, backups, performance tuning...the list goes on.
It all takes up heaps of time. Having a managed service for this comes in handy.
Bugfender uses a variety of databases to store our platform information. One of them is MySQL, which is currently running in Amazon’s Relational Database Service (RDS).
GCP’s counterpart, called Google Cloud SQL, appears to be slightly more advanced. It provides a few additional functionalities:
- Automatic failover in replicated databases: MySQL allows for several database servers to work together by using replication. If you have replicas in your setup and the master becomes unavailable, Google Cloud SQL automatically switches over to a replica to ensure continuity. In contrast, RDS only offers this in its proprietary database, Aurora.
- Automatically add storage capacity: Being a log storage provider, it is common that for Bugfender we need to add more space in the database. RDS lets you manually add disk space to a running database, but we wouldn’t recommend doing so. Why? Well, we tried it once and the performance penalty was so hefty that it completely brought down the service for five hours. Google Cloud SQL, in contrast, claims to provision disk space automatically when required. We hope it does so in a much safer way!
- Data encryption at rest: this is an option in RDS and it’s not straightforward if you have replicas in different availability zones. GCP does this by default, no configuration required, so it’s quite simply more convenient.
Note: Amazon provides a proprietary database compatible with MySQL called Aurora. Perhaps Aurora would fair better against Google Cloud SQL. We tried it once but never switched as its performance was poorer than the RDS MySQL we were using (contrary to the 5x improvement Amazon claims on their marketing page).
Conclusion
Both Amazon Web Services and Google Cloud Platform are mature hosting platforms with bucketloads of services and features on offer. We only need to draw on a couple of them, however, and with that in mind Google Cloud Platform pulls away as a clear winner when it comes down to a service that’s right for us.
Plus, we’re saving money!
So there you have it. We’ll be sure to report on our findings.
Do you have experience using both AWS and GCP? What’s your view? Leave us a comment!
Top comments (20)
I'm at the same place with AWS. While I like the diverse array of services, and the ability to build robust apps. The pricing structure is kind of crazy.
I'm not going to know how many servers I can commit to paying for long term until I'm up and running for a while. It is very chicken and the egg.
Also, by the time I've got enough usage data to prognosticate on future usage. We will already be looking at probably moving to a different arch entirely.
Which then brings up my next thing. AWS is more attractive to me because of Lambda and other serverless tech.
I'm still building stuff on AMIs because that is what I know. But I think in the next year or two that will be reduced to a bastion host.
Yes, indeed lambda seems to be very interesting. In our case we can not use such services, because pricings are on a per-request basis and the nature of our service is about handling a high volume of requests/second. But it's looks suitable for lots of use cases!
Here Simform has done pretty good comparison of regular instance pricing and discounted pricing(simform.com/compute-pricing-compar...).
Simform considered four scenarios standard, highmemory, highcpu and GPU with no SSD and Google Cloud comes with the lowest price for all.
I really want to hear more about this migration. One of the people I trained in my business is using GCP for website hosting (I think it's a bit mad); but maybe I'm being a stick in the mud when I shouldn't be.
Hi david,
First of all, sorry for the misunderstanding if that wasn't clear.
About networking, we're referring to private networks between your servers here. Not VPNs, but private networking. It's virtual because you don't have a cable connecting your computers, and here is where the risk lies: data is transmitted over the same cable together with other customers, the only separation is virtual. If an attacker had access to the raw data in the cable, they would be able to see your traffic, given it's not encrypted.
About Redis: Redis stores data on disk on most configurations (including the default configuration in AWS). Actually, the key difference between Redis and other databases is that it defers the writing to disk, so this doesn't block the read/writes. Same applies to database backups.
Damn, that's a pretty brutal policy with AWS.
GCP's "sustained use" discounts are pretty great, but they also offer "committed use" discounts as well that give even lower pricing for 1 and 3 year terms, effectively cheaper than most dedicated hosting providers while getting all the benefits of running in the Google environment.
Another great feature is that discounts are based on cores/ram rather than any specific instance type. This makes it easy to get discounts even with fluid usage of the VMs themselves.
It is especially for startups! One of the great things of cloud computing is the possibility of upgrading/downgrading machines, or deploying more machines in short notice. 1 year planning is totally impossible :(
MySQL looks like the wrong choice of database for your application anyways as it doesn't really scale. And if you use the real cloud services (key-value store, file store, ...) it wouldn't be easy to switch between two clouds.
We know that MySQL is a wrong choice for our product, but what started as an experiment is now a real product used by millions of devices. We are moving away from MySQL for the log storage that's what it requires more work on the database storage engine.
But this change requires some time and meanwhile, you need to keep the service running, so having a better SQL server will release stress on the team.
Reminds me of this youtube.com/watch?v=b2F-DItXtZs
I'm not saying stick with MySQL, but I would say you've probably got a better idea what your app needs and wants, and you should be in control of tech-stack, which it seems you are moving towards enabling you to make changes when as a business you've tested and know it's right.
Correct, we're still keeping MySQL for some things but moving to Elasticsearch for log data. We're using each tool for what they're good at.
Hi, I just wonder if the migration process was painless and landmines to watch out?
We are planning the migration at the moment it will take several weeks, there are landmines to watch out for. One of them is moving data out of Amazon RDS (proprietary) and putting it into Google Cloud SQL (also proprietary!).
Once we have completed the migration we intend to write a follow up post.
Thanks for your feedback! And looking forward for your successful migration story sharing :)
Great motivations behind migrating to GCP to take advantage cost, MySQL and privacy.
Why would not you chose other dev-friendly players like DigitalOcean, Exoscale? Are there rationale behind not adopting multi-cloud?
I would have suggested (magic.cloudureka.com/#!/compare) to help you measure your ROI from AWS to GCP (and other cloud options), even before the migration.
Disclaimer: I'm one of the founder of Cloudureka.
We considered other options, however managed MySQL and encrypted network traffic/data at rest are two things that we value and that are not provided by most of them out of the box.
So, how is GC is working for you?
Thank you for the useful breakdown! I'm filing this one away for later.
Btw there's a typo in your bio box. :)
Woops! thank you!