infrastructure as a service iaas
play

Infrastructure as a Service (IaaS) Google Compute Engine AWS - PowerPoint PPT Presentation

Infrastructure as a Service (IaaS) Google Compute Engine AWS Elastic Compute Cloud (EC2) Azure Virtual Machines Digital Ocean Go Google gle Compu pute e En Engi gine ne (GC GCE) E) Infrastructure-as-a-Service Hardware service


  1. Infrastructure as a Service (IaaS) Google Compute Engine AWS Elastic Compute Cloud (EC2) Azure Virtual Machines Digital Ocean

  2. Go Google gle Compu pute e En Engi gine ne (GC GCE) E)  Infrastructure-as-a-Service  Hardware service for you to create and run virtual machine instances on  Lowest-level abstraction for cloud infrastructure  Flexible, but requires management  Good for arbitrary workloads  Provides vertical scaling options  Number of cores  Amount of RAM  Video card types  Type of disk (standard, SSD)  Up to 96 cores, 684 GB ! (10/2017)  Billed at a sub-minute level Portland State University CS 430P/530 Internet, Web & Cloud Systems

  3.  Seen previously  Segmentation and filtering for security  Instance templates and groups to auto-scale up at the VM level  Load balancing to distribute work across VMs globally Portland State University CS 430P/530 Internet, Web & Cloud Systems

  4. Pre-em emptible ptible VMs  VMs that Google can re-claim at any time if demand spikes  80% lower in cost!  Framestore  Video rendering for visual designers  15,000 cores needed at peak rendering times  Unneeded at quiet time  Not mission-critical, OK to be pre-empted temporarily  $300k saved by using on-demand, pre-emptible infrastructure over dedicated  Fault-tolerance built-in to application to restart interrupted jobs Portland State University CS 430P/530 Internet, Web & Cloud Systems

  5. Compute Engine access  All eventually hit API REST API directly Portland State University CS 430P/530 Internet, Web & Cloud Systems

  6. Via Web eb UI  console.cloud.google.com Portland State University CS 430P/530 Internet, Web & Cloud Systems

  7. Via Cloud oud Shel ell l or SDK DK  Command-line interface (CLI) with myriad command-line options  List gcloud compute instances list  Create gcloud compute instances create myinstance  Delete gcloud compute instances delete myinstance Portland State University CS 430P/530 Internet, Web & Cloud Systems

  8. Via libraries braries and d API  Through client libraries in many different languages (Python, JavaScript, Go, etc.)  Translates into HTTP/JSON API requests  Python example via google-api-python-client Python package compute = googleapiclient.discovery.build('compute', 'v1') def list_instances(compute, project, zone): result = compute.instances().list(project=project, zone=zone).execute() return result['items'] if 'items' in result else None Portland State University CS 430P/530 Internet, Web & Cloud Systems

  9. Via RES EST T API  Demo via interactive API Explorer  From web console, APIs and Services ➔ Library ➔ Compute Engine API ➔ Try this API in APIs Explorer  Example: listing instances via API  Enable OAuth2  compute.instances.list Portland State University CS 430P/530 Internet, Web & Cloud Systems

  10.  Example  REST API call  GET https://compute.googleapis.com/compute/v1/projects/{project}/zones/{zone }/instances  JSON response Portland State University CS 430P/530 Internet, Web & Cloud Systems

  11. Storage as a Service

  12. Ba Back ckgr ground: ound: Go Google gle file le sy syst stem em (GF GFS) S) 2003  Designed to support Google Search  Retrieving, storing, and querying of web pages at massive scale  Goals  Large data sets, high-throughput, low-latency querying  Durability and availability with very little management overhead  Dead disks simply replaced and system seamlessly adapts  Done via horizontal scaling and replication  http://research.google.com/archive/gfs-sosp2003.pdf  But, initially proprietary  Yahoo! later reverse-engineered GFS  Released as Hadoop Distributed File System (HDFS).  Open-sourced and distributed by Apache  Spun out commercially into … Portland State University CS 430P/530 Internet, Web & Cloud Systems

  13. Go Google gle Cloud ud Storag age e (gc gcs)  AWS equivalent is S3  Fully-managed (e.g. serverless), no-ops storage service  No administration or capacity management  Backed up and versioned automatically  Replicated and cached over multiple zones/regions  Fixed region for local computation  Multi-region for global file delivery  Adats to load and access patterns for high availability and throughput  Low latency: 10s of ms on first use, then faster via migration  Data encrypted at rest when not being used and in flight  Key sharding with parts of keys in multiple jurisdictions  But, unencrypted when being used  Massive scale  Autism Speaks: 1300 genomes and > 100 TB of data  Projected to 10,000 genomes > 1 PB of data Portland State University CS 430P/530 Internet, Web & Cloud Systems

  14. Model del  Storage done via "buckets"  Buckets, like URLs, must be uniquely identifiable  Object-level storage  Access storage similar to accessing objects over the web  Present an identifier, receive it back in its entirety  Different than block-level storage of disks Portland State University CS 430P/530 Internet, Web & Cloud Systems

  15. App pplications lications  Good for large unstructured data that does not need to be queried  Images, Video, Zip files  Structured data that needs to be queried should use DBs  Used to feed and store data and logs from all cloud services  BigQuery, App Engine, Cloud SQL, ComputeEngine, Dataflow/Dataproc, Etc.. Portland State University CS 430P/530 Internet, Web & Cloud Systems

  16. Access cess  Web interface  SDK via gsutil command and gs:// URI gsutil ls gsutil mb gs://xx-yy-zz  Client libraries (Python google-cloud-storage) from google.cloud import storage storage_client = storage.Client() bucket_name = 'my-new-bucket' bucket = storage_client.create_bucket(bucket_name)  REST API (Storage JSON API) Portland State University CS 430P/530 Internet, Web & Cloud Systems

  17. Database as a Service

  18. Main in ty type pes  NoSQL  SQL  Non-realational, unstructured data  Relational structured data  Complex querying using relations  Simple, fast key-value lookup  Schema (statically typed data)  Schemaless (dynamically typed data)  Strict transactional consistency  Loose eventual consistency  Vertical scaling  Horizontal scaling What explains the last two design patterns? Portland State University CS 430P/530 Internet, Web & Cloud Systems

  19. CAP P Theo eorem rem (Fox/B x/Bre rewer er 2000) 0)  Any networked system can have at most two of three desirable properties  C = consistency  A = availability  P = partition-tolerance  Can not have strong consistency in the wake of network outages with high availability  Two consistency options for networked databases  ACID (atomicity, consistency, isolation, durability)  To achieve strong consistency, lose “A” availability in the face of a network partition “P”  Can not perform transactions until all replicas fully on-line  Cloud SQL  BASE (basically available, soft state, eventual consistency)  To achieve high availability, lose “C” in the face of a network partition “P”  Cloud BigTable & Cloud Datastore Portland State University CS 430P/530 Internet, Web & Cloud Systems

  20. App pplication lication driv ives es consis nsisten ency cy mo model el  Bank accounts  Require strong consistency  High-score updates in a game?  Can survive with just eventual consistency  Need different implementations of databases (and DBaaS) to support different application requirements Portland State University CS 430P/530 Internet, Web & Cloud Systems

  21. Two arch chit itectural ectural opt ptions ons  Server-based  Machines with pre-configured database software  Cloud SQL, AWS RDS (MySQL, Postgres, MS SQL Server, etc.)  Many backend databases, many DBaaS  Serverless  Fully managed, NoOps, database services that automatically scale  Cloud Datastore, AWS DynamoDB  Cloud Spanner Portland State University CS 430P/530 Internet, Web & Cloud Systems

  22. Ser erverless erless app pplied lied to d databa tabases ses On-premises IaaS DBaaS App optimization App optimization App optimization Scaling Scaling Scaling High availability High availability High availability DB backups DB backups DB backups DB patching DB patching DB patching DB installation DB installation DB installation OS patching OS patching OS patching OS installation OS installation OS installation Server maintenance Server maintenance Server maintenance Rack and stack Rack and stack Rack and stack Power, HVAC, network Power, HVAC, network Power, HVAC, network Portland State University CS 430P/530 Internet, Web & Cloud Systems

  23. Server-based DBaaS

  24. Cloud SQL AWS RDS (Relational Database Service) Azure SQL Database

  25. Reca ecall ll  Drop-in replacement for MySQL or Postgres relational database  AWS RDS with MS SQL Server, Oracle, MariaDB  Uses pre-configured VMs on demand  Vertical scaling (read and write)  Horizontal scaling only for reads via replicas  Accessed via standard drivers Portland State University CS 430P/530 Internet, Web & Cloud Systems

  26. Serverless DBaaS

  27. Cloud Datastore (NoSQL) AWS DynamoDB Azure Cosmos DB

Recommend


More recommend