The Future of Cloud Computing: Google Cloud
Hi there!
My name is Obul. I did PhD in Cloud Computing and Big Data from University of Florida. My passions include Cloud, Big Data, Data Science, Linux and Open Source. I have about 8 years of experience with various Cloud services and Big Data tools. Today, I want to talk about the future of Cloud Computing. Cloud Computing is revolutionizing and redefining “Computing” as we know it. As every other cutting edge technology, Cloud is undergoing tremendous change. I am working on series of posts on why I think Google Cloud will be the Cloud of the future, focusing on Ease of use, Big Data, Scalability, Machine Learning and more. This is first of them focusing on “Ease of use” comparing Google Cloud with AWS.
Ease of Use
Cloud should be easy to use. To a developer, ease of use means learning/knowing as few things as possible. Cloud requires a fundamental shift of “how” we think about computing (elastic, pay per go, ..). But, Cloud should not be a too much of cognitive overhead to a developer. While comparing Google Cloud and AWS, I am going to touch on the following aspects.
- Cloud should not require learning needless new nomenclature.
- Cloud should have easy to use UI, SDKs, tools and services.
- Cloud services should be coherent and well organized.
No New Nomenclature
Here are the names of some products and services on AWS: Elastic Cloud Compute (EC2), Elastic Beanstalk, EC2 Container Service (ECS), Elastic Load Balancer (ELB), Simple Queuing System (SQS), Volume, Security Group, Network Access Control Lists (NACLs) and the list goes on and on. The naming scheme should should be easy enough to convey what a service is about. How about Compute / App / Container Engine, Load Balancer, Disk, Firewall, Pub/Sub, Storage, Monitoring, Logging, Debug for product and service names? See how easy Google Cloud is to get started with!
Easy to Use UI, SDKs, Tools and Services
Web Console is the primary UI for Cloud services. If I were to sell you a car with a dashboard littered with names of all the parts in car, I am sure you would not be excited. That’s how I feel when I login into AWS web console. It’s literally a marketing board for their products. Once you step into your car, you would expect a dashboard where you can see how fast you are going, amount of fuel left, any potential problems with car’s various parts, easy access to steering wheel, accelerator, brake, cup holder but not your spare tire. Log into Google Cloud console, you will be greeted with the list of resources you have created, their performance metrics and some additional information like service status, customizable shortcuts to most used services. Just like a car’s interface!
You can even customize what you want see and what you don’t want to see. If you have 10 projects and you are working on project A, why would some be interested about information on project B? May be once in a blue moon, but not all the time. In AWS, if you have 10 VPC’s and say you navigate into EC2 page, you will be shown Instances from all 10 VPC’s. Same with Networks, and other resources. Why this craziness? I don’t know. Google Cloud has nice concept call project (similar to VPC on AWS). Once you select the project you are working on, you will be shown the resources only for that project. It’s much easy to manage resources this way.
Just like with any other UI, it should be easy to access resources. With AWS, you need to navigate from web console to the service/product page, then query the resources with VPC ID or name and then you access the resource. With Google Cloud, right from home page you can access resources in 2 mouse clicks. From any service page, you can jump to any other service page using configurable and easy to use shortcuts.
Coherent services
Another big aspect of Cloud is how coherent are the services and how well they are organized. Some companies have a mindset of garage/warehouse and some others of a workshop/museum. (I am not talking about hacker mindset, I am talking about how well they are organized). The difference between the two being, garage/warehouse is a dumping yard where as a workshop/museum a well organized collection. In companies with garage/warehouse mindset, people keep picking fancy tools for solving jobs and in the end the company ends up with lot of dumping yard which need maintainers, need to maintain various knowledge about various tools, siloed data etc ., A well organized company should try to stay boring when it comes to tools, as much as possible. If the job at hand can not be solved with the existing tools and requires a fundamental shift of approaching things, then go for a new service. That way you end up with workshop rather than a garage.
AWS comes with 3 queuing systems (SQS, Kinesis Firehose, Kinesis Streams), a push notification system (SNS), two storage systems (S3 and Glacier) with different API’s, with a gotchas(billing, minimum object sizes, minimum time periods), and each service address only a subset of problems in that category (S3 for object storage, Glacier for cold storage. Of course now they have S3 IA, Kinesis Firehose can only write to S3 / Redshift / Ealsticsearch, Kinesis Streams can only support 1000 inserts / sec, … ). EBS optimized instances, Network optimized instances, EBS needs to warmed up before usage, disk sharding for improved RDS performance, load balancer warm up tickets, clock drifts for EC2 instances, micro instance gets shutdown routinely, no default encryption for data … and the list never ends. They don’t scale well, require the developer to tweak the knobs to scale up and down. Services on AWS have complex pricing model. It’s a nightmare for a developer to learn so many tools and API’s. There should be just one queuing technology and it should solve all the queuing needs and it should seamlessly scale. There should be one object storage system and it should take care of all object storage needs.
Google’s Pub/Sub addresses the needs for a queuing and notification system. Pub/Sub works with Compute, Storage, Logs, Dataflow, Autoscaler, Networking, Monitoring, and AppEngine. Google Storage is a unified storage solution. Google Dataflow can process both streams and batch data. Google cloud provides a set of well designed tools with high coherence. AWS is a bunch of tools built with no regards for ease of use and without any coherence.
With that let’s conclude this post on ease of use. Developer time is the most important resource a company has. It should be not be wasted with having to learn needless names, acronyms, wading through bad UI, learning multiple products that solve similar problems but cover different corners a solution. Let’s meet again on Big Data and Machine Learning!
Disclaimer: I should say that I am a big fan of Google Cloud. These are opinions of my own and not of my employer.
Edits: This post was written nearly a year ago. So here are some updates to keep the content fresh.
On UI: AWS made some changes to its Dashoboard, but still clunky and a long way to go.
On Databases: I am happy to see Google Cloud add PostgreSQL to its list of managed databases! And impressed with capabilities of Spanner! This move puts Google Cloud above AWS and other Cloud providers in Databases too!
Machine Learning: I am super impressed with Google Cloud ML (Hosted version of TensorFlow). If you or your company is betting big on AI or even thinking of AI / Machine Learning, make sure to try Google Cloud ML and ML APIs (Speech / Vision / Text / Video).
