Compute & hosting

Every client engagement we run has built on Azure to date — the three services below are described in that depth because that's where the hands-on experience is. The same architectural patterns apply directly on AWS (Elastic Beanstalk, Lambda, EKS) or Google Cloud (App Engine, Cloud Run, GKE) when that's the platform a client is already standardized on; the trade-offs between managed hosting, serverless, and containers don't change by vendor.

Managed app hosting — Azure App Service

Azure App Service is Microsoft's platform-as-a-service for hosting web applications and APIs — you deploy code or a container image, and Azure handles the underlying VM, OS patching, and web server configuration. It supports ASP.NET, ASP.NET Core, Java, Node.js, PHP, and Python out of the box, running on either Windows or Linux, and it carries a 99.99% uptime SLA once you're past the free/shared development tiers. Compute plans range from shared instances for small or dev workloads up to isolated, single-tenant environments for apps that need network isolation from other tenants.

Because it's a managed platform rather than a set of VMs you provision yourself, the features that matter for running something in production come built in: autoscaling based on load, deployment slots that let you stage a new release and swap it into production with no downtime, integrated authentication, and hooks for standard CI/CD pipelines. That's what makes it the default landing spot for a web app that doesn't need custom infrastructure control — you're trading some low-level flexibility for not having to own patch schedules, load balancer configuration, or VM sizing decisions.

Moving an existing application off aging on-prem infrastructure usually starts with a discovery and assessment pass — profiling what's actually running (framework version, dependencies, resource usage) and flagging whether an app is a realistic candidate for managed hosting as-is, or needs work first. From there, the path splits into a few standard strategies: rehost ("lift and shift"), where the app moves with little to no code change; replatform, where the app is retargeted but a few things change underneath it — a local SQL Server instance becomes a managed database, local file storage becomes blob storage; and refactor, where the application is restructured to actually take advantage of the platform.

How CloudCompass AI uses it

We use App Service both for new client-facing applications and as the landing target when we're moving a client off legacy, self-managed hosting — running an assessment first to figure out whether a given app is a clean lift-and-shift or needs a database or storage swap along the way, then staging the move through a deployment slot so the cutover doesn't require a maintenance window.

Serverless compute — Azure Functions

Azure Functions is Microsoft's serverless compute platform: you write a function, attach it to a trigger — a new file in storage, a message on a queue, an HTTP request, a timer — and Azure runs it when that trigger fires, without you provisioning or managing a server in between. It supports C#, Java, JavaScript, PowerShell, Python, Rust, and Go.

Scaling is handled automatically, from zero instances when nothing's happening up to whatever concurrency a burst of triggers requires. For workflows that need to persist state across multiple steps — waiting on external input, retrying failed steps, running steps in sequence — Durable Functions adds orchestration with built-in checkpointing, so a multi-step process can survive a restart partway through. Because it only runs (and only bills) in response to events, it's the right fit for processing that's inherently event-driven rather than continuous: reacting to files as they arrive, handling real-time data streams, integrating services without hard-wiring them together, and increasingly, running the backend logic behind chatbots and retrieval-augmented AI applications.

How CloudCompass AI uses it

We use serverless functions for exactly the kind of work they're designed for: processing that only needs to happen when something specific occurs, not on a server running around the clock waiting for it. That covers asset conversion — a file gets uploaded and a function transforms it — and general event handling where one system's action needs to trigger a response in another, without us standing up and maintaining a dedicated service just to sit idle between events.

Containers at scale — Azure Kubernetes Service

Azure Kubernetes Service (AKS) offloads the operational overhead of running Kubernetes to Azure. When a cluster is created, Azure provisions and manages the control plane automatically, at no charge — the layer responsible for scheduling, health monitoring, and coordinating the worker nodes that actually run an application's containers. Billing only applies to those worker nodes. AKS is CNCF-certified and compliant with SOC, ISO, PCI DSS, and HIPAA, which matters for regulated workloads that need that certification trail before containers go into production.

AKS Automatic is the fully managed option: Azure provisions and scales nodes on demand, security defaults are on out of the box, and monitoring is preconfigured rather than something to wire up manually, backed by a financially backed SLA. AKS Standard trades that hands-off default for full control over node pools and cluster configuration — the right choice when an application needs custom networking, specific VM SKUs, or has to fit into infrastructure automation that already exists. In practice, this is where an application lands once it's built (or being rebuilt) as a set of independently deployable services rather than one monolith.

How CloudCompass AI uses it

When a client's application is, or is becoming, a set of independently deployable services rather than a single deployable unit, we run it on AKS instead of App Service. We typically start on AKS Automatic for the built-in security and monitoring defaults, moving to Standard mode only when a client's networking requirements or existing infrastructure automation actually call for that level of manual control — and we wire the cluster into whatever data layer is already running for that client, with CI/CD driving continuous deployment into it.