Designing and Building Cloud-Native Solutions

Executive Summary

Business context — Contoso: Contoso operates a customer-facing service portal whose web tier, business processes, and batch jobs share a tightly coupled VM-based release process. Peak traffic stresses the application tier; maintenance affects availability; and fragmented logs make it difficult to trace errors across dependencies.

Organizations modernizing applications often need to improve release speed, resilience, and the ability to scale without making every team responsible for operating a bespoke platform. Simply moving existing servers into cloud virtual machines can preserve the same deployment bottlenecks and operational overhead.

This Contoso architecture case study documents how Tongtech shapes an Azure application platform around workload needs. The design uses managed services where they fit, containers where portability or runtime control matters, event-driven components for asynchronous work, and shared engineering practices for security, delivery, and operations.

The objective is a supportable application architecture in which teams can release independently while platform controls, identity, networking, and observability are built into the delivery path.

Client confidentiality: Contoso is the client alias used in this technical case study. Resource names, address spaces, workload volumes, and configuration examples are reference design parameters, not disclosed customer records. The design does not establish that a customer deployment occurred or that quantitative results were measured.

The Challenge

Contoso’s application portfolio presents the following engineering and operational constraints:

• Components are tightly coupled, so small changes require coordinated releases.
• Capacity is planned and scaled manually, leaving resources idle or workloads under pressure.
• Virtual machine operations take time away from application improvements.
• Long release cycles make it difficult to deliver changes safely and frequently.
• Synchronous dependencies cause one slow or unavailable service to affect others.
• Logs and metrics are spread across components, making failures difficult to trace.
• Public endpoints and application secrets are managed inconsistently.
• Development, test, and production environments behave differently.
• Teams lack a clear path to choose between containers, serverless, and managed application services.

Contoso needs a practical modernization path that improves delivery and reliability without introducing distributed-systems complexity where it is not justified.

Objectives

The target solution is designed to:

1. Match each application component to an Azure hosting option based on its runtime and operating needs.
2. Separate independently changing capabilities behind stable API or messaging contracts.
3. Use managed identity and private connectivity to reduce credential exposure and public network dependencies.
4. Standardize build, test, deployment, and promotion practices across environments.
5. Make application health, dependencies, and service objectives observable.
6. Scale application capacity in response to demand while preserving clear cost ownership.
7. Provide operational ownership, recovery guidance, and a path for future change.

Cloud-Native Architecture

The architecture is selected per workload rather than prescribing a single compute platform for every application.

Choosing the Application Platform

The selection accounts for runtime requirements, scale profile, networking, availability, team experience, operational ownership, and total cost. AKS is not the default for every container: a managed container or application service can reduce platform work when cluster-specific capabilities are not required.

Request and Event Flows

A typical solution may use Azure Front Door or Application Gateway for controlled ingress, Azure API Management for API policies and lifecycle controls, and application services or container workloads for business capabilities. Azure Service Bus supports durable commands and work queues; Event Grid distributes notifications when multiple consumers need to react to events.

Managed data services are selected around the application’s consistency, availability, and data-access needs. Caching is added only where measured access patterns justify it. Components communicate through explicit APIs or versioned event contracts so that asynchronous processing does not silently become a new source of coupling.

Data and Configuration

Each service receives only the configuration it needs. Azure Key Vault stores secrets that cannot be eliminated, while managed identities provide access to Azure resources without embedding credentials in application settings or pipeline variables. Environment-specific configuration is kept outside the application image and promoted through controlled deployment workflows.

Security Architecture

Security controls are part of the application and platform design:

• Microsoft Entra ID authenticates users and workloads where supported.
• Managed identities and narrowly scoped RBAC replace static credentials for Azure resource access.
• Private Endpoints and private DNS are used for supported data and platform services when private access is required.
• Ingress is restricted through an application gateway or edge service with WAF and API policies selected for the exposure model.
• Key Vault access, certificate lifecycle, and secret rotation have named operational ownership.
• Container images and dependencies are scanned in the build workflow, and deployment permissions are separated by environment.
• Network and application boundaries are reviewed together so that a private service remains reachable through an intentional path.

Controls are applied at the layer that can enforce them reliably, with platform guardrails complemented by application-level authorization and input validation.

Platform Engineering and Delivery

Infrastructure is defined with Terraform or Bicep and composed from reviewed environment patterns. Shared modules cover platform concerns such as networking, identity, diagnostics, container registry, and managed services without obscuring workload-specific settings.

Application delivery follows a repeatable path:

Pipelines use federated identity where supported, and production permissions are scoped to the deployment boundary. Release strategies such as deployment slots, rolling updates, or canary traffic are chosen according to the hosting platform and the application’s ability to tolerate version overlap. Database and message-contract changes are sequenced so that rollback remains practical.

GitOps can be used for Kubernetes workloads when declarative reconciliation improves auditability and operations. It is introduced with clear ownership of cluster configuration, secrets, promotion, and emergency changes.

Reliability and Observability

Reliability is designed and operated at both the component and end-to-end level. Health probes distinguish a process that is running from a service that is ready to receive traffic. Autoscaling limits and queue depth are considered alongside downstream service capacity so scaling one component does not overload another.

Azure Monitor, Application Insights, and Log Analytics provide a shared foundation for metrics, logs, traces, and platform diagnostics. Distributed tracing and consistent correlation identifiers connect a user request across APIs, workers, and dependencies. Teams define service indicators and objectives for critical user journeys, then configure actionable alerts with runbooks and ownership.

Resilience measures can include bounded retries with backoff, timeouts, idempotent message handling, dead-letter queues, graceful degradation, and tested recovery procedures. Availability zones, backups, regional recovery, and failover targets are selected according to business impact and validated through exercises rather than assumed from service configuration alone.

Implementation Sequence

1. Discovery and Workload Assessment

Review application boundaries, runtime and data dependencies, current release process, traffic patterns, security requirements, recovery needs, and team operating skills. Identify constraints that affect platform choice, such as persistent state, specialized networking, or compatibility with managed runtimes.

2. Target Architecture and Modernization Plan

Define the service boundaries, synchronous and asynchronous interfaces, hosting options, identity model, network paths, data services, observability approach, and deployment ownership. Prioritize changes by risk and value instead of requiring a full rewrite before the first improvement.

3. Secure Platform Foundation

Provision the required subscriptions or workload environment, network integration, identity, registry, secrets, policy, monitoring, and infrastructure pipelines through IaC. Establish developer and operator access before onboarding production workloads.

4. Pilot and Delivery Patterns

Move a bounded service or user journey onto the target platform. Validate the build and release path, access controls, telemetry, scaling behavior, and recovery process. Refine reusable templates based on the pilot before broad adoption.

5. Incremental Workload Migration

Modernize and release components in manageable increments. Use API or messaging contracts to support coexistence with remaining legacy components, and track data migration and rollback dependencies explicitly.

6. Operational Handover and Improvement

Transfer architecture records, source code, IaC, dashboards, alerts, runbooks, ownership, and backlog. Review operational signals and delivery feedback to prioritize the next platform or application changes.

Production Architecture and Low-Level Design

1. Workload Decomposition and Nonfunctional Requirements

The modernization boundary is the customer portal and its order-processing workflow, not the entire enterprise estate. The platform team owns network ingress, baseline security, application hosting, deployment templates and shared observability. The application team owns business APIs, message schemas, database migrations, retry behavior, and service-level indicators. Operational acceptance requires ownership at each boundary.

The design does not adopt AKS by default. If Contoso later requires Kubernetes-native workload controls or has a staffed cluster operations team, a separate AKS architecture decision should justify networking, upgrades, autoscaling, policy, and cluster operating cost. Azure Container Apps is another deployment option for containerized APIs/workers when its networking and scaling model fits; it is not assumed to be a drop-in replacement for an internal App Service architecture.

Architecture sizing is confirmed from load profiles rather than unverified throughput figures. Before approving SKU and region choices, collect peak and sustained request rate, concurrency, dependency latency, transaction size, data growth, storage IOPS, availability target, recovery time objective (RTO), recovery point objective (RPO), data residency, and regulatory constraints. Include failure-mode testing; no capacity claim is justified without it.

2. Logical Application and Event Topology

Front Door private origin features and supported App Service combinations must be verified against the selected SKU and region. Alternatively, use Application Gateway with WAF in a workload network for regional ingress. These are decisions, not simultaneous mandatory purchases. Public DNS remains on the authorized edge; application origins and data services are restricted by private access controls or equivalent approved ingress restrictions.

3. Network Segmentation and Name Resolution

The workload integrates with the Contoso landing-zone hub-and-spoke network. These CIDRs are design examples and must be reconciled against the enterprise IP address management system before deployment.

Private endpoint DNS zones are centrally governed and linked/resolved through approved hub DNS forwarding: privatelink.database.windows.net (Azure SQL), privatelink.servicebus.windows.net (Service Bus), privatelink.vaultcore.azure.net (Key Vault), and service-specific zones for any other selected private endpoints. Service FQDNs should resolve to the expected private IP from application-integrated DNS paths, including on-premises clients where necessary. A DNS query alone does not confirm network reachability: verify TCP connection, TLS/SNI and actual authentication.

App Service VNet integration concerns outbound access to the VNet. Making an App Service endpoint private for inbound connections requires a supported private endpoint/ingress configuration; integration alone does not make the app private. Required platform outbound dependencies, Azure service tags, route tables, DNS resolvers, TLS egress, and firewall rules are documented and tested before enforcing default-deny controls.

4. Request, Transaction and Failure Semantics

The user posts an order to the API. The API validates the request, creates a transaction record and uses a durable outbox/event publication approach when atomicity between the database and queue is required. The queue worker acknowledges only after its business operation succeeds according to the chosen SDK and trigger behavior. Service Bus message delivery must be handled as at least once in the general case; consumers enforce idempotency using a stable operation identifier and deduplication safeguards.

The API returns an accepted/pending state rather than blocking on asynchronous fulfillment. A status endpoint supplies the current business state; user-facing behavior specifies what happens during queue delays or worker outages. Retries use bounded exponential backoff, and non-recoverable messages reach a dead-letter queue with a reviewed reprocessing procedure. Queue length, oldest message age, dead-letter count, worker failure rate, and business reconciliation exceptions are monitored; a queue alone is not a guarantee against message loss or duplicates.

5. Identity, Authorization and Secrets

The portal uses Microsoft Entra ID or a separately selected supported customer identity solution depending on the user population. The API validates token issuer, audience, signing keys, authorized scope/role and tenant/customer boundaries; authentication does not substitute for object-level authorization. Workloads use managed identities for supported Azure data-plane access, with role assignments scoped to the necessary Service Bus entities, Key Vault secrets, or databases. Database identity and permission mapping is tested end to end.

Secrets that remain necessary are held in Key Vault and accessed through approved identity and networking paths. Certificates have owners and renewal alerts; app settings are split into nonsecret configuration and Key Vault references where appropriate. Production identities do not share credentials with staging, and developer access is not equivalent to a deployment pipeline role.

6. Database and Migration Strategy

The database remains a deliberate transactional boundary. Migration uses an inventory of schema, stored procedures, background jobs, dependencies, data sensitivity and supported compatibility levels. Database access is restricted through private networking and least privilege. Backup retention, point-in-time restore, long-term retention where required, geo-replication/failover options and RPO/RTO are selected from business requirements and verified by restore tests.

The cutover process uses a staged sequence: schema compatibility deployment → application dual-compatibility period → incremental data sync or migration → read validation/reconciliation → controlled traffic cutover → enhanced monitoring → removal of old routes only after acceptance. For continuous synchronization, use a selected supported tool and prove consistency before use. Destructive schema changes follow expand-and-contract: add new structures, migrate consumers, monitor usage, and only then remove old structures. A web-code rollback cannot reverse destructive database migrations by itself.

7. Release Architecture and Deployment Controls

Each application has a defined build artifact and immutable version. Pipelines perform dependency and secret scans, automated unit/contract tests, IaC validation, security checks, and integration tests in a production-like test environment. Release authority is environment scoped with federated identities and approval controls. Production App Service uses a warmed staging slot and explicit sticky setting configuration; slot swap can provide an application rollback path, subject to backwards-compatible database and contract changes.

Functions and messaging deployments use versioned function packages and safe contract changes. For canary or progressive delivery, route a subset of traffic only where the service/edge supports the chosen mechanism; define a rollback threshold using request failure rate, p95 latency, queue backlog and business-level correctness. No deployment is deemed successful solely because the pipeline job returned zero.

8. Observability, SLOs, and Actionable Alerts

Application Insights instrumentation propagates trace context and correlation identifiers from the entry point into the API, database calls and worker messages. Use a consistent operation/transaction identifier that does not expose personal data in logs. Telemetry is sampled where appropriate without dropping critical business/error signals. Operational dashboards include traffic, 4xx/5xx by origin, p50/p95/p99 request latency, dependency failures, worker exceptions, Service Bus dead letters and queue age, SQL throttling, platform health, and deployment annotations.

An SLO is defined around a user journey, for example successful order acceptance within an agreed latency threshold measured from production telemetry. The actual threshold and error budget require business agreement and baseline measurements; they are not inferred from Azure service SLAs. Alerts must identify an actionable owner, severity, diagnostic dashboard and runbook, with suppression/maintenance handling.

9. Reliability, Scaling, Backup, and Recovery

App Service autoscale decisions are based on CPU, memory, request load and actual downstream capacity. Functions concurrency and scale settings are tuned with SQL connection limits and Service Bus processing guarantees in mind. Timeouts, circuit breaking, request limits, idempotency and rate limiting protect dependencies. Scaling workers without bounding downstream database contention can worsen outages.

The regional availability design considers service SKU support for zone redundancy, failover mechanisms, and the cost of multi-region operation. The recovery plan names service owners, data restore sequence, DNS/edge transition, secrets and identity dependencies, queue replay strategy and business reconciliation. A region-failover design is not validated until traffic, application state and data recovery are exercised against the documented RTO and RPO.

10. Delivery Phases and Change Windows

11. Production Acceptance Tests

Before and After Implementation: Operational Improvements

This table contrasts Contoso's initial operating constraints with the specified target architecture. It is a design comparison, not a set of measured customer outcomes.

Measuring Improvements and Validating Outcomes

Collect comparable 30–90-day baseline and post-cutover periods, controlling for traffic volume, peak seasonality, release scope and significant incidents. Use Azure Monitor and Application Insights for request performance, deployment logs for frequency and failures, incident records for recovery times, Azure Cost Management for spend, and documented restore tests for RTO/RPO. Specify denominators and measurement windows; avoid unsupported claims such as "99.99% achieved," "50% savings," or "zero downtime."

Project Deliverables

A typical engagement can produce:

• current-state assessment and modernization roadmap
• target application and Azure platform architecture
• workload hosting decision records
• API and event integration patterns
• network, identity, and secrets design
• Terraform or Bicep modules and environment configuration
• application build and deployment pipelines
• container registry and image-management approach
• observability dashboards, service indicators, and alert definitions
• reliability, backup, and recovery runbooks
• operational ownership model and knowledge transfer

Expected Architectural Outcomes

The intended result is a cloud-native delivery pattern that gives teams a supported route to deploy and operate modern application components on Azure. Managed services reduce undifferentiated platform work where their capabilities fit, while container orchestration remains available for workloads that need it.

With identity, network controls, automated delivery, and observability included in the platform, teams have a clearer way to release changes and investigate issues. These are intended capabilities of the described target architecture; no project-specific delivery metrics, availability figures, or client outcomes are asserted.

Why This Architecture Works

Workload needs guide the platform choice.

Managed services reduce operational work when they fit.

APIs and events make service boundaries explicit.

Identity and private networking are part of the design.

Automated delivery and observability support safe operation.

The result is an application platform that supports incremental modernization and gives engineering teams a repeatable way to build, release, and operate cloud-native workloads.

Technologies

Microsoft Azure · Azure Kubernetes Service · Azure Container Apps · Azure App Service · Azure Functions · Azure API Management · Azure Service Bus · Azure Event Grid · Azure SQL / managed databases · Azure Key Vault · Microsoft Entra ID · Managed Identity · Private Link · Azure Monitor · Application Insights · Log Analytics · Terraform / Bicep · GitHub Actions / Azure DevOps

Related Patterns

• AKS platform architecture
• From architecture diagram to production