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