Before we started to build our TeamTracking platform, we shared our vision with our potential clients. We soon learned that while most of our clients are large companies, they need a cost-effective solution that is both flexible, and robust. For our clients, the platform agility and elasticity was a must.
Knowing that we need to offer our clients a mission-critical enterprise app, but at a low cost and with endless scalability – we turned to the Cloud.
Prior to TeamTracking, our technical team had extensive experience building platforms on the Amazon Cloud, or AWS. In fact, our CEO deployed the first commercially-available application on AWS back in 2006 and scaled it since. So when we first looked at the Google Cloud Platform, we were admittedly a bit biased.
But it didn’t take long to get us to fall in love with the Google Cloud Platform (or GCP), and today our entire company and all of our environments (Development, QA and Production) are all hosted on GCP. Yes, you heard me right, we don’t own a single server outside of GCP.
So why did we go ‘all in’ on Google Cloud Platform? Well, to understand our decision, you have to understand our platform…
At a high level, our platform is composed of a set of mobile apps that communicate with a backend service. The mobile apps will communicate a few times a minute with the backend to report status and location, and to receive data from the backend regarding the work orders of the day.
For some of our clients, with 10,000 or more users in the field each day, this can sum up to more than 150 million API calls a month, and a database that will add around 120Gb of data every year. And each of these API calls may invoke complex GeoSpatail queries, or non-trivial business rules calculation about the status and location of a work unit. Consider the simple case of routing one professional to a job, if another professional is late, now add the logic to find the nearest professional (with the right skills, tools, work load/ availability) and reroute that professional – and now go through these decisions every minute of the day.
And this is only the backend. Our platform contains a set of frontend tools that help operators (dispatchers, managers and admins) visualize the field team locations throughout the day, and respond to certain conditions, all while integrating with the enterprise platform and adhering to union rules.
As we evaluated AWS and GCP, we quickly noticed the following
AWS’ offering is focused on the needs of the system administrator, while GCP offers tools both for developers and for system administrators. For example, tools such as Google Stackdriver (https://cloud.google.com/stackdriver/) includes monitoring, logging and diagnostics that is integrated with the code base. Developers can inspect in real-time how the code is performing and address issues.
Compared to AWS, GCP greatly simplified the task of creating secure and scalable endpoints that your mobile app can communicate with. We use Google Cloud Endpoints (https://cloud.google.com/endpoints/) and host it on Google App Engine (https://cloud.google.com/appengine/) so that these endpoints scale automatically. While GCP offers all the flexibility of AWS in order to control the cost and characteristics of auto-scaling, it hides most of the complexity from the Mobile developer and allows you to build a scalable application with just a few lines of code.
When it comes to data storage, indexing and queries, GCP is far ahead of AWS and any other cloud provider. We experimented with Cloud Datastore (a NoSQL storage) but due to the complexity of our queries, we migrated to Google Cloud SQL second edition (https://cloud.google.com/sql/ ). Cloud SQL is a cloud hosted MySQL database that can fit the needs of almost any project, and is cost-effective. Developer support has been outstanding, both from the user community and from Google engineers and product managers who helped us get any question answered.
In terms of instances, compute and storage, AWS and GCP are generally comparable. But when you add the cost of network, security, ip addresses and more, GCP becomes considerably cheaper. In other words, when we considered the cost of our specific setup – GCP was a clear winner. Now, no two cloud applications are the same, and even with GCP hosting, there are things to avoid. For example, some Cloud Datastore users who have not configured their index correctly saw high cost. But if you read the documentation, and use the right tools for the right task, you will likely find GCP to be cheaper than AWS.
Since we built our platform on GCP, our business grew rapidly. With hosting taken care of, our team was able to focus on supporting our clients and improving our application. When we launched the platform, we didn’t know if our clients will use it, and how. We had no idea about the patterns of usage, and how many servers will we need to buy to accommodate for the expected usage and growth. Betting on GCP allowed us the security of an endlessly scalable platform that can grow with our needs and the needs of our clients.
Read more about our experience in the Cloud SQL Second Generation announcement on the Google Cloud Platform blog