Designing Cloud Native Apps in GCP

## Selecting the appropriate Cloud Service Model - Infrastructure-as-a-service (IaaS) model - large degree of fliexibility in implementation - requries a significant amount of labor - Software-as-a-service (SaaS) model - higher velocity for delivery of services while maintaining a fair amount of flexibility - at the expense of flexibility - Iaas -> CaaS -> PaaS -> Faas -> Saas (from low fliexibility to high velocity) ## Protability and Design Consideration - Protable Languages - Platform considerations - Platform specific designs are targeted for a specific environment - Vendor lock in ## Evaluating Different Service Technologies - Google App Engine - you want to focus on writing code, never wants to touch a server, cluster or infrastructure - you want to build a highly reliable and scalable serving app or component without doing it all yourself - you value developer velocity over infrastructure control - Minimize operational overhead - Google Kubernetes Engine - you want to increase velocity and improve operability dramatically by separating the app from the OS - you need a secure, scalable way to manage containers in production - you don't have dependencies on a specific operating system - Google Compute Engine - you need complete control over your infrastructure and direct access to high-performance hardware such as GPUs and local SSDs - you need to make OS-level changes, such as providing your own network or graphic drivers, to squeeze out the last drop of performance - You want to move your application from your own colo or datacenter to the cloud without rewriting it - You need to run a software package that can't easily be containerized or your want to use existing VM images ## Operating System Considerations - CentOS - Container-optimized OS from Google - CoreOS - Debian - Red Hat Enterprise Linux (RHEL) - SUSE Enterprise Linux - SLEX for SAP - Ubuntu - Windows Server ## Location of Your Service Components - to cut down on latency and provide better services to your end users ## Microservice Architectures - Separated into independent constituent parts, with each part having its own realm of responisbility - Refactored from monolithic apps that have very tight coupling to a micro-service based architectures - Advantages: - the code base becomes more modular and easier to manage - it becomes much easier to reuse services for other applications - it is much easier to scale and tune individules services ## Defining Key Structures - avoid monotonically increasing keys - instead, migrate to keys that use random numbers, such as UUID ## Session Management - keep a session cache - Cloud Spanner - a limit of 10K sessions per database per node - a client can delete a session - The Cloud Spanner database service can delete a session when the session is idle for more than 1 hour ## API Management Consideration - Apps should be designed to have loosely coupled components - Pub/Sub model enables event-driven architectures & asyn parallel processing - Pulisher---(publish event)---> Event Channel --(Fire Event)---> Subscriber - Pulisher---(publish event)---> Event Channel <--(Subscribe)---- Subscriber ## Health Checks - Cloud Load Balancing - Interal Load Balancing - TCP Proxy Load Balancing - SSL Proxy Load Balancing - HTTP(s) Load Balancing - Stackdriver Monitoring --- uptime check ---> storage/database/network - Example: ``` gcloud compute health-checks create [PROTOCOl] [HEALTH_CHECK_NAME] \ --description=[DESCRIPTION] \ --check-interval=[CHECK_INTERVAL] \ --timeout=[TIMEOUT] \ --healthy-threshold=[HEALTHY_THRESHOLD] \ --unhealthy-threshold=[UNHEALTHY_THRESHOLD] \ ...additional flags ```