Unit 5: Cloud-Native Development - Subjective Questions

Cloud-native architecture is an approach to designing, building, and operating applications that fully uses cloud capabilities such as elasticity, automation, managed services, and distributed computing.

Major characteristics:

• Microservices: The application is divided into small, independently deployable services.
• Containerization: Services are packaged with their dependencies in portable containers.
• Dynamic orchestration: Platforms such as Kubernetes automate deployment, scaling, and recovery.
• Elasticity: Resources can be increased or decreased according to workload.
• Resilience: Failures are expected and handled through retries, redundancy, timeouts, and circuit breakers.
• Automation: CI/CD pipelines and infrastructure as code reduce manual operations.
• Observability: Logs, metrics, and distributed traces provide visibility into system behavior.

Thus, cloud-native systems are designed to be scalable, resilient, rapidly deployable, and operationally automated.

A monolithic application contains most business functions in a single deployable unit, whereas a cloud-native microservices application divides functionality into independent services.

Trade-off: Microservices improve agility, scalability, and fault isolation, but introduce distributed-system challenges such as network latency, service discovery, data consistency, monitoring, and operational complexity.

Loose coupling means that a service has minimal knowledge of and dependency on the internal implementation of other services. Services interact through stable contracts rather than sharing code, databases, or internal data structures.

Techniques for achieving loose coupling:

• Define versioned APIs using REST, gRPC, or well-specified messaging contracts.
• Use asynchronous communication through queues or event brokers when immediate responses are unnecessary.
• Give each service ownership of its own data instead of sharing database tables.
• Use service discovery rather than hard-coded network addresses.
• Apply timeouts, retries with backoff, circuit breakers, and bulkheads.
• Maintain backward compatibility when API or event schemas change.
• Avoid coordinated deployments by allowing services to evolve independently.

Benefits include independent deployment, fault isolation, easier scaling, and team autonomy. However, excessive decoupling may increase message management, consistency, and debugging complexity.

Service discovery is the mechanism through which a service dynamically finds the current network locations of other service instances. It is necessary because container and virtual-machine addresses can change during deployment, scaling, or failure recovery.

Client-side discovery:

1. Service instances register their addresses in a service registry.
2. The client queries the registry.
3. The client selects an instance and sends the request directly.

• Advantages: Direct communication and client-controlled load balancing.
• Limitations: Discovery and balancing logic must be included in every client technology.

Server-side discovery:

1. The client sends a request to a load balancer, proxy, or API gateway.
2. The intermediary queries or monitors the registry.
3. It forwards the request to an available instance.

• Advantages: Simpler clients and centralized traffic policies.
• Limitations: The intermediary adds another network hop and must be highly available.

Registries use health checks and registration updates to remove failed instances and add newly created ones.

Load balancing distributes incoming requests among multiple healthy service instances. It improves throughput, availability, resource utilization, and fault tolerance while preventing a single instance from becoming overloaded.

Common algorithms:

• Round robin: Sends requests to instances in sequence. It is simple but ignores differences in capacity and current load.
• Weighted round robin: Assigns more requests to instances with greater capacity.
• Least connections: Selects the instance with the fewest active connections and is useful for long-lived requests.
• Least response time: Considers observed latency and often the number of active connections.
• Random selection: Chooses an instance randomly and works reasonably well at large scale.
• Consistent hashing: Maps a key, such as a user identifier, to an instance and minimizes remapping when instances change.

Load balancing may occur at the network, application, ingress, API-gateway, or service-mesh level. Effective balancing must use health checks so that requests are not routed to failed instances.

These mechanisms form a continuous control process:

1. Registration: When a new service instance starts, it registers itself or is automatically detected by the orchestration platform.
2. Health checking: Readiness checks determine whether the instance can receive traffic, while liveness checks determine whether it should be restarted.
3. Discovery: Clients, proxies, or load balancers obtain the list of currently available instances.
4. Load balancing: Requests are distributed across the healthy and ready instances.
5. Scaling: When demand increases, the autoscaler creates new instances. They receive traffic only after becoming ready.
6. Failure handling: Failed instances are marked unhealthy, removed from discovery results, and replaced when necessary.
7. Scale-in: Before an instance is terminated, it should be removed from routing and allowed to drain active connections.

This coordination prevents traffic from reaching unavailable or initializing instances and allows the system to adapt without relying on fixed IP addresses.

Autoscaling automatically adjusts computing resources according to workload, performance targets, or schedules.

• Horizontal scaling: Adds or removes service instances. For example, a deployment may increase from 4 to 10 pods. It improves availability and is well suited to stateless services.
• Vertical scaling: Increases or decreases CPU, memory, or other resources assigned to an existing instance. It is useful when an application cannot easily run in parallel, but may require restarting the instance.
• Predictive scaling: Uses historical patterns or forecasting to provision resources before expected demand arrives.
• Scheduled scaling: Changes capacity at predetermined times, such as before a daily traffic peak.

Autoscaling may use CPU utilization, memory, request rate, latency, queue length, or custom business metrics. A good policy includes minimum and maximum capacity, cooldown periods, stabilization windows, and safe scale-in behavior. Autoscaling also requires load balancing and sufficiently fast resource provisioning.

Suppose the expected request rate is requests per second and one replica can safely process requests per second. Let the target utilization be , where . The usable capacity of one replica is .

The required number of replicas is therefore:

For example, if requests per second, requests per second, and , then:

Thus, at least 6 replicas are required.

An autoscaler can also estimate desired replicas from a measured metric:

where is the observed metric and is its desired value.

In practice, the calculation should be combined with:

• Minimum and maximum replica limits
• Startup time and readiness checks
• Cooldown or stabilization periods
• Queue length and latency measurements
• Spare capacity for sudden traffic bursts
• Gradual scale-in to avoid oscillation

The formula provides a useful starting point, but production capacity must be validated through load testing.

Cloud-native data management often follows the database-per-service principle. Each service owns its data and exposes it through an API or published events rather than allowing other services to access its tables directly.

Key principles:

• Service teams control their own schemas and persistence logic.
• Different services may use different database technologies, known as polyglot persistence.
• Data changes are shared through APIs, events, or change-data-capture mechanisms.
• Stateless service instances store durable state in external data systems.
• Databases require backups, encryption, replication, and access controls.

Major challenges:

• Transactions spanning several services are difficult.
• Replicated data may become temporarily inconsistent.
• Joins across service-owned databases are not straightforward.
• Schema and event evolution must preserve compatibility.
• Duplicate messages require idempotent processing.
• Reporting may require a separate warehouse, lake, or read model.

The goal is to preserve service autonomy while providing reliable, secure, and appropriately consistent data.

A Saga represents a distributed business transaction as a sequence of local transactions. Each participating service updates its own database. If a later step fails, previously completed steps are logically undone using compensating transactions.

For example, an order workflow may:

1. Create an order.
2. reserve inventory.
3. authorize payment.
4. arrange delivery.

If payment authorization fails, compensation may release the inventory and cancel the order.

Choreography-based Saga:

• Services publish events and react to events from other services.
• Advantages: Decentralized and loosely coupled.
• Limitations: The workflow becomes difficult to understand, monitor, and modify when many services participate.

Orchestration-based Saga:

• A saga orchestrator explicitly commands participants and tracks progress.
• Advantages: Workflow logic and failure handling are easier to visualize and control.
• Limitations: The orchestrator can become complex and may create stronger coordination dependencies.

Sagas do not provide automatic isolation like a single database transaction. Systems must handle retries, duplicate events, out-of-order messages, idempotency, timeouts, and compensation failures.

In a distributed data system, a network partition may prevent nodes or services from communicating. The CAP perspective states that during such a partition, a system must make a trade-off between:

• Consistency: Every read observes the latest successful write or reports an error.
• Availability: Every request receives a non-error response, although the data may not be the latest.
• Partition tolerance: The system continues operating despite communication failures between nodes.

Because partitions cannot be completely avoided in distributed cloud environments, systems commonly choose different consistency and availability trade-offs for different operations.

Eventual consistency means replicas or service-owned views may temporarily differ, but converge when updates have propagated. It is often used because it enables higher availability, asynchronous processing, loose coupling, and geographic distribution.

However, it can cause stale reads, conflicting updates, and confusing user experiences. Mitigation techniques include version numbers, idempotency keys, conflict-resolution rules, read-your-writes behavior, reconciliation jobs, and clear pending states. Strong consistency should still be used where business correctness requires it, such as certain balance or uniqueness checks.

The twelve-factor app methodology provides practices for building portable, scalable, and maintainable software-as-a-service applications.

1. Codebase: Maintain one codebase in version control, with many deployments.
2. Dependencies: Explicitly declare and isolate all dependencies.
3. Config: Store environment-specific configuration outside the code.
4. Backing services: Treat databases, queues, and caches as attached resources.
5. Build, release, run: Keep build, release configuration, and execution as separate stages.
6. Processes: Execute the application as one or more stateless processes.
7. Port binding: Export services through a self-contained network port.
8. Concurrency: Scale by adding process instances rather than relying on one large process.
9. Disposability: Support fast startup and graceful shutdown.
10. Development and production parity: Keep environments and workflows as similar as practical.
11. Logs: Treat logs as event streams and send them to external aggregation systems.
12. Admin processes: Run administrative tasks as one-off processes using the same code and configuration.

These factors support container deployment, automation, horizontal scaling, continuous delivery, failure recovery, and operational consistency. Modern cloud-native systems extend them with security, observability, API design, and orchestration practices.

A containerized microservice can apply the methodology as follows:

• Store its source code in a dedicated version-controlled codebase.
• Declare exact dependencies in a package manifest and lock file.
• inject configuration, endpoints, and feature settings through environment variables or a configuration service.
• Supply secrets through a secure secret manager rather than embedding them in an image.
• Build an immutable container image and promote the same image across environments.
• Keep application instances stateless and store durable data in backing services.
• Expose the application through a configured port.
• Scale by creating additional container replicas.
• Start quickly, handle termination signals, stop accepting new traffic, and complete in-flight work before shutdown.
• Send logs to standard output so the platform can aggregate them.
• Run database migrations and maintenance commands as controlled one-off jobs.
• Use CI/CD and environment templates to reduce differences between development, testing, and production.

These practices produce portable deployments and allow orchestration platforms to scale, replace, and update instances safely.

Serverless architecture is a cloud execution model in which the provider manages server provisioning, runtime infrastructure, scaling, and much of the availability management. Developers deploy functions or use managed backend services without directly administering servers.

In Function as a Service, an event such as an HTTP request, queue message, file upload, database change, or schedule triggers a short-lived function. The platform starts as many function instances as needed and normally charges according to executions and resource consumption.

Benefits:

• Little infrastructure administration
• Automatic scaling, including possible scale-to-zero
• Fine-grained pay-per-use billing
• Rapid development and deployment
• Easy integration with managed cloud services
• Isolation of event-processing tasks

Suitable use cases:

• API endpoints and webhooks
• Image or document processing
• Scheduled automation
• Stream and event processing
• Queue consumers
• Lightweight integration workflows

Serverless is less suitable for workloads requiring long execution, specialized infrastructure, consistently low latency without provisioning, or extensive control over the runtime.

Selection guidance:

• Use serverless for bursty, event-driven, short-duration workloads.
• Use containers for APIs, microservices, workers, and workloads needing runtime control.
• Use virtual machines for legacy software, custom operating systems, strong isolation, or specialized kernel requirements.

A practical cloud-native system may combine all three rather than selecting only one deployment model.

Major limitations and mitigations include:

• Cold-start latency: An inactive function may take extra time to initialize. Mitigate through smaller packages, efficient initialization, provisioned concurrency, or asynchronous invocation.
• Execution limits: Providers impose duration, memory, payload, and concurrency limits. Divide long jobs into stages or use containers for unsuitable tasks.
• Stateless execution: Local memory and storage cannot be treated as durable. Store state in managed databases, caches, or object storage.
• Vendor lock-in: Event formats and managed-service APIs may be provider-specific. Isolate provider adapters and use open standards where practical.
• Observability: One request may cross many functions and services. Use correlation identifiers, centralized logs, metrics, and distributed tracing.
• Duplicate delivery: Event systems may deliver messages more than once. Implement idempotency and deduplication.
• Security complexity: Many small functions can create excessive permissions. Apply least-privilege identities, secret management, and automated policy checks.
• Cost unpredictability: High invocation volume or inefficient functions can become expensive. Monitor cost metrics, set budgets, and optimize memory and execution time.

Netflix evolved from a largely monolithic data-center application toward a cloud-based architecture composed of independently deployable services. Its streaming workload requires global availability, elastic capacity, rapid delivery, and graceful handling of failures.

Important practices associated with the case study:

• Decomposing business capabilities into independently operated services
• Automatically scaling resources to respond to variable viewing demand
• Using service discovery and load balancing to route traffic among changing instances
• Applying timeouts, retries, circuit breakers, and fallback behavior to contain failures
• Using extensive metrics, logging, tracing, and operational dashboards
• Automating deployment through continuous-delivery pipelines
• Employing chaos engineering to validate behavior under realistic failures
• Using content delivery infrastructure to serve media close to viewers

Architectural lessons:

• Cloud-native systems should assume that components will fail.
• Resilience must be designed and continuously tested.
• Team ownership and deployment independence improve delivery speed.
• Observability and automation are essential at large scale.
• Microservices are not free; they require strong platform engineering and operational discipline.

As Amazon's commerce platform grew, tightly connected application components made independent development and scaling increasingly difficult. The organization moved toward services aligned with business capabilities, such as catalog, ordering, payment, inventory, and recommendation functions. Teams exposed functionality through clearly defined service interfaces instead of depending directly on another team's internal data.

Important ideas illustrated by the case:

• Small teams can own services throughout development and operation.
• Service contracts establish clear organizational and technical boundaries.
• Independent deployment reduces coordination across a large engineering organization.
• Each service can scale according to its workload.
• Automation, monitoring, and standardized infrastructure support many autonomous teams.
• Managed cloud services can provide reusable storage, messaging, computing, and deployment capabilities.

Lessons:

• Architecture and team structure influence each other.
• APIs should be treated as stable products with versioning and governance.
• Service ownership must include reliability, security, cost, and on-call responsibilities.
• Decentralization should be balanced with platform standards to avoid uncontrolled technology and operational complexity.

A ride-hailing platform must coordinate riders, drivers, trips, pricing, maps, notifications, and payments in near real time. As Uber expanded in traffic, features, and geographic reach, a single application became difficult to scale and modify. Decomposition into domain-oriented services allowed different capabilities to evolve independently.

Benefits of the microservices approach:

• Independent scaling of high-demand functions such as location and dispatch
• Parallel development by teams owning different domains
• Better fault isolation than a single large deployment
• Selection of suitable storage and processing technologies for different workloads
• Faster release of localized or domain-specific features

Complexities introduced:

• A very large number of service dependencies
• Difficult end-to-end debugging and incident diagnosis
• Network latency and partial failures
• Data consistency across trips, pricing, and payments
• API and event-schema evolution
• Need for service discovery, traffic management, and standardized observability

The case demonstrates that large microservice environments require strong platform capabilities, dependency management, distributed tracing, service-level objectives, and clear domain boundaries.

A suitable design can divide the retail platform into catalog, search, cart, order, inventory, payment, notification, and user services. Clients enter through a content delivery network and an API gateway.

Request and service layer:

• The API gateway performs routing, authentication, rate limiting, and request validation.
• Stateless microservices run as replicated containers across failure zones.
• Platform-based service discovery tracks healthy and ready instances.
• Load balancers or a service mesh distribute traffic and remove unhealthy instances.
• Timeouts, circuit breakers, bulkheads, and bounded retries prevent cascading failures.

Autoscaling:

• Catalog and search scale using request rate, CPU, and latency.
• Order workers scale using queue length and event-processing delay.
• Minimum replicas handle normal demand, while maximum limits protect cost and downstream systems.
• Predictive scaling can add capacity before known sales events.

Data management:

• Each service owns its database.
• Catalog data may use a document store, carts may use a low-latency key-value store, and orders may use a transactional database.
• A Saga coordinates order creation, payment, and inventory reservation.
• An outbox pattern reliably publishes events after local data changes.
• Idempotency keys prevent duplicate orders or payments.

Serverless components:

• Functions can resize product images, process uploads, send notifications, or execute scheduled cleanup tasks.
• Event queues absorb traffic bursts and decouple producers from consumers.

Operations and security:

• CI/CD pipelines deploy immutable artifacts with rolling or canary strategies.
• Centralized logs, metrics, traces, and business indicators support observability.
• Least-privilege identities, encryption, secret management, backups, and audit logs protect the system.

This architecture combines independent scaling, resilience, loose coupling, and managed event processing while acknowledging the need for strong observability and data-consistency controls.