A Market Maturing — But Not Yet Grown Up

Analyst firm Cloud Spectator published a report around this time examining the relationship between price and performance across cloud providers. Its findings echoed earlier studies: the largest hyperscalers — Amazon Web Services, Microsoft Azure, and Google Cloud — are not always the best fit for every organisation when compared with high-performance, lower-cost specialists. OVH, for example, bucked the typical narrative by ranking second in that report despite being considerably smaller than the hyperscaler giants.

A panel session at Cloud Expo Europe brought together senior voices from IBM, OVH, and Rackspace to address how the biggest names in cloud are adapting their strategies in response to a more sophisticated customer base and a more crowded market.

IBM: From Cloud Awareness to Business Innovation

Rene Bostic, Technical Vice President of Innovation and New Technologies at IBM Cloud, described a marked shift in how organisations think about cloud. Two years prior, IBM’s primary job was helping customers understand what cloud even was. By the time of this panel, customers had largely cleared that hurdle.

“Our customers understand what cloud is, they understand the use cases. The focus now is on business innovation. How can you monetise the cloud environments that you have — how can you make sure your startup companies and other companies won’t take your market share away fast?”

Rene Bostic, Technical VP of Innovation and New Technologies, IBM Cloud

Bostic illustrated this with a practical example: IBM’s integration of Watson AI into customer service workflows. Watson analyses the tone of incoming customer communications — identifying whether a caller is frustrated, calm, or upset — and helps agents tailor their responses accordingly. This kind of applied AI sits on top of cloud infrastructure in a way that is effectively invisible to the end user.

Bostic also described an insurance provider use case in which IBM integrated its cloud platform with The Weather Company (acquired by IBM in early 2016) via its API. The system sends real-time alerts to policyholders based on weather conditions — for example, warning a user that a hailstorm is approaching and suggesting they move their vehicle under cover. The practical result is fewer claims. Crucially, the policyholder has no visibility into which cloud infrastructure is running the service.

OVH: Avoiding Vendor Lock-In at All Costs

Russell Reeder, President and CEO of OVH US, made a strong case for open-source approaches as the antidote to the vendor lock-in that has burned organisations in the past. His message was straightforward: customers who have experienced lock-in once are deeply motivated to avoid it again.

“As a customer, people should be really afraid of the cloud — and choosing the wrong cloud provider and being locked in.”

Russell Reeder, President and CEO, OVH US

To address the skills gap from his organisation’s perspective, OVH has been building self-service tooling so that customers who have the technical capability can manage their own migrations without needing to engage external consultants or wait on provider support teams.

Despite the industry’s growing maturity, Reeder emphasised that cloud adoption is still in its early chapters. Alex Hilton, CEO of the Cloud Industry Forum and session moderator, offered a more colourful take: he described the cloud as “adolescent” — capable and increasingly self-aware, but not yet fully formed.

Rackspace: Managed Services Across a Multi-Cloud World

Rackspace’s strategic repositioning — from operating its own public cloud to providing managed services across the major public cloud platforms — was a central topic. Lee James, Rackspace’s Chief Technology Officer, articulated the company’s working assumption clearly: their customers are already operating in a multi-cloud environment, and Rackspace’s job is to broker and optimise that reality.

“For us, it’s not about saying ‘how do you justify the support on top of AWS?’ — we expect all of you to be in a multi-cloud world, so how do we broker that for you? How do we optimise that for you?”

Lee James, CTO, Rackspace

James backed this up with two concrete customer examples. A furniture retailer benefits from elastic scaling — ramping capacity up or down in line with seasonal demand fluctuations. A food manufacturer runs its entire operation on AWS, with Rackspace actively managing cost optimisation on its behalf. Notably, Rackspace’s commitment to service extends to provider transitions: if a customer decides to switch cloud providers, Rackspace will migrate them at no charge.

Rackspace has also invested in internal training infrastructure, opening a dedicated “university” to develop cloud skills within its own workforce — a response, at least in part, to the wider industry skills shortage.

The Skills Gap: Still Unresolved

All three panellists acknowledged the cloud skills gap as a persistent, unresolved problem. Across the industry, demand for engineers and architects with hands-on cloud experience continues to outpace supply. Each provider is approaching the problem differently:

• OVH is investing in self-service tooling so that technically capable customers can handle migrations themselves, reducing dependency on scarce skilled labour.
• Rackspace has created internal training through its cloud university to upskill its own staff.
• IBM is focusing increasingly on cloud-native application development as a way to build skills organically within the enterprises it works with.

Key Takeaways for DevOps and Infrastructure Teams

The panel’s discussion surfaces several themes that remain directly relevant for DevOps engineers and platform teams making architectural decisions:

• Multi-cloud is the default, not the exception. Organisations should plan for heterogeneous environments rather than betting on a single provider.
• Vendor lock-in is a genuine risk. Favour open standards, portable container orchestration, and abstraction layers that allow workloads to move between providers.
• Managed services add measurable value. For teams without deep cloud expertise, managed services can deliver cost optimisation and operational stability that would be difficult to achieve internally.
• Cloud-native design matters. Applications built with cloud-native principles — stateless services, horizontal scalability, infrastructure-as-code — are inherently more portable and easier to optimise across providers.
• Skills investment is non-negotiable. Whether through internal training programmes or self-service platform tooling, closing the skills gap is a prerequisite for realising the value of cloud investment.

The broader message from Cloud Expo Europe was one of cautious optimism. Cloud infrastructure has matured significantly, but the industry is still working through the implications — for skills, for architecture, and for the competitive dynamics between providers of every size.

From Snowballs to Snowmobiles: AWS’s Scale Problem

When large enterprises — particularly banks — first move to Amazon Web Services, they face an immediate physical challenge: how do you transfer petabytes of legacy data into the cloud? AWS solved this with its Snowball appliance: a ruggedized, encrypted storage device shipped to a client site, filled with data on-premises, then physically transported to an AWS data centre for upload.

As customer data volumes grew, even the Snowball Edge (with higher capacity than the standard Snowball) was no longer sufficient for some enterprises. AWS’s response was characteristically blunt: mount a purpose-built, data-centre-grade container on a tractor-trailer. They called it a Snowmobile. The customer plugs it into their data centre, the data is encrypted and ingested, the truck drives to an AWS facility, and the data is uploaded and re-encrypted. It is a vivid illustration of how seriously AWS treats the mechanics of large-scale data migration.

AWS and Azure Dominate Financial Services

Since AWS relaunched its commercial cloud platform in 2006, it has become the de facto standard for enterprise cloud infrastructure. By 2017, AWS revenues had reached approximately $14 billion annually, up from roughly $10 billion the prior year, and the platform counted Nasdaq and all Fortune 50 companies among its customers.

Financial services adoption lagged other industries — banks are famously conservative — but the pace accelerated dramatically in the mid-2010s. Major institutions including Citigroup, JPMorgan, and HSBC moved workloads onto AWS. Regulators themselves followed: the UK’s Financial Conduct Authority (FCA) and the US Financial Industry Regulatory Authority (FINRA) became cloud customers.

Microsoft Azure pursued a parallel strategy. By mid-2017, Microsoft claimed that 85% of systemically important banks had signed on to Azure, ranging from established names like UBS to new entrants like ClearBank.

A survey of more than 40 London fintechs at the time found that the vast majority ran on AWS, with most of the remainder on Azure, and only three using both.

The Systemic Risk Question

The concentration of financial infrastructure in two cloud providers triggered a familiar debate. In June 2017, the Financial Stability Board (FSB) raised concerns about the systemic risk created by banks’ dependence on third-party providers, specifically calling out cloud computing and data services. The FSB urged local regulators to assess whether tighter rules were warranted, and acknowledged that it lacked sufficient data to draw firm conclusions — one proposed measure was requiring banks to disclose which third-party providers they rely on.

“The moment that there is a security flaw or an availability flaw within the Amazon fabric, for us that is a catastrophic failure.”

Gavin Jackson, Head of EMEA, Amazon Web Services

The analogy to the 2008 financial crisis is not merely rhetorical. Systemically important financial institutions (SIFIs) were considered too big to fail because their collapse would cascade through the global economy. The question regulators began asking in 2017 was whether AWS or Azure had achieved a comparable degree of systemic importance — not through financial leverage, but through operational dependency.

Why Multi-Cloud Is Harder Than It Sounds

The obvious mitigation for concentration risk is diversification: require financial institutions to spread workloads across multiple providers. In practice, this is more complicated than it appears.

Modern cloud platforms are not simply storage and compute rentals. AWS and Azure each offer deeply integrated ecosystems of services — databases, analytics pipelines, machine learning frameworks, security tooling, identity management, and more. A financial institution that builds its core platform on AWS-native services (such as RDS, Redshift, or SageMaker) cannot simply replicate those workloads on Azure without significant re-engineering. The two platforms’ APIs, data models, and operational tooling are fundamentally different.

Andrew White, co-founder of FundApps, put it plainly: running on both AWS and Azure would “pretty much require near duplication of all operational infrastructure and staff and would be a nightmare for any company, large or small.” Charlie Henderson, co-founder of Feedstock, noted the same problem from the vendor side: when a bank insists on Azure and his product is built on AWS, “you have to rebuild it, which is very costly.”

Gavin Jackson of AWS pushed back on the framing of “lock-in” altogether, arguing that AWS services are built on open standards and open-source software, making it technically possible for customers to leave. Microsoft’s Richard Peers acknowledged that switching difficulty is a “real issue” while arguing that the risk calculus must be proportionate — a small fintech representing 0.01% of UK payment volumes does not carry the same systemic weight as a clearinghouse or payment rail.

One company, Credit Benchmark, took a different path entirely, selecting CenturyLink as its cloud provider rather than AWS or Azure. Its CTO described the trade-off plainly: the ready-made managed services on the major platforms make life easier in the short term, but deepen dependency over time.

The Shared Responsibility Model and Its Gaps

Cloud providers operate on a shared responsibility model: the provider secures the underlying infrastructure, while the customer is responsible for securing everything they build on top of it — their data, their access controls, their application configurations, and their network rules.

“If you are architecting your applications for a single data centre in a single availability zone in a single region, then you could argue there’s an accident waiting to happen.”

Gavin Jackson, Head of EMEA, Amazon Web Services

Javvad Malik, security advocate at AlienVault, identified a persistent and dangerous misunderstanding in the financial sector: the belief that moving to AWS transfers security responsibility to Amazon. “‘We put it on Amazon so it must be secure,” he said, is a mindset that is “wrongly embedded” among bank management. It ignores firewalls, operating system hardening, and database configuration — all of which remain the customer’s domain.

Malik also flagged a structural skills gap: cloud security expertise is not uniformly distributed across financial institutions’ IT teams. Where that knowledge gap exists, risk follows. A further complication is outsourcing — some banks delegate management of their AWS accounts to third parties, adding another link in the chain and another potential point of failure.

Ankur Modi, CEO of cybersecurity startup StatusToday, noted that even the most robust infrastructure is not immune to outages. In February 2017, a misconfigured command during routine maintenance of AWS S3 in the US-EAST-1 region caused a significant outage that disrupted a wide range of services — including Business Insider, Quora, Medium, and AWS’s own status dashboard — for several hours. The incident was caused by human error, not a security breach, but it illustrated that availability risk is real regardless of the provider’s security record.

AWS’s Argument: Resilience by Design

AWS counters concentration risk arguments with its global infrastructure architecture. The platform operates across multiple geographic regions, each divided into multiple isolated Availability Zones — physically separate data centres within a region, connected by high-bandwidth, low-latency links. Customers who architect their applications to span multiple AZs and multiple regions gain a degree of resilience that most on-premises deployments cannot match.

Jackson argued that AWS does not access customer data — it is always encrypted and controlled by the customer, who determines the region and replication strategy. He declined to disclose AWS’s security investment figures but pointed to over eleven years of operation without a major security breach of the underlying infrastructure as evidence of the platform’s trustworthiness.

The broader argument from both AWS and Microsoft is that, for most financial institutions, running on a major cloud provider is more secure than maintaining aging on-premises infrastructure with limited security budgets and staff. The pendulum, as Jackson described it, had shifted: banks were no longer asking “How do I think about security in the cloud?” but rather “I have to get into the cloud, because of security.”

Key Takeaways for DevOps and Platform Teams

• Shared responsibility is not optional. Cloud providers secure their infrastructure; you secure everything you build on it. Misconfigurations, weak IAM policies, and unpatched OS images are your problem, not AWS’s.
• Multi-AZ and multi-region architecture matters. Deploying to a single availability zone in a single region exposes you to outages like the 2017 S3 incident. Design for failure from the start.
• Multi-cloud is architecturally expensive. True workload portability between AWS and Azure requires avoiding provider-native managed services and accepting significant operational overhead. Evaluate this trade-off honestly before committing.
• Vendor lock-in is real, even with open-source tooling. Using open-source software does not eliminate lock-in if your operational tooling, IAM, networking, and data services are tightly coupled to one provider’s abstractions.
• Concentration risk is a governance issue, not just a technical one. For regulated financial institutions, documenting third-party dependencies — including cloud providers — is increasingly a regulatory expectation, not merely a best practice.
• Skills gaps are an underestimated risk vector. Migrating to the cloud without investing in cloud-native security expertise creates exposure regardless of the provider’s own security posture.

Where the Debate Stands

The concentration risk debate in financial services cloud has not been resolved — it has intensified. Regulators in the UK, EU, and US have continued to develop frameworks for operational resilience that explicitly address cloud dependency, including requirements for exit planning and third-party risk management. The FSB’s concerns about systemic risk from cloud concentration remain active policy questions.

For DevOps and platform engineers working in or adjacent to financial services, this debate has direct operational implications. Architecture decisions that seem purely technical — which managed database to use, how to structure IAM, whether to use a provider’s native container orchestration — carry regulatory and systemic risk dimensions that teams need to understand and document.

As Jackson noted in 2017, the cloud market — even dominated by two players — was still early. That remains true. But the infrastructural and regulatory stakes have only grown since.