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.
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!
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).
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!