📘 Tutorial 11: Modern Cloud-Based and Web Service Applications

COMP347 (Revision 10) | TrustOpen University

📑 Table of Contents

🎯 Learning Objectives

Upon completion of this expanded tutorial, students will be able to:

🔭 Overview

Modern Internet applications are no longer monolithic, single‑server systems. They are composed of many small, independently deployable services running in containers across multiple cloud regions. This tutorial provides a rigorous, university‑level examination of the technologies and architectures that power today's cloud‑based applications.

We begin with cloud computing models (IaaS, PaaS, SaaS) and the shared responsibility model. We then explore cloud‑native principles, including microservices, containers, and DevOps. A significant portion is dedicated to web service communication: we compare REST, GraphQL, and gRPC, examining their performance characteristics, strengths, and weaknesses. We then dive into microservices architecture patterns (API Gateway, Circuit Breaker, Service Registry) and their implementation in Kubernetes. The tutorial also covers serverless computing (FaaS), service meshes (Istio, Linkerd), and emerging trends like edge computing and WebAssembly. Throughout, we emphasise the trade‑offs between flexibility, performance, and operational complexity.


1. Cloud Computing – Models and Formal Definitions

1.1 Service Models

ModelDefinitionUser ManagedProvider Managed
IaaS (Infrastructure as a Service)Virtualised compute, storage, and networkingOS, middleware, runtime, data, applicationsVirtualisation, hardware, storage, networking
PaaS (Platform as a Service)Platform for developing and deploying applicationsApplications, dataOS, middleware, runtime, infrastructure
SaaS (Software as a Service)Ready‑to‑use applications delivered over the InternetApplication configuration, user dataEverything else (app, runtime, OS, infrastructure)

1.2 Deployment Models


2. Cloud‑Native Principles and DevOps

2.1 Cloud‑Native Definition (CNCF)

Cloud‑native technologies empower organisations to build and run scalable applications in dynamic environments (public, private, hybrid). Key principles:

2.2 DevOps and CI/CD

DevOps bridges development and operations, emphasising collaboration, automation, and measurement. CI/CD (Continuous Integration / Continuous Delivery) pipelines automate building, testing, and deploying code, reducing manual errors and accelerating release cycles.


3. Web Services – REST, GraphQL, and gRPC

3.1 REST – Representational State Transfer

3.2 GraphQL

3.3 gRPC

3.4 Comparison

AspectRESTGraphQLgRPC
TransportHTTP/1.1 or HTTP/2HTTP/1.1 or HTTP/2HTTP/2 (or HTTP/3)
Data formatJSON, XML, etc.JSON (query), response JSONProtocol Buffers (binary)
Message sizeLarger (textual)Larger (textual)Smaller (binary)
LatencyHigherHigherLower
StreamingLimited (WebSocket)Subscriptions (over WebSocket)Full bidirectional
Client flexibilityFixed responsesHigh (client selects fields)Fixed methods
ToolingMature (OpenAPI)Good (Apollo, GraphiQL)Good (protoc, gRPC‑web)
Browser supportNativeVia client librariesVia gRPC‑web

4. Microservices Architecture – Patterns and Trade‑offs

4.1 Key Patterns

4.2 Trade‑offs

AdvantageChallenge
Independent deploymentsDistributed complexity (network, latency)
Technology diversityOperational overhead (monitoring, logging)
Scalability per serviceData consistency (distributed transactions)
Fault isolationService discovery and load balancing
Team autonomyEnd‑to‑end testing complexity

5. Containerization and Orchestration (Kubernetes)

5.1 Containers (Docker)

5.2 Kubernetes Architecture

Master Node: API Server Scheduler Controller Manager etcd (distributed key‑value store) Worker Nodes: Kubelet Container Runtime (Docker, containerd) kube‑proxy Pods (containers) Services (stable IP, load balancing) Ingress (HTTP routing) ConfigMaps, Secrets, PersistentVolumes

5.3 Key Kubernetes Concepts


6. Serverless Computing and FaaS

6.1 Function‑as‑a‑Service (FaaS)

6.2 Cold‑Start Latency

When a function is invoked after being idle, the platform initialises a new container (downloading the code, starting the runtime). This cold start can add 100‑1000 ms latency. Mitigations:

6.3 Trade‑offs


7. Service Mesh and Observability

7.1 Service Mesh Overview

A service mesh is a dedicated infrastructure layer for handling service‑to‑service communication. It provides:

The data plane (sidecar proxies, e.g., Envoy) intercepts traffic; the control plane (Istio, Linkerd) configures and manages policies.

7.2 Observability Pillars

Tools: Prometheus (metrics), ELK/EFK (logs), Jaeger/Zipkin (tracing).


8. Emerging Trends – Edge, WebAssembly, and Beyond

8.1 Edge Computing

8.2 WebAssembly (Wasm) on the Server

8.3 Quantum‑Safe Cryptography

With the advent of quantum computers, current RSA/ECC will become vulnerable. NIST is standardising post‑quantum algorithms (e.g., CRYSTALS‑Kyber, CRYSTALS‑Dilithium). Applications must plan for migration to ensure long‑term security.


📝 Quiz: Tutorial 11

Q1: In the shared responsibility model for IaaS, who is responsible for patching the guest operating system?

Answer

The customer/user.

Q2: What is the primary advantage of GraphQL over REST?

Answer

Clients can request exactly the fields they need, avoiding over‑fetching and under‑fetching.

Q3: Which protocol does gRPC use for transport?

Answer

HTTP/2.

Q4: What is the role of an API Gateway in a microservices architecture?

Answer

It acts as a single entry point, routing requests to appropriate services, handling authentication, rate limiting, and aggregating responses.

Q5: What is the main purpose of the Circuit Breaker pattern?

Answer

To prevent cascading failures by stopping requests to a failing service, allowing it to recover.

Q6: In Kubernetes, what is a Pod?

Answer

The smallest deployable unit, consisting of one or more containers that share network and storage.

Q7: What is a cold‑start in serverless computing?

Answer

The delay incurred when a function is invoked after being idle, requiring the platform to initialise a new container.

Q8: What is the purpose of a service mesh?

Answer

To handle service‑to‑service communication, providing traffic management, security (mTLS), and observability (metrics, tracing).

Q9: Which emerging technology provides a secure, portable binary format for serverless workloads?

Answer

WebAssembly (Wasm).

Q10: What is the difference between horizontal and vertical scaling in cloud applications?

Answer

Horizontal scaling adds more instances (e.g., more pods); vertical scaling adds more resources (CPU/RAM) to a single instance.

Q11: In a microservices architecture, what is the role of a Service Registry?

Answer

It stores the network locations (IP, port) of service instances for service discovery.

Q12: What is the advantage of using Protocol Buffers over JSON for service communication?

Answer

Protocol Buffers are binary, smaller, and faster to serialise/deserialize, improving performance.


✏️ Exercises: Tutorial 11

Exercise 1 – API Design Decision

You are building a public API for a mobile app with limited bandwidth. Should you use REST, GraphQL, or gRPC? Justify.

Sample Solution

gRPC would be best because Protocol Buffers are binary and compact, reducing bandwidth usage. However, if the client is a browser, gRPC‑web adds overhead. GraphQL could be a good compromise if flexibility is needed. REST is simpler but less efficient. For mobile, gRPC is often recommended for its performance and streaming capabilities.

Exercise 2 – Kubernetes Deployment

Design a Kubernetes deployment for a web application with a frontend, backend API, and a database. State the resources you would use.

Sample Solution

Deploy frontend as a Deployment with a Service (LoadBalancer). Backend as a Deployment with a ClusterIP Service. Database as a StatefulSet with PersistentVolume and a Headless Service for stable network identity. Use ConfigMap for environment variables, Secret for credentials, and Ingress for HTTP routing.

Exercise 3 – Circuit Breaker Scenario

Explain how a circuit breaker would prevent a cascading failure when a database service becomes slow.

Sample Solution

The circuit breaker monitors the failure rate of calls to the database. When the error rate exceeds a threshold (e.g., 50% over the last 10 seconds), the circuit opens. Subsequent calls return a fallback response (e.g., cached data or an error) without attempting the call, allowing the database to recover. After a timeout, the circuit goes to half‑open state to test if the database is healthy.

Exercise 4 – Serverless vs Containers

Compare serverless (FaaS) and containers for a background job processing pipeline. Which is more suitable?

Sample Solution

If the jobs are short‑lived, infrequent, and can tolerate cold starts, serverless is simpler and cost‑effective. If jobs are long‑running, require custom dependencies, or have high throughput, containers with Kubernetes provide more control and predictability. For a mixed workload, a combination (serverless for sporadic jobs, containers for steady state) could be optimal.

Exercise 5 – Observability Implementation

Design an observability strategy for a microservices application. What metrics, logs, and traces would you collect?

Sample Solution

Metrics: request rate, latency percentiles (p50, p95, p99), error rate, CPU/memory for each service. Logs: structured JSON logs with request ID, service name, timestamp, and level. Traces: distributed traces using OpenTelemetry, with spans for each service call, database queries, and external API calls. Export metrics to Prometheus, logs to ELK, and traces to Jaeger.

Exercise 6 – API Versioning Strategy

Propose a versioning strategy for a REST API that is used by multiple clients with different update cycles.

Sample Solution

Use URL path versioning (e.g., `/v1/users`, `/v2/users`). Maintain support for old versions for a grace period (e.g., 12 months). Communicate deprecation via headers (`Deprecation: true`). Use content negotiation as an alternative (e.g., `Accept: application/vnd.example.v2+json`). Version increment for breaking changes only; additive changes can be backward‑compatible.


📚 Homework: Tutorial 11

Homework 1 – Cloud Cost Modeling

Compare the cost of running a web application on IaaS (EC2) vs PaaS (Elastic Beanstalk) vs FaaS (Lambda) for a variable workload. Model the cost as a function of CPU hours, memory, and network transfer.

Guidance

Use AWS pricing; include EC2 reserved vs on‑demand; Lambda costs are based on requests and execution time.

Homework 2 – Microservices Decomposition

Take a monolithic e‑commerce application (user management, product catalog, orders, payments, inventory) and propose a microservice decomposition. Justify the boundaries and discuss the data consistency challenges.

Guidance

Use domain‑driven design; each service owns its own database; use eventual consistency with event‑driven communication (e.g., Kafka) for cross‑service transactions.

Homework 3 – Kubernetes vs Docker Swarm

Compare Kubernetes and Docker Swarm in terms of architecture, features, ecosystem, and learning curve. Provide a recommendation for a small team.

Guidance

Kubernetes is more powerful but complex; Swarm is simpler but less feature‑rich. For a small team with modest requirements, Swarm may be sufficient; for growth and advanced features, Kubernetes is preferred.

Homework 4 – gRPC vs REST Performance Benchmark

Implement a simple echo service in both REST (JSON) and gRPC (Protobuf). Benchmark throughput and latency under load (e.g., using `wrk` or `ghz`). Report the results and analyse the differences.

Guidance

gRPC typically shows higher throughput and lower latency due to binary serialisation and HTTP/2 multiplexing.

Homework 5 – Service Mesh Implementation

Design a service mesh architecture using Istio for a multi‑service application. Describe the control plane (Pilot, Mixer, Citadel) and data plane (Envoy proxies). Outline the benefits for security, traffic management, and observability.

Guidance

Include mutual TLS, canary deployments, circuit breaking, and distributed tracing integration.


📌 Summary

This expanded tutorial has provided a comprehensive, university‑level examination of modern cloud‑based and web service applications. Key takeaways:

Understanding these technologies and trade‑offs is essential for designing and operating modern, scalable, and resilient cloud applications.