Cloud Adoption Is Widespread, but Deep Value Remains Elusive

Despite cloud computing being mainstream for well over a decade, many organizations are still treating it as little more than a remote data centre — a place to park virtual machines (VMs) rather than a platform for genuine transformation. The author, writing from more than ten years of hands-on experience as a CIO and CTO, argues that this conservative posture leaves the most important benefits of cloud computing completely untapped.

Case Study: Elastic Donation Infrastructure at Comic Relief

The author’s first significant encounter with cloud’s transformational potential came in 2009 while serving as CIO of Comic Relief, the UK charity known for its televised fundraising events (Red Nose Day and Sport Relief). The organisation faced a classic traffic-spike engineering problem: its telethons, watched by millions, generated enormous bursts of online donation traffic concentrated in a very short window on broadcast night. Building permanent on-premises infrastructure capable of sustaining hundreds of transactions per second — for only one or two peaks per year — would have been financially unsustainable.

Working with major technology partners, the team built a horizontally scalable, cloud-based donation platform. Horizontal scalability in this context meant that capacity could be increased by adding additional compute nodes during peak demand, rather than replacing or upgrading existing hardware. Nodes could be provisioned cheaply and quickly, and decommissioned once the peak had passed. The result was an autoscaling system that set transaction-volume records while keeping infrastructure costs proportionate to actual usage — an early, practical proof of what cloud elasticity could deliver.

Case Study: Migrating the National Geographic Image Collection to Google Cloud

Later, as CTO at National Geographic in Washington, D.C., the author led the migration of the organisation’s image collection — approximately two million iconic photographs, including the famous “Afghan Girl” portrait — from an internal on-premises platform to Google Cloud.

The migration addressed two distinct problems:

• Performance: The legacy on-premises system could no longer keep pace with user expectations as concurrent session counts grew. Moving to Google Cloud provided cost-effective access to additional compute capacity, improving application responsiveness at scale.
• Security: The existing system relied on a simple username-and-password authentication model that was out of alignment with modern security policies. The migration enabled the team to implement a new identity and access management (IAM) framework using Google Cloud’s native capabilities, restricting access to properly authenticated users and significantly improving the overall security posture.

The National Geographic case illustrates that cloud migration, when approached thoughtfully, is an opportunity to remediate technical debt in security and architecture — not just to replicate existing infrastructure in a different location.

Why Most Cloud Migrations Underperform

Enterprise cloud adoption, while growing, remains shallower than headline figures suggest. Even organisations that have formally adopted cloud services often have only a small fraction of their total workloads running off-premises. Two structural barriers explain much of the gap between cloud’s promise and its delivered value.

1. Hidden Transition Costs

The cost savings cited by cloud providers are real over the long term, but they are not automatic. Organisations frequently encounter an initial increase in costs during and immediately after migration, driven by factors including:

• Investment in retraining existing staff in cloud-native tools and practices
• New operational processes required for cloud environments — revised security policies, VPN configurations, access controls
• Data residency and sovereignty laws in certain jurisdictions that restrict where data can be stored or processed
• A shift from capital expenditure (CapEx) for hardware purchases to operational expenditure (OpEx) for cloud consumption — a change that can disrupt established budgeting and financial approval processes

2. Legacy Application Architecture

Many enterprise applications were designed within a data-centre paradigm: large, monolithic codebases running on tightly coupled hardware and middleware. These architectural characteristics directly limit the ability to exploit cloud-native capabilities. For example, decomposing a monolith into microservices and well-defined APIs allows separate teams to develop, test, and deploy individual components independently, reducing deployment bottlenecks and enabling faster iteration. A monolith moved to the cloud as-is gains little from that decomposition opportunity.

This is why a pure “lift and shift” strategy — moving VMs and their workloads to cloud infrastructure with no architectural changes — frequently fails to deliver meaningful improvements. It relocates existing constraints rather than resolving them.

The Alternative: A “Move and Improve” Mindset

Rather than treating migration as a destination, organisations should treat it as the beginning of a modernisation journey. The author proposes a four-phase framework for progressive cloud transformation.

Phase 1: Audit and Rationalize

Before migrating anything, take stock of what you actually have and whether it is worth migrating. Key questions to answer at this stage:

• Which applications are mission-critical, and which are candidates for deprecation?
• Could a legacy custom-built application be replaced entirely by a modern SaaS product, avoiding a complex migration altogether?
• What are the dependencies between systems, and in what order should workloads move?

A structured audit prevents teams from investing effort migrating applications that should be retired or replaced — a common and expensive mistake.

Phase 2: Optimize

Once the migration roadmap is clear, identify immediate improvements that the move to cloud makes possible. Security is often the most accessible quick win: replacing a weak authentication model with cloud-native IAM, enforcing least-privilege access, and enabling audit logging are improvements that can be implemented during migration without requiring significant changes to application code.

Phase 3: Enhance

Look for components of the application — or services that support it — that can be upgraded independently, without a full rewrite. Examples include:

• Replacing an aging relational database with a cloud-native managed database service, reducing licensing costs and operational overhead
• Improving front-end performance to increase conversion rates for customer-facing applications — quantifying the revenue impact of performance improvements helps build the business case
• Offloading static asset delivery to a cloud CDN to reduce latency globally

The enhancement phase is most effective when guided by the key business metrics that matter most to the organisation. Start with the pain points that have measurable financial or operational consequences.

Phase 4: Modernize

With a stable, optimised cloud-hosted application as the foundation, teams can begin more fundamental architectural changes. This is where cloud-native capabilities deliver their greatest leverage:

• Decomposing monolithic applications into microservices and APIs, allowing independent deployment of discrete components and significantly increasing development velocity
• Replacing rule-based or manual processes with machine-learning services — for example, automating metadata tagging in a document management system, with human review reserved for edge cases
• Adopting managed services for infrastructure-heavy concerns (queuing, caching, storage, identity) so that engineering effort shifts toward product features rather than platform maintenance

Lift and Shift Is a Starting Point, Not a Strategy

Moving VMs to the cloud can be a legitimate first step — it establishes connectivity, builds team familiarity with cloud operations, and may deliver some immediate cost relief on ageing hardware. But it should be understood as a foundation, not a finished state. The durable value of cloud computing for an organisation comes from progressively modernising the applications and processes that run on top of it.

For technology leaders, this means framing cloud adoption internally not as an infrastructure project but as a business transformation programme — one that requires sustained investment in people, process, and architecture, and that delivers compounding returns over time rather than a single cost-reduction event.

Key Takeaways for DevOps and Platform Teams

• Elasticity is the killer feature: If your cloud architecture cannot scale dynamically in response to demand, you are not exploiting the fundamental advantage cloud provides over on-premises infrastructure.
• Audit before you migrate: Not every workload deserves to be migrated. Replace or retire where possible; only migrate what genuinely needs to move.
• Security is not optional: Migration is an opportunity to raise your security baseline. IAM, secrets management, and zero-trust network access should be part of every cloud project scope.
• Decompose incrementally: You do not need to rebuild everything as microservices on day one. Identify bounded contexts within existing monoliths and extract them progressively.
• Measure business outcomes: Cloud projects that cannot demonstrate impact on revenue, cost, or risk will lose executive support. Instrument early, measure continuously, and communicate results clearly.

Overview

Microsoft Build 2019 moved well beyond the traditional major-release cadence and instead delivered a broad set of incremental but meaningful improvements across Azure. For DevOps engineers, the announcements touched on Kubernetes orchestration, relational and NoSQL databases, serverless computing, blockchain infrastructure, and machine learning tooling. This article organises those announcements into actionable categories.

Containers and Kubernetes (AKS)

Containers and Kubernetes remain central to cloud-native DevOps, and Microsoft used Build 2019 to shore up rough edges in Azure Kubernetes Service (AKS).

Azure Dev Spaces

Dev Spaces creates a shared development cluster where team members can iterate on individual microservices without affecting other components of the application. It is intentionally scoped to development clusters rather than production environments, reducing the risk of accidental interference between developers working on the same distributed system.

Azure Pipelines Integration with AKS

A tighter integration between Azure Pipelines and AKS was announced to streamline deployments from a Git repository directly to a Kubernetes cluster. The goal is to lower the barrier for teams adopting CI/CD pipelines with containerised workloads.

Azure Policy for AKS

Azure Policy — a governance tool for enforcing organisational standards across cloud resources — was extended to cover AKS deployments. This enables platform teams to apply consistent compliance rules to Kubernetes clusters alongside other Azure resources, something that had previously required separate tooling.

KEDA: Kubernetes-Based Event-Driven Autoscaling

KEDA (Kubernetes-based Event-Driven Autoscaling) is an open-source project co-developed by Microsoft and Red Hat. It brings Functions-as-a-Service-style event-driven scaling to any Kubernetes cluster, including AKS. Rather than triggering scale-out based solely on CPU or memory thresholds, KEDA scales workloads in response to events from sources such as:

• Apache Kafka streams
• Azure Storage Queues
• Azure Service Bus
• RabbitMQ
• HTTP requests
• Azure Event Grid

This makes KEDA well-suited to batch processing, message-driven architectures, and any workload with bursty, unpredictable demand patterns.

AKS Virtual Nodes: Generally Available

Virtual nodes — built on the Virtual Kubelet technology that Microsoft donated to the Cloud Native Computing Foundation (CNCF) — reached general availability. Virtual nodes allow AKS clusters to burst container workloads onto Azure Container Instances almost instantaneously, rather than waiting for new VM-backed nodes to provision. Billing is per-second. At the time of the announcement, virtual nodes supported Linux containers only.

Database Announcements

Build 2019 featured a significant number of database-related announcements, reflecting both the volume of data organisations are managing and the variety of workloads they need to support.

Azure SQL Database Edge

Azure SQL Database Edge is a lightweight relational engine designed for edge computing scenarios. Key characteristics announced at the time included:

• Support for both ARM and Intel processors
• Optimisation for data streaming and time-series workloads
• Built-in machine learning for local inference before optionally uploading data to the cloud
• Cloud-managed updates via Azure
• Linux-only at the time of announcement; in private preview

Azure SQL Database Hyperscale

The Hyperscale tier for Azure SQL Database is designed to remove the traditional ceiling on relational database size and performance. It distributes data across multiple nodes and handles sharding automatically, while still presenting a single connection endpoint to application developers. Announced capabilities included:

• Storage up to 100 TB (with larger limits planned)
• Near-instant backups and restores
• Optimisation for OLTP workloads

A Hyperscale tier for PostgreSQL (via Azure Database for PostgreSQL) was also referenced as part of the broader announcement.

Azure SQL Database Serverless

The serverless compute tier for Azure SQL Database automatically pauses compute resources when a database is idle and resumes them on the next request. During inactive periods, customers pay only for storage. This model suits intermittent or unpredictable workloads where keeping compute running continuously would be wasteful.

Cosmos DB: Apache Spark, Jupyter Notebooks, and etcd API

Azure Cosmos DB received several additions targeting analytics and operational intelligence:

• Apache Spark integration: Enables running operational analytics and AI workloads directly against globally distributed Cosmos DB data, using Spark alongside existing protocol connectors (Cassandra, MongoDB, Gremlin).
• Jupyter Notebooks: Integrated directly into the Cosmos DB portal, allowing data exploration and ML query development without leaving the database environment.
• etcd API: Allows Kubernetes clusters to use Cosmos DB as the backing store for etcd configuration data, enabling globally distributed Kubernetes control planes.

Azure Blockchain Service

Azure Blockchain Service entered public preview at Build 2019. It is a fully managed service for provisioning and operating consortium blockchain networks, handling the underlying infrastructure so that teams can focus on writing smart contracts and business logic rather than configuring nodes and networking.

Complementing the managed service, Microsoft also announced:

• Azure Blockchain Development Kit: Includes connectors for Microsoft Flow and Logic Apps, enabling non-expert developers to integrate blockchain workflows into existing business processes.
• Visual Studio Code plug-in: Aimed at simplifying smart contract development within a familiar IDE.

Artificial Intelligence and Machine Learning

Azure Form Recognizer

Form Recognizer is a cognitive service that extracts text, key-value pairs, and table data from forms using a small set of sample documents (approximately five examples). This removes the need to build a bespoke ML model for every form type, which has practical implications for automating document processing at scale across industries such as healthcare, finance, and logistics.

Visual Interface for Azure Machine Learning

A new drag-and-drop visual interface for Azure Machine Learning was introduced, making it possible to build, train, and deploy models without writing code. This lowers the entry barrier for developers who work with data but are not dedicated ML practitioners.

MLOps and Azure DevOps Integration

Microsoft formalised the concept of MLOps — treating ML model development with the same lifecycle management practices applied to application code. Integration with Azure DevOps means that model training runs, versioning, and deployments can participate in standard CI/CD pipelines.

ML.NET

ML.NET brings machine learning capabilities to .NET developers using familiar C# or F# workflows, without requiring Python expertise or external ML frameworks. Build 2019 featured improvements to the library, though the specific version details in the original source material were not fully enumerated here.

Azure Active Directory for GitHub Enterprise

Following Microsoft’s acquisition of GitHub, Build 2019 included the announcement that Azure Active Directory authentication is now supported for GitHub Enterprise, enabling organisations to enforce existing identity and access management policies across their source control environment.

Summary of Key Announcements

What to Watch Next

Build 2019 represented only a portion of Microsoft’s Azure roadmap at the time. Services announced shortly after the conference — including Azure Lighthouse (multi-tenant management) and Azure Bastion (managed jump-host service) — continued the theme of reducing operational complexity for platform and DevOps teams. Many of the preview features listed above have since reached general availability; always verify current status in the official Azure documentation before adopting them for production workloads.

Original reporting by Paul Schnackenburg for virtualizationreview.com. Paul is an IT consultant specialising in Windows, Hyper-V, and Exchange Server solutions.

Background: GitHub Post-Microsoft Acquisition

Following Microsoft’s acquisition of GitHub for $7.5 billion in stock, GitHub moved quickly to demonstrate that its developer-first culture remained intact. A series of platform-level security and collaboration improvements — aimed squarely at enterprise users — formed a key part of that effort. These updates address two persistent pain points for large engineering organizations: lack of cross-team visibility, and poor open source dependency governance.

Organization Insights: Visibility Into How Teams Collaborate

GitHub launched a beta of organization insights for GitHub Enterprise users. The feature aggregates development activity data across an organization, giving engineering leaders a consolidated view of how teams are working and what technologies they are adopting.

Mario Rodriguez, Senior Product Director for GitHub Enterprise, described the intent to The Daily Swig:

“This allows large enterprises to get a deeper look into software development trends at their organizations and helps them stay ahead of their talent needs, where the future is taking them, and which languages are being used the most.”

— Mario Rodriguez, Senior Product Director, GitHub Enterprise

Rodriguez added that organizations undergoing DevOps transformations can use the feature to track code reuse, improve code review practices, and surface collaboration metrics that were previously spread across individual team dashboards.

Dependency Insights: Auditing Open Source Risk at Scale

Alongside organization insights, GitHub introduced dependency insights — a built-in auditing and reporting layer for the open source packages an enterprise relies on. The feature surfaces two categories of risk that frequently catch organizations off guard:

• Security vulnerabilities in upstream open source dependencies
• License compliance issues, particularly with restrictive or copyleft licenses that may conflict with proprietary software distribution

Justin Hutchings, Senior Product Manager of Security at GitHub, explained the business motivation:

“We know that modern software development organizations rely on increasing amounts of open source code, but like any code, open source code is not without risks. When we talk to customers, they tell us that they’re worried about what happens if they miss a security vulnerability or accidentally ship something that depends on a very restrictive license.”

— Justin Hutchings, Senior Product Manager of Security, GitHub

The dependency insights dashboard allows enterprises to:

• Identify which open source licenses are in use across the organization
• Trace which upstream projects and maintainers dependencies originate from
• Understand contributor activity in those upstream projects
• Spot known security vulnerabilities linked to specific dependency versions

For DevOps and platform engineering teams, this kind of centralized dependency intelligence reduces the manual work required to comply with internal security policies or external regulatory requirements.

Bug Bounty Program: Five Years and Growing

These platform improvements coincided with GitHub marking five years of its bug bounty program. In 2018, GitHub paid out $250,000 to security researchers through bounty payouts and research grants. The platform also increased bounty ceilings, with the most critical vulnerability classes now attracting rewards exceeding $30,000.

GitHub also updated its Legal Safe Harbor terms, offering explicit protections to researchers who uncover issues in good faith — even if their methods technically violate the bounty policy. GitHub additionally committed to advocating on behalf of researchers against third parties who may not extend the same protections.

DDoS Resilience: Lessons From the 2018 Attack

In March 2018, GitHub experienced what was widely reported as one of the largest DDoS attacks ever recorded at the time. The attack exploited memcached amplification, generating an enormous volume of traffic directed at GitHub’s infrastructure.

GitHub responded by routing all incoming traffic through Akamai Prolexic, its DDoS mitigation provider, which scrubbed malicious packets in real time. The attack subsided within minutes of mitigation being engaged.

Sam Kottler, Senior Manager of Infrastructure at GitHub, told The Daily Swig that the company has since invested significantly in network capacity:

“We’ve significantly grown our transit capacity over the years, which has allowed us to withstand certain volumetric attacks without impact to users. We’re continuing to deploy additional transit capacity, add points of presence, and develop robust peering relationships across a diverse set of exchanges.”

— Sam Kottler, Senior Manager of Infrastructure, GitHub

For teams hosting critical code and CI/CD pipelines on GitHub, this infrastructure investment matters directly: availability of the platform is a prerequisite for the reliability of any deployment pipeline that depends on it.

What This Means for DevOps Teams

Taken together, these improvements reflect a broader shift in how developer platforms are expected to support security and compliance, not just code hosting. Key takeaways for engineering and platform teams:

• Dependency governance is becoming a platform-level concern. Tracking open source licenses and vulnerability exposure manually at scale is not realistic; built-in tooling reduces that burden.
• Organization-level metrics matter for DevOps maturity. Understanding collaboration patterns, language adoption, and code reuse rates helps leaders make better investment decisions.
• Infrastructure resilience is a shared responsibility. GitHub’s DDoS investments protect its infrastructure, but teams should also design pipelines with fallback mechanisms for platform outages.
• Bug bounty transparency builds trust. Clear legal safe harbor terms lower the barrier for researchers to responsibly disclose vulnerabilities, which ultimately benefits all users.