Unit 4: Economic Benefits of Microservices - Subjective Questions

Scalability is the ability of a system to increase or decrease its computing resources according to changes in workload.

In a microservices architecture, each service can be scaled independently. Its economic benefits include:

• Selective scaling: Only heavily used services require additional resources.
• Reduced overprovisioning: Organizations do not need to provision an entire application for peak demand.
• Pay-as-you-go usage: Costs are based on the resources actually consumed.
• Improved utilization: Compute capacity can be allocated more efficiently.
• Demand responsiveness: Automatic scaling can add resources during traffic spikes and remove them when demand falls.

Thus, independent scaling aligns infrastructure expenditure more closely with business activity.

Vertical scaling increases the capacity of an existing server by adding CPU, memory, or storage. Horizontal scaling increases capacity by adding more service instances or servers.

Horizontal scaling is usually more suitable for microservices because services can run as multiple independent instances behind a load balancer. However, vertical scaling may still be appropriate for databases or workloads that cannot easily be distributed.

In a monolithic application, all functional modules are deployed as one unit. If one module becomes overloaded, the complete application must usually be replicated, including modules that do not need more capacity.

Microservices reduce this inefficiency through:

• Fine-grained resource allocation: CPU-intensive, memory-intensive, and low-demand services can use different instance types.
• Independent replica counts: Only the overloaded service receives additional replicas.
• Separate scaling policies: Each service can scale using metrics relevant to its workload.
• Targeted optimization: Frequently used services can be optimized without redesigning the entire application.
• Faster scale-in: Unnecessary replicas can be removed after demand falls.

For example, if only a catalog service needs four times its normal capacity, a microservices system can scale that service alone. A monolith may require four times the resources for every application component, producing avoidable cost.

Major AWS compute pricing models include:

• On-Demand Instances: Capacity is paid for without a long-term commitment. It is suitable for unpredictable workloads, development environments, and short-lived applications.
• Savings Plans: Customers commit to a consistent amount of compute usage for one or three years in exchange for discounted pricing. They suit predictable baseline workloads.
• Reserved Instances: Customers receive discounts by committing to particular instance usage conditions. They are useful for stable, long-running workloads.
• Spot Instances: Spare EC2 capacity is offered at a large discount but may be interrupted. It is appropriate for fault-tolerant batch processing, testing, and distributed jobs.
• Dedicated Hosts or Instances: Physical capacity is dedicated to one customer. It supports licensing, compliance, or isolation requirements but usually costs more.

A cost-effective architecture often combines discounted capacity for baseline demand, On-Demand capacity for variable demand, and Spot capacity for interruptible tasks.

Azure provides several compute pricing options:

• Pay-as-you-go: Resources are billed according to usage without an advance commitment. This works well for uncertain or temporary microservices workloads.
• Azure Reservations: Customers reserve eligible resources for one or three years to obtain discounts on predictable workloads.
• Azure Savings Plan for Compute: A commitment to a fixed hourly spend provides flexibility across eligible compute services.
• Azure Spot Virtual Machines: Unused capacity is available at lower prices but can be evicted. It is suitable for resilient workers and batch services.
• Azure Hybrid Benefit: Existing eligible Windows Server or SQL Server licenses can reduce cloud costs.
• Serverless consumption pricing: Services such as Azure Functions can charge according to executions, execution duration, and allocated resources.

An organization may reserve capacity for stable services, use pay-as-you-go instances for traffic bursts, and run retryable background services on Spot Virtual Machines.

Google Cloud offers the following important pricing options:

• On-demand pricing: Compute resources are billed according to actual usage without a long-term commitment.
• Sustained use discounts: Eligible resources may receive automatic discounts when they run for a significant portion of a billing month.
• Committed use discounts: Customers commit to a specified resource usage or spend level for a defined term in return for reduced prices.
• Spot VMs: Spare capacity is offered at a lower price and may be preempted. It is useful for fault-tolerant or restartable services.
• Custom machine types: CPU and memory can be selected more precisely, reducing waste caused by oversized predefined instances.
• Serverless pricing: Cloud Run and Cloud Functions can charge based on allocated resources, requests, and execution time, depending on configuration.

These options allow stable microservices to use commitments while variable or event-driven services use elastic and serverless pricing.

AWS, Azure, and Google Cloud all provide usage-based pricing, long-term commitment discounts, spare-capacity pricing, and serverless services. Their terminology and discount mechanisms differ.

A valid comparison must consider more than the advertised compute rate. Region, operating system, support, storage, network transfer, managed-service fees, discounts, and workload behavior all affect total cost. The cheapest provider therefore depends on the application's complete usage profile.

The compute cost of a microservice is influenced by:

• Instance or container size: More virtual CPUs, memory, or accelerators increase the rate.
• Execution duration: Long-running instances accumulate more billable hours or seconds.
• Number of replicas: Horizontal scaling increases total resource consumption.
• Region and availability zone: Prices can differ by location.
• Operating system and software licenses: Commercial software may add licensing charges.
• Pricing commitment: On-demand, reserved, committed, and spot capacity have different rates and conditions.
• Utilization: Idle or oversized instances waste paid capacity.
• Orchestration overhead: Kubernetes control planes, system pods, and reserved node capacity can add cost.
• Serverless request characteristics: Invocation count, execution time, memory, CPU, and provisioned concurrency may all be billable.

A simplified estimate is:

where is the average number of instances, is the price per instance per time unit, and is the billable duration.

The original monthly compute cost is:

Therefore, the original cost is $216 per month.

A 25% reduction gives the optimized average instance count:

The optimized monthly cost is:

The monthly savings are:

The percentage saving is:

Hence, autoscaling reduces the monthly compute cost from $216 to $162, resulting in a saving of $54 per month.

Cloud storage cost can include several components:

• Stored data volume: Charges are commonly based on gigabytes stored per month.
• Storage class: Hot, cool, cold, archive, and high-performance tiers have different rates.
• Operations: Reads, writes, listings, and API requests may be charged separately.
• Performance: Provisioned input/output operations, throughput, and high-speed disks can increase cost.
• Replication: Multi-zone or multi-region replication stores additional copies.
• Retrieval: Cold and archive tiers may impose data retrieval charges.
• Minimum retention: Early deletion from archival tiers can incur fees.
• Snapshots and backups: Retained snapshots consume storage and may create transfer charges.

Microservices often create separate databases, logs, caches, and backups. This improves service independence but may duplicate data and increase storage operations. Lifecycle policies, compression, retention limits, and appropriate storage classes help control these costs.

Object storage is generally suitable for large quantities of unstructured data. Block storage is preferred when low-latency disk access is required. File storage is valuable when multiple services need conventional shared-file access. The lowest per-gigabyte option is not always the lowest total-cost option because access frequency, performance, request volume, and transfer must also be considered.

Network and data transfer charges commonly arise from:

• Internet egress: Data sent from a cloud region to users or external systems is often charged.
• Internet ingress: Incoming data is commonly free, although related services may still incur charges.
• Cross-region transfer: Communication between services in different regions is usually billed.
• Cross-zone transfer: Traffic between availability zones may attract charges, depending on the provider and service.
• Inter-cloud transfer: Moving data between cloud providers usually incurs egress charges from the source provider.
• Content delivery network traffic: CDN delivery, requests, invalidations, and origin retrieval can be billable.
• Load balancers and gateways: Charges may depend on operating time, processed bytes, connections, or requests.
• Private connectivity: Dedicated links, private endpoints, and transit services may have hourly and data-processing fees.

Because microservices communicate frequently, a highly distributed design can generate substantial internal traffic. Service placement and communication patterns are therefore important cost decisions.

First, convert the total transfer to gigabytes:

Subtract the free allowance:

Calculate the transfer charge:

Therefore, the monthly data transfer charge is $237.76.

This example demonstrates why a free tier should be subtracted before applying the billable rate. In a real cloud invoice, tiered pricing, destination, region, CDN usage, and provider-specific definitions may alter the calculation.

Microservices can increase network cost because operations that previously occurred within one application process become remote calls. Cost can grow through synchronous call chains, repeated API requests, large payloads, cross-zone communication, and cross-region replication.

Cost-reduction methods include:

• Co-locating related services: Place frequently communicating services in the same region or zone when resilience requirements permit.
• Reducing chatty interfaces: Replace many small calls with appropriately designed coarse-grained operations.
• Caching: Store frequently requested data closer to consumers.
• Compression: Compress suitable payloads before transfer.
• Asynchronous messaging: Decouple non-immediate operations and batch messages where appropriate.
• Payload control: Return only required fields and avoid unnecessary duplication.
• CDN usage: Serve static and cacheable content near users.
• Traffic monitoring: Identify expensive service-to-service routes using metrics and traces.

Optimization must preserve reliability and latency requirements; eliminating cross-zone traffic may reduce cost but can weaken fault tolerance.

AWS provides several tools for cloud financial management:

• AWS Cost Explorer: Visualizes historical cost and usage, supports filtering, and provides forecasts.
• AWS Budgets: Defines cost or usage limits and sends alerts when actual or forecast values exceed thresholds.
• AWS Cost and Usage Report: Supplies detailed billing data for analysis and allocation.
• AWS Cost Anomaly Detection: Uses automated analysis to identify unusual spending patterns.
• AWS Compute Optimizer: Recommends resource sizes based on utilization data.
• AWS Trusted Advisor: Identifies selected opportunities related to cost, performance, security, reliability, and service limits.
• Tags and cost allocation categories: Attribute spending to services, teams, projects, or environments.

Together, these tools support budgeting, anomaly detection, rightsizing, forecasting, and accountability for microservices spending.

Important Azure cost management tools include:

• Microsoft Cost Management: Analyzes cost, filters spending by dimensions, exports data, and supports cost allocation.
• Azure Budgets: Defines spending thresholds and generates notifications or triggers actions.
• Azure Advisor: Recommends rightsizing, removal of idle resources, and the use of reservations or savings plans where appropriate.
• Azure Monitor: Provides metrics and logs that help relate resource utilization to cost.
• Pricing Calculator: Estimates the cost of a proposed Azure architecture before deployment.
• Total Cost of Ownership Calculator: Compares estimated on-premises expenditure with Azure expenditure.
• Tags and management groups: Organize costs by application, department, environment, or owner.

These tools enable teams to detect overspending, forecast expenditure, identify underutilized services, and establish financial accountability.

Google Cloud provides the following cost-management capabilities:

• Cloud Billing reports: Display cost trends and allow filtering by project, service, SKU, region, and labels.
• Cost table and billing export: Provide detailed cost data, including export to BigQuery for custom analysis.
• Budgets and alerts: Notify stakeholders when actual or forecast expenditure reaches configured thresholds.
• Recommender: Suggests actions such as rightsizing virtual machines and removing idle resources.
• FinOps Hub: Centralizes selected cost optimization opportunities and financial-management insights.
• Pricing Calculator: Estimates the expected cost of planned resources.
• Labels, projects, and folders: Support cost attribution across teams, environments, and applications.

These tools help organizations understand spending, detect waste, evaluate recommendations, and allocate microservices costs to responsible owners.

A comprehensive strategy should include the following steps:

1. Establish ownership: Assign every service to a team and require standard cost-allocation tags or labels.
2. Create a baseline: Record current compute, storage, database, observability, and network expenditure.
3. Define budgets: Set budgets for applications, teams, environments, and cloud accounts or projects.
4. Configure alerts: Notify owners about forecast overruns and unusual spending.
5. Measure unit economics: Track indicators such as cost per request, customer, order, or transaction.
6. Rightsize resources: Compare requested capacity with actual CPU, memory, storage, and throughput utilization.
7. Apply elasticity: Configure scale-out and scale-in rules, minimum replica counts, and scheduled scaling.
8. Use pricing commitments carefully: Cover predictable baseline demand with reservations or commitments while retaining flexible capacity for bursts.
9. Optimize data: Apply retention, lifecycle, compression, caching, and deletion policies.
10. Review network topology: Identify cross-zone, cross-region, and internet egress hotspots.
11. Automate governance: Detect untagged, idle, oversized, and abandoned resources.
12. Review continuously: Hold regular engineering and finance reviews to verify savings without degrading service objectives.

This strategy combines technical telemetry with financial data and creates accountability at the individual-service level.

Rightsizing is the process of selecting a resource type and capacity that closely matches a workload's actual CPU, memory, storage, and input/output requirements. Autoscaling dynamically changes the number or capacity of resources as workload demand changes.

Key differences are:

• Rightsizing answers what size each resource should be.
• Autoscaling answers how many resources should run at a particular time.
• Rightsizing is commonly based on historical utilization analysis.
• Autoscaling responds to metrics, schedules, queues, or predictive policies.

For example, reducing a service instance from 8 virtual CPUs to 4 virtual CPUs is rightsizing. Increasing replicas from 3 to 10 during peak demand is autoscaling.

They work best together: rightsizing prevents each replica from being unnecessarily expensive, while autoscaling prevents an unnecessary number of replicas from running.

A simplified monthly total cost model can be expressed as:

The main components may be estimated as:

where:

• is the number of compute resources of type .
• is the compute rate and is usage duration.
• is stored volume and is the storage rate.
• represents storage operation or retrieval charges.
• is the number of billable requests and is the price per request unit.
• is transferred data and is the applicable transfer rate.
• includes databases, load balancers, gateways, and observability services.
• includes support plans and related organizational costs.

To compare providers, the same workload assumptions, region, availability target, traffic pattern, retention period, and support level must be applied to each provider. Free tiers, tiered rates, commitments, and expected growth should also be included. This produces a more reliable comparison than evaluating compute prices alone.