-
The Beginning: Amazon Web Services (AWS), Elastic Compute Cloud (EC2), rented VMs, launched in 2006
-
Programmers previously optimized when things were too slow, but now we need to optimized when it is too expensive (cost is not always obvious at the moment you are running a job so that need to do "back of the envelope" estimates until you get a bill)
-
Service Types:
-
IaaS (Infrastructure as a Service)
EC2, other services that feel closer to raw hardware
virtual disks, virtual network, some storage systems, etc.
cheap+flexible -- you can deploy anything on it (Cassandra, Kafka, etc).
-
PaaS (Platform as as Service)
Cloud provider has deployed systems on the infracture; you pay to use the deployed system
databases, application framework/platforms, ML training/deployment systems less flexible, easier to use
often more expensive (though not necessarily more than doing it yourself due to effiencies available to cloud provider but not you)
-
-
Lock In: If it's hard to move to a competing cloud, you are "locked in".
- PaaS: services are often unique, and it would be hard to move to a different cloud providers.
- IaaS: services like VMs are more uniform -- it would be easier to switch to a different cloud to find the cheapest place to rent VMs.
- Data: cloud providers often make it free to bring data into the cloud (ingress) but expensive to take it out (egress).
-
Compute
- Multi-tenant Hosts: typical case
- Sole-tenant Hosts: better isolation/security, $1000s/month
- Containers (Kubernetes Engine)
- Serverless Functions: functions run when events happen; pay by the millisecond
-
Memory
-
IaaS
memory is often roughly proportional to CPU resources
"memory optimized" VMs skew heavy on RAM (very expensive! at high end >10 TB)
-
PaaS: often open-sources platforms provided as a service.
- memcached (cache)
- redis (in-memory DB)
-
-
Storage
VM disks are virtual block devices
- can be attached, detached, re-attached to VMs
- different disk types offer different performance/price tradeoffs
- HDD (standard); SSD (balanced, SSD, extreme)
- price depends on size and type (power off still generates cost)
-
Network
- Hierarchy: continents > regions (data center consisting of 1 or more nearby buildings) > zone (area of region with fast interconnect but usually common points of failure, like power, routers, etc)
- Fault tolerance
- Deploy under the assumption that nodes in the same zone may reasonably all go down together (e.g., due to power loss)
- Being extra careful: assume a region can go down (e.g., tornado destroys couple buildings)
- Clouds generally bill per GB of network I/O
- ingress is usually free (incentivize you to start using the service, charge to move your data elsewhere
- egress rate is complicated (depends on many factors)
- Internet: $0.085/GB
- Same continent: $0.05/GB (Asia)
- Same region: $0.01/GB
- Same zone: free
-
Common Pattern
Duration is calculated from the time your code begins executing until it returns or otherwise terminates, rounded up to the nearest 1 ms (check if you have a large number of small ops getting rounded up)
-
On-Demand vs. Spot Instances
- on-demand instances: constant (high) price. Can generally get a VM. Won't be taken away from your arbitrarily. Used when capacity is needed at specific times.
- spot instances: price varies throughout day. If you're not willing to pay enough, your computation waits for a cheaper price. VM might be interrupted ("preempted") once started. Excellent for once-a-day batch jobs.
-
Scaling and Billing
- fixed: you configure what you want, then pay a constant amount. Low risk, often wasteful, doesn't handle unexpected bursts. Example: VM instances.
- auto scaling: the cloud service detects high/low load and automatically increases/ decreases your reservation. Often cannot scale to zero. Example: Elastic Beanstalk
- pay as you go: pay for actual resources consumed with fine granularity. Example: AWS Lambda.
-
Google Architecture (early systems)
-
Google (Papers) => Hadoop (open-source software)
-
HDFS - Spark - Cassandra - Kafka
-
Colossus (HDFS)
Colossus is indirectly available to customers via GCS and other services
- Users can create GCS "buckets" containing "objects" (corresponding to files in Colossus)
- Buckets can be public or private
- GCS connector for Hadoop implements HDFS interface over GCS
- Applications (like Spark) can switch out HDFS for GCS
-
BigQuery (Spark)
- similar to Spark SQL
- query engine based on Dremel (2010 system in Google that replaced a lot of MapReduce work)
- tightly integrated with BigQuery storage engine (that uses Colossus)
- can also run queries on other data sources
Blurred analytics architecture
- data warehouse: BigQuery query engine with BigQuery storage
- data lake: part of BigQuery used with another system
-
For analytics, we'll want a column-oriented format:
- Parquet
- ColumnIO
- Dremel (used in BigQuery) originally used ColumnIO files
- ColumnIO inspired Parquet files (introduced by Twitter+Cloudera)
- Capacitor
-
sucessor to ColumnIO in Google
-
optimized for repeated values
-
optimization: run-length encoding
-
optimization: dictionary encoding
-
-
-
protocol buffers (protobufs)
- some protobufs at Google had grown to have 100s of thousands of columns
- some protobufs at Google had grown to have 100s of thousands of columns
-
BigTable (Cassandra)
- BigTable is directly available to customers as a GCP service
- It's now built on Colossus.
-
Kafka
- Apache Kafka - open source
- Confluent Kafka - closed source, more features, available as service is the major cloud providers