Unit 2: Evolution of Cloud Microservices - Subjective Questions

A monolithic application architecture organizes all application functionality as a single deployable unit. User-interface logic, business logic, and data-access logic are usually developed and packaged together.

Major characteristics:

• Single codebase: Most application modules are maintained in one repository or tightly integrated project.
• Single deployment unit: The entire application is built, tested, and deployed as one package.
• Shared runtime: Modules generally execute within the same process.
• Shared database: Different business modules commonly access the same database schema.
• Direct in-process communication: Modules communicate through method or function calls.
• Centralized scaling: The whole application is replicated even if only one feature requires additional capacity.

A typical monolith may contain presentation, business, and persistence layers. This structure is simple for small applications, but it can become difficult to change, scale, and deploy as the system grows.

Advantages of a monolithic architecture:

• It is comparatively easy to design and develop during the early stages of a project.
• Local method calls make communication between modules fast and simple.
• Testing is straightforward when the entire application can be started as one unit.
• Deployment requires managing only one application package.
• Transactions across multiple modules are easier when they share one database.
• Monitoring and debugging can initially be simpler because execution occurs in one process.

Limitations:

• A small change may require rebuilding and redeploying the complete application.
• Individual modules cannot normally be scaled independently.
• Tight coupling increases as the codebase grows.
• A failure in one module can affect the entire application.
• Large codebases slow down development, testing, and startup.
• Introducing a new technology is difficult because the entire application is built around a common technology stack.
• Multiple teams may face coordination and release conflicts.

Thus, monoliths are useful for small or stable applications but may restrict agility and scalability in large systems.

A distributed application architecture divides an application into multiple components that run on different processes, machines, containers, or geographical locations and communicate through a network.

Essential characteristics:

• Multiple processing nodes: Components execute independently on separate computing resources.
• Network-based communication: Components exchange information through HTTP, RPC, messaging, or event streams.
• Independent failure: One component may fail while others continue operating.
• Concurrency: Several components can process requests simultaneously.
• Independent scalability: Selected components can be replicated according to workload.
• Location transparency: Consumers may not need to know the physical location of a component.
• Partial failures: Network links or individual nodes can fail without a total system failure.
• Distributed data: Data may be stored in multiple databases or locations.

Distributed architectures improve scalability and flexibility, but they introduce challenges such as latency, network failures, data consistency, service discovery, monitoring, and security.

The two architectural styles differ in the following ways:

A monolith is often appropriate for small systems and early product development. Microservices are more suitable when business domains are complex, independent scaling is important, and multiple teams require autonomous delivery. Microservices should not be adopted merely because they are popular; their operational cost must be justified.

The evolution toward cloud microservices was driven by a combination of business and technical factors:

• Growing application complexity: Large monoliths became difficult to understand, test, and modify.
• Need for faster releases: Organizations wanted small teams to release features independently through continuous delivery.
• Elastic cloud infrastructure: Cloud platforms made it possible to provision and scale resources on demand.
• Containerization: Containers provided lightweight, portable, and isolated deployment units for services.
• DevOps adoption: Development and operations teams began sharing responsibility for automated delivery and production reliability.
• Uneven workloads: Different business functions often required different levels of scaling.
• Fault isolation: Organizations wanted failures to remain confined to individual components.
• Technology flexibility: Independent services could select tools and databases appropriate to their responsibilities.
• Business alignment: Services could be organized around business capabilities rather than technical layers.
• Automation and orchestration: Platforms such as container orchestrators simplified deployment, recovery, discovery, and scaling.

Therefore, microservices evolved as a response to the limitations of large monoliths and as an architectural style well suited to cloud automation and rapid business change.

A microservice is a small, independently deployable software service designed around a specific business capability. It runs in its own process and communicates with other services through well-defined network interfaces.

Fundamental principles:

• Single business responsibility: A service focuses on a cohesive business capability.
• Independent deployment: Changes to one service should not require redeploying unrelated services.
• Loose coupling: A service hides its internal implementation and exposes only a stable contract.
• High cohesion: Closely related business rules and data are kept within the same service.
• Decentralized data ownership: Each service controls the data required for its capability.
• Autonomy: Teams can develop, test, deploy, and operate their services independently.
• Failure isolation: Services are designed so that one failure does not automatically stop the complete system.
• Automation: Continuous integration, automated testing, deployment, and infrastructure provisioning are essential.
• Observability: Logs, metrics, and traces are collected to understand distributed execution.

The term "micro" refers primarily to a focused scope and manageable responsibility, not to a fixed number of source-code lines.

A well-designed microservice normally has the following characteristics:

• Business-oriented: It represents a meaningful business capability such as payment, inventory, or shipment.
• High cohesion: Its operations and data contribute to a closely related purpose.
• Loose coupling: Internal changes have minimal effect on consumers and other services.
• Autonomous ownership: A team owns the service from development through production operation.
• Independent deployability: It can be released without coordinating a complete system deployment.
• Private data ownership: Other services do not directly modify its database.
• Explicit API or event contract: Communication occurs through documented and versioned interfaces.
• Resilience: It applies timeouts, retries, circuit breakers, and graceful degradation where appropriate.
• Observability: It produces structured logs, operational metrics, health information, and distributed traces.
• Security: Authentication, authorization, input validation, and secure communication are included by design.
• Automated lifecycle: Builds, tests, deployments, scaling, and recovery are highly automated.

Service size alone does not determine quality. A very small service with excessive dependencies may be less maintainable than a slightly larger but cohesive service.

Major benefits:

• Services can be deployed and scaled independently.
• Small, focused codebases are easier for individual teams to understand.
• Teams can release features faster and choose appropriate technologies.
• Failures can be isolated through resilient design.
• The architecture aligns technical ownership with business capabilities.
• Individual services can be replaced or modernized gradually.

Major challenges:

• Network communication introduces latency and partial failures.
• Distributed data makes cross-service transactions and consistency difficult.
• Testing complete business workflows is more complex.
• Operations require service discovery, centralized logging, metrics, tracing, and alerting.
• API changes must be carefully versioned and coordinated.
• A large number of services increases deployment and configuration complexity.
• Security must be enforced across many network endpoints.
• Poor decomposition can create a distributed monolith, where services must still change and deploy together.

Microservices provide significant agility only when supported by mature DevOps practices, automation, observability, and clear service ownership.

A cloud microservices architecture commonly contains the following building blocks:

• Client applications: Web, mobile, desktop, or external systems that initiate requests.
• API gateway: Provides a unified entry point and routes requests to services.
• Microservices: Independently deployed services implementing business capabilities.
• Service registry and discovery: Maintains service-instance locations and helps components locate them.
• Load balancer: Distributes requests among healthy service instances.
• Databases: Services usually own separate schemas or databases.
• Message broker or event platform: Supports asynchronous communication and event-driven workflows.
• Container and orchestration platform: Automates deployment, scaling, networking, and recovery.
• Configuration and secret management: Supplies environment-specific settings and protected credentials.
• Observability platform: Collects logs, metrics, traces, and alerts.
• Identity provider: Performs user or service authentication and supplies identity tokens.

Typical request flow:

1. A client sends a request to the API gateway.
2. The gateway authenticates the request and applies policies such as rate limiting.
3. It discovers and selects a healthy instance of the required service.
4. The service executes business logic and accesses its own data store.
5. It may synchronously call another service or publish an event.
6. The result returns through the gateway to the client.
7. Logs, metrics, and traces are recorded throughout the workflow.

These components collectively provide routing, scalability, resilience, security, data management, and operational visibility.

Synchronous communication requires the requester to wait for an immediate response. Common mechanisms include HTTP/REST and gRPC.

• It is easy to understand and is suitable for request-response interactions.
• It is useful when the client needs an immediate result, such as checking product availability.
• It creates temporal coupling because both services must be available at the same time.
• Long call chains can increase latency and cause cascading failures.

Asynchronous communication allows a producer to send a message or publish an event without waiting for immediate processing. Message queues and event-streaming platforms are commonly used.

• It reduces temporal coupling between services.
• It supports buffering, retries, load smoothing, and event-driven processing.
• It is suitable for notifications, audit processing, order fulfillment, and background tasks.
• It introduces eventual consistency and requires duplicate-message handling, monitoring, and failure recovery.

A system often uses both styles. Synchronous communication is appropriate for immediate queries or commands, while asynchronous communication is preferable for long-running workflows and integration events.

The database-per-service principle states that each microservice owns its data and exposes that data through an API or events. Other services must not directly read or modify its private database tables.

Benefits:

• Services remain loosely coupled to internal schemas.
• Database changes can be made independently.
• Each service can select a suitable database technology.
• Data ownership and business-rule enforcement are clear.
• Services can scale their storage independently.

Consistency challenges:

A single ACID transaction normally cannot safely update databases owned by several services. Microservices therefore often use eventual consistency, under which all services become consistent after events have been processed.

Common techniques:

• Saga pattern: A business transaction is divided into local transactions with compensating actions for failures.
• Transactional outbox: A service stores a business update and an outgoing event in one local transaction; a separate process publishes the event.
• Idempotent consumers: Reprocessing the same message does not produce unwanted duplicate effects.
• Event sourcing: State is represented as a sequence of domain events in suitable systems.
• CQRS: Read and write models are separated when their requirements differ.

The principle improves autonomy but requires careful management of events, failures, duplicate messages, and temporary inconsistency.

Microservices operate over unreliable networks, so resilience must be designed explicitly.

Important resilience patterns include:

• Timeout: Stops waiting for a response after a defined period and releases resources.
• Retry: Repeats a failed operation when the failure is likely to be temporary. Exponential backoff and random jitter help prevent retry storms.
• Circuit breaker: Stops calls to a repeatedly failing service and later tests whether it has recovered.
• Bulkhead: Separates resource pools so that failure or overload in one area does not consume all resources.
• Fallback: Returns cached, default, or reduced information when a dependency is unavailable.
• Load balancing: Spreads traffic across healthy instances.
• Health checks: Allow orchestration platforms to detect and replace unhealthy instances.
• Rate limiting: Protects services from excessive traffic.
• Queue-based load leveling: Buffers work so consumers can process it at a sustainable rate.
• Idempotency: Ensures retries do not create duplicate business effects.

These patterns should be combined with monitoring and alerting. Uncontrolled retries or poorly configured timeouts can worsen an outage rather than improve resilience.

Domain-Driven Design (DDD) is an approach to software development that models software around a complex business domain. It encourages close collaboration between domain experts and software developers.

Core principles:

• Domain focus: Design begins with business concepts and rules rather than databases or frameworks.
• Ubiquitous language: Domain experts and developers use a shared, precise vocabulary in conversations, models, APIs, and code.
• Domain model: Software represents important business concepts, behaviors, and relationships.
• Bounded context: A model is valid within an explicit boundary; the same term may have different meanings in different contexts.
• Context mapping: Relationships between bounded contexts are identified and managed.
• Aggregates: Related entities and value objects are grouped under a consistency boundary.
• Domain events: Important business occurrences are represented explicitly.
• Continuous model refinement: The model evolves as the team gains domain knowledge.

In microservices, DDD helps discover cohesive business capabilities and define meaningful service boundaries. A bounded context is often a strong candidate for a microservice, although the relationship does not have to be one-to-one.

A bounded context is an explicit boundary within which a particular domain model, vocabulary, and set of business rules are valid and internally consistent.

For example, the term customer may mean a buyer with delivery preferences in an ordering context, but it may mean an account with credit status in a billing context. Keeping these models separate prevents one oversized and ambiguous enterprise model.

Importance for microservices:

• It groups closely related business concepts and rules.
• It establishes clear ownership of terminology, logic, and data.
• It reduces coupling between different domain models.
• It allows models to evolve independently.
• It provides a candidate boundary for service and team ownership.
• It makes integration points explicit through APIs or domain events.

A bounded context should not be divided solely according to database tables or technical layers. It should represent a cohesive business capability. One bounded context may be implemented by one or several services, depending on its complexity, workload, and operational needs.

Entity: An object defined by identity and continuity rather than only by its attributes. For example, an order with identifier Order-105 remains the same order even if its status changes.

Value object: An immutable object defined by its values and without a separate identity. Examples include an address, date range, or money value such as USD 100.

Aggregate: A cluster of related entities and value objects treated as one consistency and transactional boundary. For example, an Order aggregate may contain order-line entities and shipping-address values.

Aggregate root: The main entity through which external code accesses and modifies an aggregate. If Order is the aggregate root, order lines should be modified through methods of the order rather than updated independently.

Domain event: A record of a business occurrence that domain participants care about, such as OrderPlaced, PaymentAuthorized, or ShipmentDispatched.

These concepts protect business invariants. An aggregate should generally be modified in one local transaction, while domain events communicate completed business changes to other aggregates or services.

Strategic DDD decomposes a system by identifying business domains, subdomains, bounded contexts, and relationships between them.

A possible decomposition process is:

1. Study the business domain: Collaborate with experts to understand ordering, payment, inventory, shipping, and customer support.
2. Establish ubiquitous language: Define terms such as product, stock reservation, order, authorization, and shipment.
3. Identify subdomains:
   • Core: Capabilities that provide competitive advantage, such as recommendation or fulfillment optimization.
   • Supporting: Necessary custom capabilities, such as catalog administration.
   • Generic: Common capabilities, such as identity or email delivery.
4. Define bounded contexts: Possible contexts include Catalog, Shopping Cart, Ordering, Inventory, Payment, Shipping, and Customer Support.
5. Assign ownership: Each context owns its model, business rules, and data.
6. Define integration contracts: Contexts communicate through APIs and events such as OrderPlaced, StockReserved, and PaymentAuthorized.
7. Create a context map: Document upstream and downstream dependencies and translation requirements.
8. Evaluate operational factors: Separate services further only when scalability, security, release cadence, or team ownership justifies it.

For example, the Ordering service should not directly update Inventory tables. It can request a reservation or publish an event. This preserves boundaries and autonomy. DDD therefore produces services based on business meaning rather than arbitrary technical layers.

Effective service boundaries should balance business cohesion with operational independence.

Important factors include:

• Business capability: A service should represent a recognizable business responsibility.
• Bounded context: Concepts and rules belonging to one domain model should remain together.
• High cohesion: Operations that frequently change together should normally be placed together.
• Loose coupling: Services should minimize knowledge of one another's internal data and implementation.
• Data ownership: A service should own the data required to enforce its business rules.
• Consistency requirements: Data that must be updated atomically may belong in the same aggregate or service.
• Change frequency: Features that evolve together should avoid unnecessary separation.
• Team ownership: A service should be manageable by a clearly accountable team.
• Scalability: Workloads with substantially different scaling needs may justify separate services.
• Security and compliance: Sensitive capabilities may require stronger isolation.
• Performance: Excessive remote calls indicate that a boundary may be too fine-grained.
• Independent deployability: A boundary is useful only if the service can evolve and deploy with limited coordination.

Service boundaries should be reviewed as domain knowledge improves. Prematurely creating many tiny services often increases complexity without providing meaningful autonomy.

Symptoms of poor service boundaries:

• Several services must be changed and deployed together for one feature.
• A single request causes many small, sequential network calls.
• Services directly access one another's database tables.
• Business logic is duplicated across services.
• Ownership of data or rules is unclear.
• Cross-service distributed transactions are frequent.
• Teams cannot work independently because of constant coordination.
• Services are separated by technical layers, such as user-interface, logic, and database services, rather than business capabilities.

Consequences:

• Increased latency and cascading failures
• Fragile API dependencies
• Difficult testing and deployment
• Inconsistent business rules
• Reduced team autonomy
• A distributed monolith that has the disadvantages of both monoliths and distributed systems

Improvements:

• Revisit bounded contexts with domain experts.
• Place concepts that change together in the same service.
• Assign one clear owner to each business rule and data set.
• Merge overly chatty or inseparable services.
• Split oversized services around cohesive business capabilities.
• Replace internal data sharing with explicit APIs or domain events.
• Use asynchronous communication where immediate coordination is unnecessary.
• Continuously evaluate boundaries using dependency, performance, and deployment data.

An API gateway is a server or managed cloud component that acts as a common entry point for client requests to backend microservices. It hides the internal service topology and applies cross-cutting policies.

Major responsibilities:

• Request routing: Directs requests to the correct service or service version.
• Authentication and authorization: Validates identity tokens and access permissions.
• Load balancing: Distributes requests across healthy service instances.
• Protocol translation: Converts between external and internal protocols or message formats.
• Request aggregation: Calls multiple services and combines their responses.
• Rate limiting and throttling: Protects services from abuse or overload.
• Caching: Reduces repeated backend processing for suitable responses.
• TLS termination: Manages secure client connections.
• Observability: Records access logs, latency, errors, and tracing information.
• API transformation: Adds, removes, or transforms headers and payload fields when necessary.

The gateway simplifies clients because they do not need to discover every service. However, business logic should generally remain in domain services so that the gateway does not become a complex new monolith.

Benefits of an API gateway:

• Provides clients with one stable endpoint.
• Hides internal service addresses and topology.
• Centralizes authentication, throttling, routing, and other cross-cutting policies.
• Reduces client-side complexity through response aggregation.
• Supports API versioning, monitoring, and controlled exposure of services.

Limitations and risks:

• It can become a performance bottleneck if it is not scaled properly.
• A gateway failure can block access to many services.
• Excessive business logic can turn it into a tightly coupled gateway monolith.
• Additional processing introduces latency.
• Central ownership can reduce team autonomy and slow releases.
• Configuration errors can affect many APIs simultaneously.

Design considerations:

• Deploy multiple gateway instances and use health checks for high availability.
• Keep the gateway stateless where possible.
• Apply short timeouts, controlled retries, circuit breakers, and request-size limits.
• Securely validate tokens and forward only necessary identity information.
• Monitor request rates, error rates, latency, and backend dependency failures.
• Use separate gateways or the Backend for Frontend pattern when web, mobile, and partner clients have substantially different needs.
• Keep domain decisions inside microservices rather than gateway policies.

API gateway versus load balancer:

A load balancer primarily distributes traffic among multiple instances of the same application or service. An API gateway operates at the API level and can route to different services, authenticate requests, aggregate responses, transform protocols, and enforce usage policies. A gateway may internally use load balancing, but the two components have different primary responsibilities.