8.4.3: Reference Architecture Examples (AWS and GCP)

AWS Cloud-Native Application Architecture:

Consider a web application following a three-tier model (presentation, application, data) using AWS services in a modern way: - The presentation tier could be delivered via Amazon CloudFront (a Content Delivery Network) caching content from an S3 bucket that hosts a single-page web application (HTML/JS/CSS). Users first hit CloudFront which serves static assets and provides fast global access. - For dynamic requests, an Amazon API Gateway provides a unified API endpoint for the front-end to call. API Gateway handles routing of REST API calls to backend services and can authorize requests (e.g., via Amazon Cognito for user authentication). - The application logic is implemented as a set of microservices. In a fully serverless approach, these could be AWS Lambda functions triggered by API Gateway (each function handling a certain route or operation). In a container-based approach, these could be microservices running on an EKS or ECS cluster behind an internal load balancer. Either way, each microservice focuses on a specific domain (users, orders, inventory, etc.). - Services might communicate asynchronously using Amazon SNS/SQS. For instance, when an order is placed (API call handled by a Lambda), it might publish an "OrderPlaced" event to an SNS topic. Downstream services (inventory, shipping) subscribed to that topic will process the event. - The data tier uses purpose-chosen managed databases. For example, user accounts and orders might live in Amazon DynamoDB (a NoSQL database) for scalability, while analytical data or reporting could use Amazon RDS (relational) or Redshift for data warehousing. If the application needs full-text search, something like Amazon OpenSearch (Elasticsearch) could be part of the architecture. - Supporting services include Amazon CloudWatch for logging and monitoring (collecting logs from Lambda or containers, gathering metrics on API calls, etc.), and AWS X-Ray for tracing requests through the system. AWS IAM roles and security groups enforce least privilege access between services (for example, a Lambda function can be given permission to read a DynamoDB table but nothing else). - The whole application is deployed across multiple Availability Zones for high availability. If using EKS/ECS, the cluster spans AZs; if using Lambda, it’s inherently multi-AZ. The API Gateway and DynamoDB are multi-AZ by design. This ensures that even if one data center goes down, the application stays up.

For instance, AWS’s retail Reference Architecture might illustrate something like an e-commerce site where incoming requests go through a cloud load balancer, then to containerized microservices (perhaps running on ECS with an Auto Scaling Group of EC2 instances across AZs), and those services interact with other AWS components (Elasticache for caching, S3 for images, DynamoDB for product catalog, etc.). One slide from an AWS reference suggests an Ad Serving application architecture that could use content delivery, microservices and data stores in tandem.

GCP Cloud-Native Application Architecture:

On Google Cloud, a comparable architecture can be built with Google’s managed services: - Use Google Cloud Load Balancing (with a global HTTP(S) load balancer) as the entry point for users. This can route to different backends based on URL (for instance, static content vs API calls). - Static content and frontend can be hosted on Cloud Storage with Cloud CDN (similar to AWS’s S3 + CloudFront combo). For user authentication, GCP can integrate with Firebase Auth or Identity Platform, or you might use a Google Identity Aware Proxy to protect internal apps. - Microservices can run on Google Kubernetes Engine (GKE), each as a Deployment of pods, with a Kubernetes Service exposing it. Alternatively, they might run on Cloud Run for a fully managed experience. GCP’s App Engine is another option for certain types of services (especially if using languages/frameworks it supports directly). In one GCP reference, App Engine is used to host application services (which could represent a set of microservices behind the scenes). - For asynchronous messaging, Google Cloud Pub/Sub is a natural choice. It provides globally scalable publish/subscribe messaging. A Retail example on GCP might use Pub/Sub to stream transactions or events (e.g., sending a message whenever a user updates an inventory count). - Data storage is handled by GCP’s variety of managed databases: Cloud SQL or Cloud Spanner for relational data, Cloud Datastore/Firestore or Bigtable for NoSQL, and BigQuery for analytics. For example, a fraud detection component might utilize Cloud Bigtable for storing events and BigQuery for analyzing large datasets of transactions. GCP reference architectures often show data pipelines where events flow through Pub/Sub to processing via Cloud Dataflow (Apache Beam) and then into BigQuery for analysis. - Monitoring/Logging are handled by Google Cloud Operations Suite (formerly Stackdriver). This covers log aggregation, metrics, and distributed tracing (Stackdriver Trace or now Cloud Trace, which can be fed by OpenTelemetry instrumentation). - GCP also emphasizes fully managed services: for instance, instead of self-hosting a machine learning model, one could use Cloud Vision API, Cloud Translation API etc., or use Cloud Functions for lightweight event-triggered functions. These can all integrate into an application without managing servers.

A concrete GCP reference architecture given in a lecture example was a Real-Time Inventory system for retail: retail store inventory changes are captured by an App Engine service, which publishes events to Cloud Pub/Sub; those events are processed by Cloud Dataflow, updating aggregated data in Cloud Bigtable and Cloud SQL, and making inventory APIs available via App Engine services for use by other applications. This shows how multiple managed services can be composed to handle streaming data and serve it via APIs.

The above figure demonstrates how a cloud-native design can resemble a traditional three-tier architecture logically, but each tier is implemented with cloud-native components that automatically scale and are fully managed. The presentation layer is globally distributed (CDN), the app layer is serverless (Lambda) or container-based microservices, and the data layer uses cloud-native databases. Both AWS and GCP architectures share these traits, just with different service names.

High availability is built-in by using multi-zone deployments, and global scalability can be achieved by adding multi-region active-active setups or using services that are global (like Cloud Pub/Sub or DynamoDB Global Tables). It’s also important to consider network topology – for example, using a Virtual Private Cloud (VPC) in AWS or Virtual Private Cloud in GCP to isolate and secure services, connecting them via VPC peering or cloud VPNs if needed (for hybrid scenarios).

By studying such reference architectures, one can see the practical realization of cloud-native principles: each service is independently deployed and managed, the infrastructure is largely automated (Infrastructure as Code templates would define these cloud resources), and the system can gracefully handle changes in load or component failure through the dynamic nature of the platforms.