Cloud Computing Becomes Mission-Critical Infrastructure

By mid-2020, cloud computing had shifted from a strategic priority to an operational lifeline. The COVID-19 pandemic forced enterprises, governments, and educational institutions to accelerate digital transformation plans that had previously been projected to unfold over several years. Remote work, distance learning, and the sudden shutdown of physical offices placed an enormous burden on cloud infrastructure — and exposed how underprepared many organizations were.

Wedbush Securities analyst Dan Ives captured the moment clearly in a research note from June 2020:

“With remote learning, work from home and more applications and technology needing to be accessed during this ‘new normal’… the shift to cloud computing over the last few years is now the ‘hearts and lungs’ core technology and infrastructure enabling companies and governments globally to operate smoothly during this unprecedented environment.”

Dan Ives, Wedbush Securities

Ives specifically highlighted front-line collaboration tools — Zoom, DocuSign, Citrix, Microsoft Teams, and Slack — as the visible face of the pandemic response, while pointing to the hyperscale public and hybrid cloud providers (AWS, Microsoft Azure, and Google Cloud) as the foundational infrastructure enabling those tools to function at scale.

Cloud Spending Bucked the 2020 IT Downturn

The broader IT industry took a significant hit in 2020. Research firm Gartner projected that global IT spending would fall approximately 8 percent to $3.4 trillion as a result of the pandemic-driven economic recession. Cloud computing, however, moved in the opposite direction: Gartner forecast cloud spending to increase by roughly 19 percent over the same period.

This divergence reflected a broader structural shift. Cloud migrations and infrastructure modernization projects that had been on multi-year roadmaps were suddenly being fast-tracked. As Ives noted, many enterprises found themselves “caught flat-footed with a lack of cloud-enabled functionality” — a reality that compressed timelines dramatically.

A Turning Point for Enterprise Cloud Adoption

Wedbush’s analysis suggested that the pandemic represented a genuine inflection point — not just a temporary spike in cloud usage. Prior to the pandemic, the firm’s baseline forecast projected that cloud workloads would grow from approximately 33 percent of enterprise workloads to 55 percent by 2022. By mid-2020, Ives believed those targets could be hit a full year ahead of schedule.

“We believe this coronavirus pandemic is a key turning point in the technology world around deploying cloud-driven environments… With our expectations of a trillion dollars to be spent in the cloud over the next decade, there will be many beneficiaries — cybersecurity, data center plays, cloud stack/enablers, hybrid cloud, applications — across the technology landscape.”

Dan Ives, Wedbush Securities

Microsoft Azure and AWS were identified as the two vendors best positioned to capture the sustained acceleration in cloud infrastructure spending both during and after the pandemic.

Why Cloud Startups Thrived in This Environment

Venture-backed cloud startups were uniquely positioned to benefit from this acceleration. With hyperscalers providing the foundational infrastructure, startups were free to build specialized tooling, platforms, and services on top of it — targeting specific pain points that large cloud vendors were too generalized to address effectively.

Key areas where cloud startups found traction in 2020 included:

• Cloud security and zero-trust networking: As enterprise perimeters dissolved with remote work, demand for cloud-native security tooling surged.
• Data management and observability: Enterprises moving workloads to the cloud needed new ways to monitor, govern, and extract value from distributed data.
• Multi-cloud and hybrid cloud management: Few enterprises operated on a single cloud, driving demand for abstraction and orchestration layers.
• Developer tooling and CI/CD: Software delivery pipelines needed to scale rapidly to support remote engineering teams.
• Cloud cost optimization: As cloud bills grew quickly, FinOps and cost visibility tools became a priority for CFOs.

The Broader Context: A Decade of Cloud Investment Ahead

The mid-2020 analysis from Wedbush framed the pandemic not as a short-term demand spike but as an accelerant for a decade-long investment cycle. For DevOps engineers, platform teams, and infrastructure architects, this meant that architectural decisions made in 2020 — around containerization, Kubernetes adoption, serverless computing, and multi-cloud strategy — would have long-lasting consequences.

Cloud startups entering the market in 2020 were building against this backdrop: enterprises newly committed to cloud-first strategies, hyperscalers investing heavily in developer ecosystems, and a venture capital market still willing to fund ambitious infrastructure bets.

For a curated list of the specific startups identified by CRN as the hottest cloud companies to watch in mid-2020, refer to the original CRN coverage.

Key Takeaways for DevOps Teams

• The COVID-19 pandemic compressed enterprise cloud adoption timelines by one to two years relative to pre-pandemic projections.
• Cloud spending grew even as overall IT budgets contracted — a rare counter-cyclical dynamic that signaled structural demand rather than discretionary spending.
• Hyperscalers (AWS, Azure, Google Cloud) provided the foundation, but startups addressed specialized gaps across security, observability, cost management, and developer experience.
• Enterprises caught without cloud-ready infrastructure in 2020 faced immediate operational risk — a lesson that drove lasting changes in how organizations approach cloud strategy.
• The long-term investment thesis for cloud — framed around a trillion dollars in spending over the following decade — created a durable opportunity for well-positioned startups.

The Cloud Label Problem

“Cloud” has become one of the most overloaded terms in enterprise technology. Vendors routinely attach the label to solutions that are, in practice, little more than traditional hosted applications—your legacy software running on someone else’s server, with none of the architectural benefits that genuine cloud compute delivers. Before committing to any solution marketed as cloud, engineering and procurement teams should ask several pointed questions:

• Is this cloud or hosting? Has the vendor simply lifted an existing on-premises application into a data centre and made it accessible via a browser?
• Has the application been re-architected? Does it take advantage of elastic scaling, microservices, or cloud-native storage and compute primitives?
• Does the vendor have an agile development roadmap? Cloud-native platforms should deliver continuous, value-adding enhancements—not periodic monolithic upgrades.
• What are the actual total-cost and performance characteristics? A hosted legacy application may carry the same or greater operational overhead as the on-premises original.

Cloud adoption should be driven by pragmatism and due diligence, not by a mandate to move everything off-premises for its own sake. The right question is never “Can we put this in the cloud?” but rather “Does cloud compute provide a measurable advantage for this specific workload, security model, and user need?”

Where Cloud Migration Actually Stands

The first wave of cloud migration—moving straightforward, low-risk workloads—is largely complete. Estimates at the time of this analysis placed roughly 20% of enterprise compute in public cloud environments. What remains is a harder category: workloads that are more complex, more tightly coupled to on-premises systems, or subject to stricter compliance requirements.

These harder workloads are also, paradoxically, the ones most likely to generate meaningful business value once migrated successfully. The transition represents more than a technology change—it requires new operating models, new skills, and in many cases a genuine re-evaluation of application architecture. Some workloads will ultimately prove impractical or uneconomical to migrate, and new applications continue to be provisioned on-premises where that remains the appropriate choice.

Digital Transformation ≠ Wholesale Cloud Migration

A widespread misconception equates digital transformation with moving everything to the public cloud. This conflation carries real costs. According to data cited from an Everest Group survey, 73% of enterprises failed to deliver any measurable business value from their digital transformation efforts. While causation is difficult to isolate, a likely contributor is treating technology migration as an end in itself rather than as a means to improve processes, customer experiences, or competitive positioning.

A genuine transformation starts with identifying the target business outcomes and then selecting the appropriate technical form factor—cloud, hosted, or on-premises—to achieve them. The result is often a deliberate mix of all three, each serving the workloads it is best suited for.

Digital Distress Is a Real Competitive Risk

IDC projected that by 2020 a significant proportion of organisations would be either “digitally determined” (actively using technology to drive advantage) or “digitally distressed” (falling behind because of inadequate digitisation). The intervening years have borne this out: established brand names have struggled, been acquired, or exited markets, not because technology was unaffordable but because they failed to adapt to customer expectations for seamless, omnichannel digital experiences.

The barriers to effective digitisation are no longer primarily financial or technical. The determining factors are organisational: the willingness to change, the capability to execute, and the discipline to select the right platform for each use case while avoiding vendor lock-in that constrains future options.

Why Multi-Cloud Happened by Osmosis—and Why That’s Fine

Most enterprises did not architect a multi-cloud strategy from scratch. They arrived at it incrementally, as individual application choices drove platform selections—much the way mixed UNIX, Novell NetWare, LAN Manager, Windows NT, and VM environments emerged in earlier decades, each pulled into existence by the operating system requirements of the applications running on top of them.

Today, different SaaS and PaaS vendors offer varying levels of integration with AWS, Azure, Google Cloud, and other platforms. Choosing a single public cloud provider and constraining all future application decisions to that platform is increasingly impractical. The right cloud for a given application is determined by that application’s specific performance, compliance, integration, and geographic requirements—not by a top-down mandate.

Accepting multi-cloud as the default state removes a false constraint and lets teams optimise at the workload level. It does, however, introduce real operational challenges that must be addressed deliberately:

• Compliance and data sovereignty across providers with different certification scopes and regional footprints
• Skill set breadth required to operate competently across multiple cloud control planes and toolchains
• Consistent security posture when identity, network policy, and secrets management span disparate platforms
• Observability and monitoring across heterogeneous environments without gaps or duplicated tooling
• Cost visibility and optimisation when spend is distributed across multiple billing models

What the Forrester/IBM Research Found

The Forrester survey commissioned by IBM identified the primary drivers behind enterprise multi-cloud strategies:

• Higher application and infrastructure performance
• Flexibility to match workloads to the most appropriate platform
• Improved customer experience enabled by best-in-class services
• Ability to support rapid organisational change

The same research found that 39% of IT organisations reported a loss of competitive edge rather than a gain—a signal that cloud adoption without coherent strategy, skills investment, and architectural discipline can actively harm the business. The research also reinforced a point that many finance teams resist: delaying refresh and upgrade investments is not a saving. Deferred modernisation accumulates technical debt that ultimately costs more to resolve and imposes measurable drag on business performance in the interim.

Principles for a Workable Hybrid and Multi-Cloud Strategy

Based on the patterns described in the Forrester research and broader industry experience, effective hybrid and multi-cloud strategies share several characteristics:

1. Workload-first placement decisions. Evaluate each workload against the compute, security, compliance, latency, and integration requirements it actually has, then select the appropriate environment.
2. Portability as a design requirement. Architect applications to avoid deep dependency on proprietary platform APIs where the cost of that dependency exceeds its benefit. Containers and Kubernetes have become a common portability layer, though they introduce their own operational complexity.
3. Co-existence, not forced migration. Accept that a significant percentage of workloads will remain on-premises, and invest in the networking, identity, and management tooling that makes on-premises and cloud resources operate coherently together.
4. Centralised governance, decentralised execution. Standardise on security baselines, cost tagging, and compliance controls centrally, while allowing individual teams to choose cloud services that best serve their specific applications.
5. Skills investment as a first-order concern. Multi-cloud complexity compounds quickly without teams that understand the nuances of each platform. Training and hiring plans should be explicit components of any cloud strategy, not afterthoughts.

Conclusion

Hybrid and multi-cloud are not aspirational architecture patterns—they are the operational reality for most enterprises. The organisations that will gain competitive advantage are those that stop treating multi-cloud as a problem to be solved in favour of a single platform, and instead build the tooling, governance, and skills to operate heterogeneous environments well. Cloud adoption driven by genuine workload fit, with clear business outcomes attached, consistently outperforms adoption driven by the assumption that cloud is categorically better for everything.

The Forrester data is a useful reminder: technology investment without strategic clarity does not automatically translate to business value. The hard work—migrating complex workloads, upskilling teams, and building coherent multi-cloud operations—is where the real returns are found.

There’s no escaping it: to get ahead today, you need to have a hybrid, multi-cloud environment. Companies have long since noted the benefits of public cloud – and indeed, more than one public cloud for greater efficiency and optimisation. Yet it is not an easy process.

An entire industry, from consulting to monitoring, has grown around this complexity. Alongside this, some smaller IT providers see an opportunity. Comarch argues that when moving to the cloud, many organisations still could fall foul of hidden traps. CloudTech spoke with Ryszard Kluza (left), ICT business unit director at Comarch, to discuss the advantages of local service providers, issues with migration, and how Covid-19 is ramping up demand for cloud services.

CloudTech: Tell us about your role and responsibilities at Comarch?

Ryszard Kluza: At Comarch I am the BU ICT director, responsible for businesses related to cloud services (IaaS, PaaS), power cloud, hosting services provided from 20 data centres worldwide, and IT outsourcing services.

CT: What are customers telling you about the problems they are seeing with regards to their cloud migrations – and how can Comarch help them in this regard?

RK: Cloud solutions are the inevitable future of IT, but clients are very often afraid of becoming even more dependent on big IT corporations how it used to be with a let’s say “traditional” IT vendors. They do not want to wake up in a few years in a world where there are only a few global players which are still dictating constantly rising prices.

Comarch could be seen as an alternative, providing, in addition to their own developed cloud services, a hybrid multi-cloud solution where there is no risk of vendor lock-in. As a smaller provider, we are able to be closer to the client and better understand their challenges and problems while still offering world-class solutions. We can tailor our offer to each client’s specific requirements, which is rather difficult for big players.

CT: What challenges remain for businesses when they are looking to cloud migration, both from a technical and a business perspective?

RK: Transition to the cloud involves a huge change in mentality, as well in the business as in technological aspects.

Companies should carefully assess transition pros and cons, and answer simple questions about whether or not it is worth moving to the cloud. On the one hand, they could lower investments costs (CAPEX) and move their teams to develop and support the core business, because engineers would no longer have to deal with operational work related to the platform. On the other hand, business can become increasingly dependent on an external provider. Important questions to be asked should focus on whether quoted prices at the very beginning will still be valid in the long term, they might rise quickly (and if so, it is key to assess how quickly). Businesses considering a move to the cloud should also ensure that their teams can exercise restraint when faced with seemingly “unlimited” resources from their cloud provider.

From a technological perspective, companies have to analyse whether or not their existing solutions are compatible with cloud technology, and whether they have appropriate knowledge and the required competences to manage IT in the cloud. What about security? The cloud is a shared environment, so how to secure access to the systems on a remote platform? What guarantees are there that, in the event of any failure, the organisation’s administrators still have an access to IT systems placed in the cloud to support the core business?

Going into the cloud involves a change of IT teams’ philosophy in terms of supporting business. On one hand, the cloud offers easy, unlimited access to resources, but on the other there is still uncertainty about whether such easy access will be very costly in the near future if the wrong solution is chosen?.

However business answer these questions and address these challenges, they must remember that a shift to the cloud is inevitable.

CT: Do you agree that organisations go into migration plans without the requisite knowledge of cloud providers, business plans, and technical demands? What advice would you give to companies who are worried about making the wrong decision, vendor lock-in, etc?

RK: Recently, the cloud and associated services were among the most common topics of discussion the IT world. There is incredible pressure on management boards, CIOs and IT managers, especially those who do not yet have IT in the cloud, because maybe this means that they are not managing their enterprise’s IT optimally. This often leads to a rush to move IT systems to the cloud without proper preparation or detailed analysis. The worst thing is when an organisation lacks adequate technological competences and is unable to grasp a deep understanding of cloud vendors’ offers. A proposal may look good, but the first invoice might itemise many unknown items and prove rather expensive. I advise companies to make a considerable effort to understand the various offers on the market, choose multi-cloud strategies without vendor lock-in, and continuously assess cloud providers – none of which should prove a big deal.

CT: What impact has the Covid-19 pandemic had – or will have – on demand for cloud services? What effect is the widespread implementation of remote working having on both cloud software, but also cloud security?

RK: The situation with Covid-19 seems to have had a significant influence on the decision of boards of enterprises about putting IT systems into the cloud. Obligations on employers to allow their staff to work remotely have shown how important remote, secure access to IT systems really is. Not every company has reliable, secure and efficient network infrastructure ready to handle increased network traffic and secure remote work. Cloud providers are specialised companies which have reliable and secure systems as well as competent teams of engineers who can react rapidly to support clients with any problems they may encounter.

This is why, I believe, the situation with Covid-19 will accelerate movement towards the cloud and demand for cloud services.

CT: What cloud trends should companies be looking for during the rest of 2020 and into 2021 in your opinion?

RK: There are many cloud providers on the market, ranging from global players to local operators acting regionally. Going into the cloud is inevitable, but companies will want to avoid vendor lock-in and will choose multi-cloud solutions, to reduce the risk of becoming dependent on a single provider. This is why there is a place on the market for many smaller cloud service providers. Similar to traditional IT, clients are now buying hardware, software and services from many vendors and providers, to avoid such dependency and in order to optimise costs.

Containers and Cloud: A Natural Partnership

Containers have become a cornerstone of modern application development and deployment. Their value proposition is well understood: they package an application and its dependencies into a portable unit that can run consistently across development laptops, on-premises servers, and multiple cloud environments. This portability is especially important as enterprises pursue hybrid and multi-cloud strategies, moving workloads between providers or between cloud and on-premises infrastructure without costly re-engineering.

But building and operating a mature containerized environment at scale is not trivial. It requires specialized expertise in orchestration, networking, storage, security, and CI/CD pipelines. That skills gap has created real friction for organizations that want the benefits of containers without investing heavily in building internal platform teams from scratch.

What Is Containers-as-a-Service (CaaS)?

Containers-as-a-Service (CaaS) is a managed cloud service model that abstracts the underlying infrastructure required to run containers. Rather than provisioning and maintaining the orchestration layer — including the control plane, node management, networking, and storage — organizations consume these capabilities as a managed service from a cloud provider or platform vendor.

CaaS sits between Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS). Users retain significant control over how their containers are configured and deployed, but they offload operational responsibility for the underlying container runtime and orchestration platform. In practice, this usually means a managed Kubernetes service, a managed Docker environment, or both.

Common CaaS offerings from major cloud providers include:

• AWS Elastic Container Service (ECS) and Elastic Kubernetes Service (EKS)
• Azure Kubernetes Service (AKS)
• Google Kubernetes Engine (GKE)

CaaS Adoption Is Rising Fast

According to the Flexera 2020 State of the Cloud Report, CaaS is no longer a niche offering. Among the 750 IT executives surveyed, 53 percent reported using CaaS — placing it as the second-ranked PaaS category in use among cloud-driven enterprises, up from sixth place the previous year. Only Database-as-a-Service ranked higher, used by 62 percent of respondents.

In terms of year-over-year growth, CaaS ranked second among the fastest-growing cloud technologies, with 17 percent annual growth — just behind IoT services at 21 percent and level with machine learning and AI services.

Adoption of specific CaaS products reflects this trend:

• AWS ECS/EKS: 54 percent adoption (up from 44 percent the prior year), with another 24 percent planning adoption.
• Azure Container Service: 46 percent adoption (up from 28 percent).
• Google Kubernetes Engine: 24 percent adoption (up from 15 percent).

The survey authors attribute this acceleration to organizations’ growing interest in leveraging containers to speed deployment, scale operations, and increase workload efficiency in the cloud.

Why CaaS Matters: Balancing Speed and Control

One of the key value propositions of CaaS is that it preserves developer and operations control over container configuration while reducing the burden of managing the platform itself. As noted in an overview by Eric Olsson at Scalyr, the evolution toward containers is part of a broader acceleration in software delivery:

“Agile methodologies shortened the development and testing pieces while cloud computing has shortened the deployment piece. Continuous integration (CI) and continuous delivery (CD) further improved the time it takes to get a feature to customers. In addition to these, containers can give you a more powerful and flexible solution. But with all these pieces come additional configuration and complexity.”

Eric Olsson, Scalyr

CaaS helps manage that added complexity by delivering a pre-integrated platform for container orchestration, allowing teams to focus on writing and shipping software rather than maintaining Kubernetes clusters.

Key Challenges Slowing Container Adoption

Despite growing adoption, the Flexera survey identified several significant barriers that organizations still face when working with containers:

• Lack of internal expertise: Cited as a major challenge by 41 percent of respondents, with another 38 percent calling it a moderate challenge. Container orchestration, security, and networking require skills that many teams are still building.
• Migrating traditional applications: 34 percent identified this as a major issue. Containers are optimized for microservices architectures, while many existing enterprise applications are monolithic and were not designed with container portability in mind. Retrofitting these applications requires significant refactoring effort.
• Security concerns: Also cited as a major challenge by 34 percent. Container security encompasses image scanning, runtime protection, secrets management, and network policy — all areas requiring deliberate investment.
• Provider expertise gaps: More than one in four respondents (26 percent) noted that even their service providers lack sufficient expertise in container technology, suggesting that the ecosystem as a whole is still maturing.

The survey authors note that these challenges largely reflect the relative recency of widespread container adoption. As the tooling, training, and managed service options mature, many of these barriers are expected to lower.

Docker and Kubernetes Remain the Foundation

Underlying most containerization efforts are two technologies that have become de facto standards in the industry. According to the Flexera 2020 survey:

• Docker: Used by 65 percent of organizations surveyed, with another 14 percent planning adoption. Docker remains the dominant container runtime and image format.
• Kubernetes: Used by 58 percent of organizations, with 22 percent planning to adopt it. Kubernetes has become the leading container orchestration platform, and most CaaS offerings — including EKS, AKS, and GKE — are built on top of it.

The widespread use of these open-source technologies means that organizations investing in CaaS today are building on a well-supported, vendor-neutral foundation, which reduces lock-in risk compared with proprietary PaaS platforms.

Is CaaS the Right Choice for Your Organization?

CaaS is not a universal solution, but it is a pragmatic one for many organizations. Teams that are beginning their container journey and do not yet have deep Kubernetes expertise can use a managed CaaS offering to get running quickly, then build operational knowledge progressively. Organizations with strong platform engineering teams may prefer more control over their Kubernetes deployment, running self-managed clusters on IaaS infrastructure.

For enterprises running hybrid or multi-cloud workloads, CaaS offerings can also provide a consistent developer experience across environments — particularly when combined with tools like Helm, Terraform, or GitOps workflows that standardize deployments across providers.

The central question is not whether to use containers — at this point, the industry trend is clear — but how much of the operational platform you want to manage yourself versus delegate to a cloud provider. CaaS represents a sensible middle path for most enterprises: enough abstraction to reduce operational burden, enough control to maintain flexibility.

Conclusion

Containers have moved from an advanced practice to a mainstream enterprise requirement, and CaaS is emerging as the practical delivery mechanism for organizations that want container benefits without standing up their own orchestration infrastructure. Adoption data from the Flexera 2020 State of the Cloud Report confirms that CaaS is growing rapidly, driven by real demand across enterprises of all sizes. Challenges around expertise and application migration remain, but the managed service model is helping lower the barrier to entry — and that trend is likely to continue as Docker, Kubernetes, and the broader cloud-native ecosystem continue to mature.

What Is ksqlDB?

ksqlDB (previously marketed as KSQL) is the streaming SQL engine built on top of Apache Kafka. It lets developers write continuous SQL queries against Kafka topics without writing Java or Scala code, making real-time stream processing accessible to a much broader engineering audience. Common use cases include:

• Stream-to-stream joins — correlate events from two or more Kafka topics in real time.
• Aggregations — compute rolling counts, sums, or averages over time windows.
• Transformations and filtering — reshape, enrich, or drop events as they flow through a pipeline.
• Data enrichment — look up reference data stored in ksqlDB tables and join it with live streams.

Queries run on the ksqlDB Server engine, which handles all reads and writes to and from the underlying Kafka cluster. Developers interact with the engine either through a SQL query editor in the Confluent Control Center UI or directly via the ksqlDB REST API.

General Availability on Confluent Cloud

Confluent announced that ksqlDB moved from preview to production-ready status on Confluent Cloud, available to all customers on usage-based billing plans. The managed service removes the operational overhead of deploying and scaling ksqlDB Server clusters yourself. As Derek Nelson, senior product manager at Confluent, explained at the time of the announcement:

Confluent Cloud ksqlDB eliminates the innate complexities of operating infrastructure in production. We take care of running production-grade infrastructure at scale while you focus on solving business problems with ksqlDB. Transformations, stream-to-stream joins, aggregations, and data enrichment can all be accomplished using ksqlDB with just a few lines of SQL.

Derek Nelson, Senior Product Manager, Confluent

Dan Rosanova, senior group product manager at Confluent, also highlighted ksqlDB’s broader role in the platform when speaking to InfoQ:

ksqlDB is really a new kind of database that has been purpose-built for stream processing applications. We see ksqlDB as an integral service rounding out our cloud offering as a complete streaming platform, beyond Kafka, enabling end-to-end stream processing workloads. It complements our Connect service as well, which enables streaming connectivity to and from many services and platforms. These services all compose together to provide users an event streaming SaaS that they can use to build and run sophisticated and complete modern applications.

Dan Rosanova, Senior Group Product Manager, Confluent

Key Capabilities of the Managed ksqlDB Service

Running ksqlDB as a managed service on Confluent Cloud offers several advantages over self-hosting:

• No infrastructure management — Confluent provisions, scales, and monitors the ksqlDB cluster on your behalf.
• Integrated UI — The Confluent Control Center provides a graphical interface to create streams and tables, browse schemas, and submit continuous queries without leaving the browser.
• REST API access — All operations available in the UI are also available programmatically via the ksqlDB REST API, enabling CI/CD integration.
• Schema Registry integration — Streams and tables are schema-aware, enabling safer evolution of event formats over time.
• Kafka Connect complement — Confluent Cloud Connect can source or sink data to external systems, with ksqlDB handling in-flight transformations in between.

Multi-Cloud Support

Confluent Cloud — and by extension the managed ksqlDB service — is available on all three major public cloud providers:

• Amazon Web Services (AWS) — available since 2017.
• Google Cloud Platform (GCP) — available via the GCP Marketplace.
• Microsoft Azure — available via the Azure Marketplace.

This multi-cloud availability means teams can run ksqlDB workloads in the same region and cloud provider as the rest of their data infrastructure, minimising egress costs and latency.

A Practical Example: Streaming Data Pipeline

A common pattern is using Apache Kafka as the backbone of a data pipeline and ksqlDB to transform events before landing them in a downstream system (a data warehouse, search index, or operational database). Instead of writing a custom Kafka Streams application in Java, a developer can express the same logic in SQL:

-- Create a stream from a raw Kafka topic
CREATE STREAM orders_raw (
  order_id VARCHAR,
  customer_id VARCHAR,
  amount DOUBLE,
  currency VARCHAR
) WITH (
  KAFKA_TOPIC='orders',
  VALUE_FORMAT='JSON'
);

-- Filter and enrich: only USD orders above $100
CREATE STREAM high_value_usd_orders AS
  SELECT
    order_id,
    customer_id,
    amount,
    UCASE(currency) AS currency
  FROM orders_raw
  WHERE currency = 'USD' AND amount > 100
EMIT CHANGES;

The resulting high_value_usd_orders stream is itself a Kafka topic, ready to be consumed by downstream services or sinked to an external system via Kafka Connect.

Who Benefits Most?

As Bart Kersteter, a systems engineer at Confluent, noted at the time of the announcement, ksqlDB is particularly valuable for teams that need real-time stream processing but do not have deep JVM expertise:

KSQL is great for writing streaming data apps, especially for non-Java programmers. It is now fully supported and available in Confluent Cloud.

Bart Kersteter, Systems Engineer, Confluent

Data engineers already comfortable with SQL for batch processing can apply the same mental model to streaming workloads, significantly reducing the learning curve compared to the Kafka Streams DSL or Apache Flink.

Getting Started

To try the managed ksqlDB service on Confluent Cloud:

1. Sign up for a Confluent Cloud account at confluent.io/confluent-cloud.
2. Create a Kafka cluster in your preferred cloud region (AWS, GCP, or Azure).
3. Add a ksqlDB application from the Confluent Cloud console.
4. Use the built-in query editor to create your first stream and run a continuous SQL query.
5. Explore the official Confluent Cloud ksqlDB documentation for deeper configuration options.

Note: Pricing details and free-tier offers mentioned at the time of this announcement (April 2020) may have changed. Check the Confluent Cloud pricing page for current information.

Cloud Computing’s Defining Moment

If any single event demonstrated the strategic value of cloud computing, it was the COVID-19 pandemic. As economies worldwide contracted sharply in early 2020, the major cloud providers—Amazon Web Services (AWS), Microsoft Azure, and Google Cloud—found themselves at the center of a demand surge driven by remote work, online education, video conferencing, e-commerce, and digital collaboration.

That demand translated directly into hiring activity at a time when most industries were cutting headcount. For DevOps engineers, cloud architects, and software developers, this represented one of the more unusual job markets in recent memory: a recession paired with strong demand for technical cloud talent.

Why Cloud Demand Spiked

The logic was straightforward. Lockdowns, remote-work mandates, and school closures pushed an enormous share of daily activity onto digital infrastructure almost overnight. Services that had been growing steadily—video conferencing, cloud storage, SaaS collaboration tools, streaming, and e-commerce—saw compressed years of growth happen in weeks.

Financial analysis firm Zacks summarized the dynamic in an April 2020 article:

“In the battle against the pandemic, when mass gatherings are strictly restricted and people are being increasingly told to work from home, cloud computing companies have come to the rescue. Amid strict lockdown measures, there has been heightened demand for online classes, video conferencing, gaming, e-commerce shopping and remote project collaboration.”

Zacks, April 2020

The Wall Street Journal described cloud providers as “among the few corporate winners in the coronavirus pandemic,” noting that their remote data storage and processing services had become “the essential link for many people to remain connected with work and families.”

Amazon Web Services: Broad Hiring Across Roles

AWS was openly recruiting across a wide range of technical and business functions during the pandemic. An AWS hiring notice at the time listed open roles including:

• Software Development Engineers
• Solutions Architects
• Support Engineers
• System Engineers
• Product Managers
• Account Managers
• Designers

AWS’s parent company, Amazon, also announced a major operational hiring push. A March 16, 2020 post on Amazon’s COVID-19 blog stated the company was hiring 100,000 new full- and part-time employees across U.S. fulfillment centers and its delivery network to meet surging e-commerce demand. Amazon specifically encouraged workers displaced from the hospitality, restaurant, and travel sectors to apply.

Microsoft Azure: Strategic Hiring Amid a Partial Freeze

Microsoft’s approach was more nuanced. In April 2020, the company confirmed it was temporarily pausing recruitment for some roles due to COVID-19 uncertainty, while continuing to hire in what it described as “strategic areas.”

“We continue to seek industry-leading talent in a range of disciplines as we continue to invest in certain strategic areas. However, in light of the uncertainties presented by COVID-19, we are temporarily pausing recruitment for other roles.”

Microsoft spokesperson, reported by Business Insider, April 2020

Microsoft declined to specify which roles were paused or which remained active. However, reporting from Business Insider and Forbes indicated that Azure was clearly one of those strategic areas. According to employees who spoke with Business Insider, Microsoft continued hiring for its cloud computing business and was holding virtual hiring events for software engineers.

A Forbes analysis from April 8, 2020 noted that Microsoft—which employed approximately 150,000 people as of 2019—still listed over 7,000 open positions on LinkedIn at that time, with more than 4,000 of those roles mentioning Azure.

Google Cloud: Active Recruiting Across Specializations

Google Cloud maintained its “We’re Hiring. Join Google Cloud!” recruiting push throughout the early pandemic period. Open roles included positions in:

• Cloud Software Engineering (e.g., Cloud SQL, Cloud Health and Life Sciences)
• Cloud Product Management
• Cloud Consulting
• People Analytics (e.g., Reporting and Insights, Cloud)
• Enterprise Architecture (e.g., Healthcare-focused Cloud Architect roles)

These listings appeared both on Google’s own careers site and on LinkedIn, suggesting an active and updated pipeline rather than stale postings.

IBM Cloud: Leadership Changes Rather Than Mass Hiring

IBM, whose cloud platform is often grouped with the “Big 3” hyperscalers, took a different approach. Rather than announcing broad hiring campaigns, IBM made targeted leadership appointments to strengthen its hybrid cloud strategy. Network World reported on these moves in an April 2020 article titled “IBM taps new leaders for hybrid-cloud battles ahead,” signaling a focus on strategic positioning rather than rapid headcount growth.

The Broader Cloud Job Market

Hiring activity extended well beyond the cloud hyperscalers themselves. Cloud-adjacent companies and organizations with cloud infrastructure needs also continued recruiting technical staff. The tech careers platform Dice noted in April 2020:

“Across the country, the need for remote work and social distancing is boosting demand for technologists who can provide everything from e-commerce portals to maintaining cloud architecture. The COVID-19 crisis still has some time to run, but for the technology industry, some of the early signals around job demand are surprisingly promising.”

Dice, April 2020

This reflected a broader pattern: while many industries were shedding workers rapidly, cloud infrastructure, DevOps, and platform engineering roles remained in demand as organizations scrambled to support remote operations at scale.

Key Takeaways for Cloud and DevOps Professionals

• Cloud infrastructure skills were recession-resistant during the early pandemic period, even as broader tech hiring slowed.
• AWS, Azure, and Google Cloud all maintained active hiring, though with different strategies—AWS broadly, Azure selectively, and Google consistently.
• Hybrid and multi-cloud roles were particularly valued, as enterprises needed to scale quickly across multiple platforms.
• Adjacent roles—such as cloud security, cloud architecture, and DevOps engineering—also saw continued demand beyond the hyperscalers themselves.
• Virtual hiring became the norm, with companies like Microsoft running online hiring events for engineering candidates.

The pandemic-era cloud hiring surge underscored a structural shift already underway: cloud infrastructure had moved from a cost-optimization strategy to a business-continuity necessity, and the engineers who could build and operate it remained in short supply regardless of macroeconomic conditions.

Remote Work Demand Surged — But VMware Was Cutting Staff

The COVID-19 pandemic and the resulting shelter-in-place orders triggered an extraordinary spike in demand for remote work and cloud infrastructure tools. Videoconferencing platforms like Zoom and Cisco Webex saw usage climb dramatically, with Zoom reportedly seeing a roughly 300% increase in usage at the height of early lockdowns. Microsoft reported a significant surge in Azure cloud demand as organisations scrambled to support distributed workforces.

Against that backdrop, the timing of VMware’s apparent workforce reduction stood out. According to sources who contacted Thinknum Media directly, VMware conducted a quiet round of layoffs beginning in February 2020 — weeks before global lockdowns fully took hold. That reporting was supported by a visible drop in the number of LinkedIn users listing VMware as their employer, tracked by Thinknum’s data monitoring tools.

What the Data Showed

Thinknum, which tracks publicly available online data including job listings and LinkedIn employer counts, observed the following sequence of events:

• March 13, 2020: VMware showed approximately 28,530 employees listing the company on LinkedIn.
• March 21, 2020: A measurable drop in that employee count was recorded — suggesting departures had already occurred or were being reflected in profile updates.
• Early February 2020: Multiple former VMware employees contacted Thinknum to report they had been laid off, predating widespread pandemic-related disruption in the US.

It is worth noting that LinkedIn-derived employee counts are an indirect proxy for headcount, not official HR figures. Employees update their profiles at different times, so the data reflects a lagging and incomplete signal rather than a precise record of layoffs.

Financial Pressure and Withdrawn Guidance

VMware’s workforce reduction did not occur in a financial vacuum. The company had seen its share price fall approximately 14.7% since its previous earnings report, according to the Thinknum report. Then, on March 26, 2020, VMware took the significant step of withdrawing its Q1 and full fiscal year 2021 financial guidance.

In the guidance withdrawal, VMware stated:

“As described in the risk factors contained in VMware’s annual report on Form 10-K filed on March 26, 2020, VMware is unable to predict the extent to which the global COVID-19 pandemic may adversely impact its business operations, financial performance, and results of operations.”

This kind of guidance withdrawal is a meaningful signal. For a publicly traded company to pull forward-looking projections entirely — rather than revise them downward — indicates genuine uncertainty about near-term demand, deal closures, and enterprise spending patterns.

Why VMware’s Position Was Paradoxical

VMware occupies an interesting position in the enterprise technology landscape. Its core products — including vSphere for server virtualisation, NSX for network virtualisation, and Workspace ONE for unified endpoint management and remote access — are precisely the kinds of tools that organisations need when rapidly deploying remote work infrastructure.

CEO Pat Gelsinger acknowledged this directly in a statement posted to the company’s website at the time:

“At a time when ‘business as usual’ is not an option, we need to focus on helping each other, and assisting our customers as they respond and adapt. We have the capabilities to help customers across the globe enable their employees to work remotely, maintain productivity, increase connectivity, and provide for continuous secure access to applications regardless of the endpoint.”

— Pat Gelsinger, CEO, VMware (March 2020)

The tension is clear: VMware’s product portfolio was well-positioned for a remote work surge, yet the company had simultaneously reduced headcount during a period when that demand was accelerating. One interpretation is that the February layoffs reflected a strategic restructuring or performance management cycle that predated the pandemic’s full impact, rather than a direct response to it.

Possible Explanations

Several factors may explain the apparent contradiction between VMware’s market opportunity and its workforce reduction:

• A soft 2019: Enterprise technology companies frequently carry out annual workforce adjustments tied to the previous year’s performance. A softer-than-expected fiscal 2019 could have triggered restructuring decisions made well before COVID-19 became a dominant concern.
• Enterprise deal cycles: Even if VMware’s products were in demand, large enterprise deals were likely being delayed or cancelled as customers froze discretionary IT spending in the immediate chaos of early lockdowns — reducing near-term revenue visibility.
• Cost management ahead of uncertainty: Withdrawing financial guidance and reducing headcount simultaneously can signal that leadership was prioritising cost control as a buffer against an unpredictable demand environment.
• Role-specific cuts: Layoffs are rarely uniform across an organisation. It is possible that sales or administrative roles were reduced while engineering and support functions supporting remote access products remained intact or grew.

Context: How Thinknum Tracks This Data

Thinknum Media specialises in tracking alternative data derived from publicly available online sources, including job postings, LinkedIn employer listings, app store ratings, and web traffic. Its methodology provides directional signals about hiring and workforce trends, but as Thinknum itself acknowledges, the data sets are not fully comprehensive — they reflect only what is available and updated on the web at any given moment.

Employee count drops on LinkedIn can result from layoffs, voluntary departures, retirement, or employees simply updating their profiles belatedly. Interpreting these drops requires cross-referencing with other signals, such as direct source reporting — which Thinknum also incorporated in this case.

Key Takeaways for DevOps and Infrastructure Teams

For engineering and DevOps professionals who depend on VMware products, the broader lesson from this period is about vendor financial health and its operational implications:

• Monitor vendor guidance withdrawals: When a core infrastructure vendor pulls financial guidance, it can be an early signal of support resource constraints or shifts in product investment priorities.
• Assess workforce signals: Large, unexpected workforce reductions at a key vendor can affect support quality, product release cadences, and professional services availability.
• Understand the paradox of platform companies during disruption: A company can have the right product for a crisis and still face financial turbulence if enterprise deal cycles freeze or if its cost base is misaligned with near-term revenue.

VMware remained a dominant force in enterprise virtualisation and cloud infrastructure well beyond the initial pandemic period, and its subsequent acquisition by Broadcom in 2023 significantly changed its commercial and licensing structure. The events of early 2020 serve as a useful case study in how even well-positioned infrastructure vendors can face short-term turbulence during periods of macroeconomic disruption.

What Does a Cloud Architect Actually Need to Know?

Cloud architect is one of the most in-demand roles in modern IT, but the required skill set is broad and continues to shift. The specific technologies you need will depend on your organization’s cloud stack, but a strong foundation across networking, security, software development, and communication will serve you in almost any environment. Certification programmes through platforms like edX, the Linux Foundation, and major cloud vendors can help fill gaps — both free and paid options exist.

Below are ten skills consistently cited as essential for cloud architects, drawing on input from practitioners and hiring managers in the field.

1. Network Engineering and Administration

Many cloud architects start out as network or systems administrators. According to Dan Kohn, former executive director of the Cloud Native Computing Foundation (CNCF), the most common entry path is through system administration:

“The most typical background is someone who is familiar with system administration, who knows how to provision individual servers and then moves up and begins thinking in terms of fleets of servers instead.”

Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Hands-on experience deploying and operating different network types — including software-defined networking (SDN) — is foundational. Understanding how traffic flows, how to design resilient topologies, and how to troubleshoot at scale translates directly to cloud architecture work.

2. Containers: Kubernetes and Docker

Containers have become a core building block of modern cloud infrastructure. Docker provides the container runtime and image format, while Kubernetes has emerged as the dominant platform for orchestrating containerised workloads at scale. Proficiency in both is now close to a baseline expectation for cloud architect roles rather than a differentiator.

The CNCF maintains a landscape of cloud-native projects, and the Kubernetes.io site lists educational resources for getting up to speed. Docker’s official documentation is similarly comprehensive for learning container fundamentals.

3. Programming Languages

Cloud architects are not always expected to be full-time software developers, but being able to read, write, and debug code is critical. Widely useful languages in cloud contexts include:

• Python — dominant in automation, scripting, and infrastructure-as-code tooling
• Java — prevalent in enterprise application back-ends running on cloud infrastructure
• Go — the language in which Docker and Kubernetes are written; increasingly valued for cloud-native tooling
• C# — relevant in Microsoft Azure-heavy environments
• Perl — still present in legacy automation and operations scripting

Kohn specifically recommends familiarity with Go given how central it is to the Kubernetes ecosystem.

4. Security

Security is no longer a bolt-on concern — it is a core architectural responsibility. As regulatory requirements such as GDPR, HIPAA, and SOC 2 tighten, cloud architects are expected to design with security built in from the start, even in organisations that also employ a dedicated cloud security architect.

Key areas to develop include:

• Identity and access management (IAM) — controlling who can access what, across services and accounts
• Network security — firewalls, security groups, private networking, zero-trust models
• Data encryption — at rest and in transit
• Compliance and privacy regulations — understanding the rules that govern where and how data is stored
• Shared responsibility models — knowing what the cloud provider secures versus what you own

5. Multi-Cloud and Hybrid Cloud Architecture

Most large enterprises do not run a single cloud provider. Acquisitions, regulatory requirements, cost optimisation, and vendor risk management all push organisations toward multi-cloud or hybrid cloud strategies. Kohn makes a direct case for breadth over specialism:

“There’s a huge level of interest and demand for multi-cloud and hybrid cloud. I would really encourage people to have at least a passing familiarity with the other major clouds. And the reality is bigger enterprises tend to have acquisitions, so you wind up with a multi-cloud strategy almost by default, whether you’re planning to or not.”

Dan Kohn, former Executive Director, Cloud Native Computing Foundation

While deep expertise in one platform (AWS, Azure, or Google Cloud) is valuable, architects who can reason across providers and design portable, cloud-agnostic solutions are increasingly sought after.

6. Data Storage

Data storage in cloud environments spans a wider surface than traditional on-premises storage. Cloud architects need to understand:

• Object storage (e.g., S3-compatible buckets), block storage, and file storage — and when to use each
• Capacity planning and cost optimisation for storage at scale
• Data lifecycle management, tiering, and archival
• Data security, encryption, and access control at the storage layer
• On-premises storage hardware, particularly relevant for hybrid cloud designs

7. Communication Skills

Cloud architects routinely need to explain complex infrastructure decisions to non-technical stakeholders — executives, finance teams, legal, and end users. Jim Johnson, senior VP at Robert Half Technology, puts it plainly:

“Being able to articulate to a CIO the impact [of the cloud] … communication is a key piece of that. And so to cultivate that, you need to talk to the users about what you’re providing. [You need to] check for understanding and make sure that you’re not talking over or talking under those individuals… about how well your services or your current environment are supporting them.”

Jim Johnson, Senior VP, Robert Half Technology

Practical communication skills include writing clear architecture decision records (ADRs), presenting trade-offs concisely in diagrams and documents, and running effective stakeholder meetings.

8. Teamwork and Leadership

Cloud architects frequently serve as technical leads or principal engineers on multi-disciplinary teams. The role requires the ability to:

• Facilitate technical decision-making without steamrolling contributors
• Delegate effectively and trust team members to execute
• Manage competing priorities and resolve disagreements constructively
• Mentor junior engineers and help grow the team’s overall capability

Johnson advises developing leadership skills early and deliberately, not waiting until you are in a senior role to start practising them.

9. Flexibility and Continuous Learning

Cloud technology evolves faster than most engineering disciplines. Tools, services, and best practices that were cutting-edge two years ago can become obsolete or superseded. Kohn is direct about this reality:

“The specific skill sets in need are going to evolve over time. I think there are tons and tons of opportunities in the cloud. And it is an ongoing effort. It’s not going to stay static.”

Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Building habits around staying current — following project release notes, attending community events, experimenting in personal lab environments, and earning updated certifications — is as important as any specific technical skill.

10. Business Acumen

Cloud architecture decisions have direct financial consequences. Choosing the wrong instance type, region, or storage class can meaningfully affect an organisation’s operating costs. Architects who understand how business value is created and measured can make better trade-offs and advocate more effectively for investment.

Johnson recommends supplementing technical education with formal or informal business training:

“Part of that might be a minor in business, or maybe even accounting to understand how the financials and numbers help drive businesses as well. But [it should be] anything that gives you that exposure to what it takes to drive business, create a business, and run a business, with that technology understanding.”

Jim Johnson, Senior VP, Robert Half Technology

FinOps practices — optimising cloud spend and aligning it to business outcomes — are an increasingly valued specialism that sits squarely at the intersection of cloud architecture and business acumen.

Building Your Cloud Architect Skill Set

No single engineer will be an expert in all ten of these areas simultaneously. The most effective approach is to build genuine depth in two or three domains — typically networking, a specific cloud platform, and security — while maintaining working knowledge across the rest. Pair that foundation with deliberate investment in communication and leadership skills, and you will be well positioned for a cloud architect career as the role continues to evolve.

1. Network Engineering and Administration

Most cloud architects come from a network or systems administration background. Dan Kohn described the common career path this way:

“The most typical background is someone who is familiar with system administration, who knows how to provision individual servers and then moves up and begins thinking in terms of fleets of servers instead.”

— Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Solid knowledge of deploying and operating different network types — including software-defined networking (SDN) — is fundamental. Understanding how traffic flows, how to design fault-tolerant topologies, and how to troubleshoot connectivity problems at scale gives cloud architects the grounding to make sound infrastructure decisions.

2. Kubernetes and Docker

Containers have become a standard building block of modern cloud infrastructure. Docker provides the container runtime and image format, while Kubernetes handles orchestration — scheduling, scaling, self-healing, and service discovery across clusters. Demand for Kubernetes expertise has grown sharply in recent years, making it one of the most marketable skills a cloud architect can hold.

Practical competencies to develop include:

• Writing Dockerfiles and building optimized container images
• Deploying and managing Kubernetes clusters (self-managed and managed services such as EKS, GKE, and AKS)
• Configuring Kubernetes networking, storage, RBAC, and namespaces
• Using Helm for application packaging and deployment
• Monitoring cluster health and setting up autoscaling policies

3. Programming Languages

Cloud architects do not need to be full-time software developers, but being comfortable with at least one or two languages is essential for scripting automation, reviewing infrastructure-as-code, and understanding cloud-native applications. Widely applicable languages include:

• Python — the de facto scripting language for cloud automation, SDK integration, and data pipelines
• Java — heavily used in enterprise microservices
• Go — the language in which Docker and Kubernetes themselves are written; increasingly relevant for cloud tooling
• C# — important in Azure-heavy environments
• Bash / PowerShell — essential for day-to-day automation and CI/CD pipeline scripting

Dan Kohn specifically recommends Go for architects who want to contribute to or deeply understand the Kubernetes ecosystem.

4. Cloud Security

Security has shifted from a bolt-on concern to a foundational design requirement. As data privacy regulations expand globally, cloud architects are expected to build security into every layer of the stack rather than leaving it to a separate team. Key areas include:

• Identity and Access Management (IAM) — least-privilege policies, role-based access, service accounts
• Network security — security groups, VPC design, private endpoints, zero-trust architectures
• Data encryption — at rest and in transit, key management services
• Compliance awareness — familiarity with frameworks such as GDPR, HIPAA, SOC 2, and PCI-DSS as they apply to cloud workloads
• Vulnerability management — container image scanning, dependency auditing, and patch management at scale

5. Multi-Cloud and Hybrid Cloud Architecture

While deep expertise in a single cloud platform (AWS, Azure, or GCP) is valuable, limiting yourself to one provider is increasingly a career risk. Large enterprises often end up with a multi-cloud environment not by design but by acquisition — each acquired company brings its own cloud infrastructure.

“There’s a huge level of interest and demand for multi-cloud and hybrid cloud. I would really encourage people to have at least a passing familiarity with the other major clouds. The reality with bigger enterprises is that you tend to have acquisitions, so you wind up with a multi-cloud strategy almost by default, whether you’re planning to or not.”

— Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Architects should understand how to design portable workloads, manage cross-cloud networking and identity federation, and apply governance policies consistently across providers. Tools such as Terraform, Crossplane, and cloud-agnostic monitoring solutions support this approach.

6. Data Storage and Management

Data is at the heart of cloud architecture. Architects need to match storage solutions to workload requirements — balancing cost, latency, durability, and compliance. Core knowledge areas include:

• Object storage (S3-compatible buckets), block storage, and file storage — and when to use each
• Database selection: relational, NoSQL, time-series, and data warehouse options
• Capacity planning and cost optimization (storage tiers, lifecycle policies)
• Data residency and sovereignty requirements for regulated industries
• Backup, replication, and disaster recovery strategies

For architects working with on-premises or hybrid clouds, familiarity with physical storage hardware and SAN/NAS concepts also remains relevant.

7. Communication Skills

Cloud architects routinely translate complex technical concepts for non-technical stakeholders — executives, product owners, compliance officers, and end users. Jim Johnson of Robert Half Technology emphasized why this matters:

“Being able to articulate to a CIO the impact of the cloud… communication is a key piece of that. You need to talk to the users about what you’re providing, check for understanding, and make sure that you’re not talking over or talking under those individuals about how well your services or your current environment are supporting them.”

— Jim Johnson, Senior VP, Robert Half Technology

Practical communication skills for cloud architects include writing clear architecture decision records (ADRs), presenting infrastructure proposals to leadership, and facilitating incident retrospectives across teams.

8. Teamwork and Leadership

Cloud architects rarely work alone. They coordinate with application developers, security engineers, operations teams, and business stakeholders simultaneously. Leadership responsibilities often include:

• Setting technical direction and establishing architectural standards
• Mentoring junior engineers and reviewing infrastructure designs
• Facilitating alignment between teams with competing priorities
• Managing conflict diplomatically when architectural trade-offs are contested

Jim Johnson advises candidates to cultivate leadership skills early — through team projects, open-source contributions, or community involvement — rather than waiting until a formal management role presents itself.

9. Flexibility and Continuous Learning

The cloud landscape changes faster than almost any other area of technology. New managed services, architectural patterns, and compliance requirements appear regularly. Dan Kohn put it plainly:

“The specific skill sets in need are going to evolve over time. There are tons and tons of opportunities in the cloud. And it is an ongoing effort. It’s not going to stay static.”

— Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Staying current means following release notes for the cloud platforms you use, participating in community forums (CNCF Slack, cloud provider communities), pursuing relevant certifications, and experimenting with new services in sandbox environments. The ability to learn a new tool or pattern quickly is itself a core professional competency.

10. Business Acumen

Cloud architecture increasingly intersects with business strategy. Architects advise on make-vs-buy decisions, cloud cost optimization, vendor contracts, and digital transformation roadmaps. Jim Johnson recommended that engineers — especially those still in school — supplement their technical education with business coursework:

“Part of that might be a minor in business, or maybe even accounting to understand how the financials and numbers help drive businesses as well. But anything that gives you that exposure to what it takes to drive business, create a business, and run a business, with that technology understanding.”

— Jim Johnson, Senior VP, Robert Half Technology

Practical business skills for cloud architects include understanding total cost of ownership (TCO) modeling, building business cases for infrastructure investment, and communicating the financial impact of architectural choices — not just their technical merits.

Certifications and Learning Resources

Formal certification can validate your skills and accelerate hiring. Widely recognized cloud architect certifications include:

• AWS Certified Solutions Architect (Associate and Professional)
• Google Professional Cloud Architect
• Microsoft Azure Solutions Architect Expert
• Certified Kubernetes Administrator (CKA) — offered by the Linux Foundation via CNCF
• Certified Kubernetes Application Developer (CKAD)

Free and low-cost learning is available through edX, Coursera, the Linux Foundation’s training portal, and the official documentation for Kubernetes and each major cloud provider. Many certification exams include a proctored testing fee, but preparation materials are often freely available.

Putting It All Together

No single architect will be an expert in every area on day one. The practical approach is to build deep expertise in two or three areas — such as Kubernetes, security, and multi-cloud networking — while maintaining working knowledge across the rest. As your role evolves, so will the balance of skills you rely on most. The cloud architect who stays curious, communicates clearly, and understands the business impact of their technical decisions will remain in demand regardless of which specific tools dominate the market in any given year.

Original source: SDxCentral

The Security Gap That Containers and Kubernetes Are Creating

The rapid adoption of containers and orchestration platforms like Kubernetes is outpacing the security practices designed to protect them. According to research from the Cloud Security Alliance (CSA) presented at RSA Conference 2020, development and operations teams are deploying containerized workloads at scale — but many organizations have not yet adapted their security models to match the complexity this creates.

John Yeoh, Global Vice President of Research at the CSA, summed up the core tension: segmenting applications into containers and microservices delivers clear functional and scalability benefits, but it simultaneously multiplies the number of components that must be secured and made compliant.

“As we have seen with the use of containers and micro-services and compliance, when you further segment things off, there’s a functionality benefit from that. But you also have a lot more pieces to secure or to make compliant. So the challenge is how do we grant proper access control to containers and micro-services? How do we make these environments compliant?”

— John Yeoh, Global VP of Research, Cloud Security Alliance

Why Access Control Is the Central Problem

Containers are designed to be lightweight, portable, and numerous. In a busy Kubernetes cluster, dozens or hundreds of containers may run simultaneously across many nodes. This creates a sprawling attack surface where default configurations — including default security settings and default access controls — may be far more permissive than the sensitivity of the data being handled requires.

Yeoh points to a specific and well-documented attack pattern: an adversary compromises one container and then pivots laterally to others within the same cluster. Over-provisioned permissions — whether through misconfigured Role-Based Access Control (RBAC) policies, exposed Kubernetes API servers, or overly broad service account tokens — are frequently the enabler.

“We see breaches and incidents all the time when it’s compromised credentials or something really silly like, ‘Why does the attacker have that much access when they penetrate one environment?’ If we can address that and limit that, we’re going to be much better off.”

— John Yeoh, Cloud Security Alliance

Common Access Control Failures in Container Environments

• Overpermissive RBAC policies: Granting cluster-admin or broad namespace access when narrower roles would suffice.
• Default service account tokens auto-mounted: Kubernetes mounts service account tokens by default; many workloads that don’t need API access still receive it.
• Unrestricted inter-pod communication: Without Network Policies, every pod can reach every other pod in a namespace.
• Exposed Kubernetes API server: Publicly reachable API endpoints without strong authentication have been exploited in documented incidents.
• Secrets stored in plain text: Credentials embedded in container images or environment variables rather than managed through a secrets manager.

Shifting Security Left: Building It Into the Development Cycle

The CSA’s position — consistent with the broader DevSecOps movement — is that security must be addressed as early as possible in the software development lifecycle, not bolted on after deployment. Yeoh describes a model where automated checks are embedded directly into CI/CD pipelines, and where code with security problems can be rolled back before it ever reaches production.

“You are also able to automate a lot of these [checks] as well, and you can almost create a self-healing architecture, where it rolls back, is fixed and then moves forward. We’re seeing more and more people do that in cloud environments. It’s a way to make sure that developers are held accountable.”

— John Yeoh, Cloud Security Alliance

In practical terms, this means integrating tooling at several stages of the pipeline:

• Image scanning: Scanning container images for known CVEs before they are pushed to a registry (tools such as Trivy, Clair, or Snyk Container).
• Static analysis: Linting Kubernetes manifests and Dockerfiles for security misconfigurations (tools such as kube-score, Checkov, or Kubesec).
• Admission controllers: Using Kubernetes admission webhooks (e.g., OPA/Gatekeeper, Kyverno) to block non-compliant workloads from being deployed to the cluster at all.
• Runtime security: Monitoring container behaviour at runtime to detect anomalous system calls (tools such as Falco).
• Automated rollback: GitOps workflows that can detect a failed or insecure deployment and roll back to a known-good state automatically.

Compliance in a Containerized World

Container environments present compliance teams with a challenge that traditional VM-based infrastructure did not: workloads are ephemeral. A container may run for seconds or minutes and leave no persistent audit trail unless that logging is explicitly configured. This makes meeting the audit and data-residency requirements of regulations such as the California Consumer Privacy Act (CCPA) and the New York SHIELD Act — both discussed at the CSA’s RSA 2020 sessions — significantly more complex.

Attorney Aravind Swaminathan, Global Co-Chair of the cyber, privacy and data innovation practice at Orrick Herrington & Sutcliffe LLP, highlighted a broader issue for organizations moving to cloud: users and organizations do not own the underlying infrastructure, which changes the risk model fundamentally.

“There’s tons of value in the cloud, but you have to understand the risks. We have recently seen individuals compromise the cloud environment when we thought we had protections like multifactor authentication and certain controls, and attackers were able to make end-runs around those. And that’s the challenge.”

— Aravind Swaminathan, Orrick Herrington & Sutcliffe LLP

Practical Recommendations for DevOps and Security Teams

Based on the challenges identified by the CSA and the speakers at RSA 2020, the following practices reflect the direction the industry is moving:

1. Apply least-privilege RBAC: Audit every Kubernetes role and cluster role binding. Grant only the permissions a workload genuinely needs.
2. Disable auto-mounting of service account tokens on pods that do not need to communicate with the Kubernetes API.
3. Implement Network Policies: Default-deny all ingress and egress traffic, then explicitly allow only required flows.
4. Scan images before deployment: Block images with critical or high CVEs from reaching production registries.
5. Use a secrets management solution: Avoid embedding credentials in images or manifests; use a dedicated secrets store integrated with your cluster.
6. Enable audit logging: Kubernetes audit logs and container runtime logs should be shipped to a centralized, tamper-resistant store for compliance and incident response.
7. Adopt a DevSecOps pipeline: Make security gates part of CI/CD so that developers receive fast feedback and policy is enforced consistently.
8. Plan for regulatory requirements early: Map data flows through your containerized architecture to understand where regulated data lives and how ephemeral workloads affect audit trails.

The Road Ahead

The security challenges that containers and Kubernetes introduce are not insurmountable, but they do require a deliberate shift in how security is resourced and when it is applied. The CSA’s research presented at RSA 2020 reflects a consensus view that is still relevant today: security teams must evolve from gatekeepers who review finished applications to engineers who build security requirements directly into the development process. Self-healing pipelines, automated compliance checks, and granular access control are no longer aspirational — they are operational requirements for any organization running containerized workloads in production.

Original reporting by BankInfoSecurity. Cloud Security Alliance research was presented at RSA Conference 2020, San Francisco.

IBM Reports Double-Digit Commercial Cloud Revenue Growth

IBM Corp. recorded double-digit revenue growth in its commercial cloud services segment as public cloud adoption accelerated among mid-market businesses, according to Vikas Arora, Vice-President of Cloud and Cognitive Software and Services at IBM India and South Asia.

IBM defines its “commercial” customer tier as any customer outside its top 200 enterprise accounts. As of early 2020, the company had more than 1,000 customers on IBM Public Cloud, a platform primarily targeting the mid-market segment.

“Our cloud integration platforms over the past two-three years have been very successful. In the commercial space, IBM’s focus has been on new customer acquisition and we are seeing double-digit revenue growth in this space, with public cloud gaining traction.”

Vikas Arora, Vice-President, Cloud and Cognitive Software and Services, IBM India and South Asia

Security Portfolio Sees Robust Growth

Within IBM’s commercial business, the security portfolio experienced particularly strong momentum. Arora highlighted that many smaller banks were actively investing in strengthening their security infrastructure, contributing to this growth. IBM’s broad security offerings — spanning identity, threat intelligence, and managed security services — positioned the company well as regulated industries began cloud migration planning.

The Red Hat Acquisition and the Hybrid Cloud Opportunity

IBM’s $34 billion acquisition of Red Hat — completed in 2019 — formed the strategic backbone of the company’s hybrid cloud push. IBM positioned the deal as unlocking a $1.2 trillion hybrid cloud market opportunity for 2020 and beyond. Red Hat’s open-source portfolio, including OpenShift and Ansible, gave IBM a platform-agnostic container and orchestration layer that could operate across on-premises data centers and multiple public clouds.

This is particularly relevant for regulated industries — such as banking, financial services, and telecommunications — where mission-critical workloads cannot simply be lifted and shifted to a public cloud. Hybrid cloud architectures allow these organizations to maintain compliance and data sovereignty while gradually extending workloads to public infrastructure.

What Is Public Cloud? A Quick Definition

For context, a public cloud is a computing model in which infrastructure resources — such as virtual machines, storage, and managed services — are made available over the internet by a third-party provider. Well-known examples include Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Pricing is typically consumption-based, with options ranging from pay-per-use to reserved capacity models. IBM Public Cloud sits alongside these hyperscalers, differentiating primarily through enterprise integration, security, and Red Hat-based open-source tooling.

India’s Public Cloud Market: Growth Projections

The broader market context in India was favorable at the time of this reporting. According to a joint report by Google Cloud and Boston Consulting Group (BCG), public cloud deployments in India were projected to grow at a compound annual growth rate (CAGR) of 25%, expanding from approximately $3 billion in 2018 to $8 billion by 2023. The same report estimated a cumulative GDP contribution potential of approximately $100 billion from 2019 to 2023.

Despite these projections, Arora noted that only 15–20% of the Indian cloud market was on public cloud at the time. The relatively low penetration was attributed to regulated industries — particularly banking and telecommunications — keeping mission-critical workloads off public infrastructure due to compliance and data privacy concerns.

Maturity Curve: From Pilots to ROI-Focused Cloud Strategy

Arora described a clear maturity curve in how organizations approach cloud adoption:

• Early stage: Customers running pilots and proofs of concept for specific AI or data analytics use cases.
• Intermediate stage: Enterprise conversations shifting toward security, data privacy, and managed cloud services.
• Mature stage: Organizations that completed automation years ago — notably banks and telcos — now focused on unlocking new revenue streams and increasing customer stickiness through deeper cloud investment.

Manufacturing represented a sector earlier in the journey, while financial services and telecommunications were described as leading adopters already focused on return on investment (ROI) metrics rather than initial migration planning.

“There is always a very strong focus on RoI through IT spends. Across sectors, some have matured earlier than others like banks and telecom. They accomplished automation several years ago. So, they are looking to unlock new revenue streams by increasing customer stickiness in terms of cloud spends.”

Vikas Arora, IBM India and South Asia

Key Takeaways for DevOps and Cloud Practitioners

• IBM’s commercial cloud growth is driven by mid-market adoption, not just its top-tier enterprise accounts.
• The Red Hat acquisition gives IBM a credible open-source, container-native story for hybrid cloud deployments — directly relevant to teams using OpenShift or Kubernetes.
• Security remains a top concern and a top budget priority, particularly for regulated industries moving toward cloud-native architectures.
• Organizations evaluating cloud strategy should expect to map their position on the maturity curve: pilot/PoC, active migration, or ROI optimization.
• Hybrid cloud — not full public cloud migration — is the dominant model for mission-critical workloads in regulated sectors.

The Challenge Facing Service Providers

Launching innovative enterprise communication services has historically been difficult for service providers. The process is time-consuming, resource-intensive, and slow to produce a return. As a result, many network operators have underutilised their existing assets—including VoLTE infrastructure and mobile subscriptions—when it comes to serving business customers.

That situation is beginning to change. A convergence of major technology shifts is opening up a genuinely new market for cloud-native communication services aimed at business users.

Technology Shifts Creating the Opportunity

Several concurrent developments are reshaping what service providers can offer enterprises:

• 5G: Higher throughput and lower latency enable richer real-time communication services.
• Cloud infrastructure: Microservices architectures allow providers to compose and release new offerings rapidly without rebuilding core systems.
• AI and Augmented Reality: Intelligent automation and AR-enabled workflows become viable for mobile-first businesses.
• IoT: Connected devices expand the communication perimeter well beyond phones and laptops.
• eSIM: Remote SIM provisioning removes friction from onboarding and device management, enabling self-service and automated ‘Try & Buy’ or ‘Multi Device’ scenarios.

Taken together, these shifts create a foundation for next-generation digital transformation and more flexible, mobile-first ways of working—particularly for smaller organisations that cannot afford traditional enterprise IT stacks.

A Framework for Delivering Cloud Communication Services

To capitalise on this opportunity, service providers should consider the following approach:

• Build or enhance turnkey services rather than pursuing fully custom deployments for every client.
• Deliver as a service to achieve scale, reduce time-to-market, and maintain quality-of-service controls without burdening the customer with on-premise infrastructure.
• Expose cloud-based microservices that can be composed into different use cases depending on the customer segment.
• Leverage existing network assets—VoLTE and eSIM infrastructure—rather than building from scratch.
• Prioritise self-service and automation, both for customer onboarding and ongoing service management.

The combination of cloud communication services with automated eSIM provisioning is particularly compelling. It allows business users to activate, manage, and expand their subscriptions with minimal friction—a genuine competitive differentiator for proactive providers.

Three Sales Strategy Steps to Revenue

Technology alone does not create revenue. Service providers also need a focused go-to-market strategy. The following three steps provide a practical framework.

1. Target the Right Client Segment

Business customers can be segmented in several ways:

• By size: Multinational companies (MNCs), large enterprises, small and medium enterprises (SMEs), and microbusinesses.
• By industry: Retail, manufacturing, finance, IT, government, and others.
• By IT/communication maturity: How strategically important is technology to the organisation’s operations?

For cloud communication services specifically, the microbusiness segment is worth prioritising first. Microbusinesses are heavily mobile-first, have no in-house IT operations team, and are unlikely to demand fully custom integrations. By contrast, larger SMEs and enterprise organisations with strong internal IT departments often prefer bespoke solutions—which are expensive, slow to deliver, and frequently outdated by the time they launch.

2. Prioritise Convenience Over Feature Depth

For business users who are not IT specialists, convenience is the primary value driver. Effective cloud communication offerings should solve time-consuming and costly communication problems without requiring technical expertise to set up or maintain. When the communication layer just works, employees can focus on their actual business activities rather than managing tools.

3. Minimise the Investment Required from the Customer

Cloud communication services should not require significant upfront capital expenditure from the customer—neither in equipment and systems integration nor in specialist staff. The ‘as a service’ model is critical here: it transforms what would otherwise be a large IT project into an operational expense with a short time to value.

The Microbusiness Market Opportunity

The microbusiness segment is largely untapped when it comes to business-grade communication services. According to the original Ericsson perspective (citing a provider survey and an Ovum B2B demographics report from August 2018 covering North America, Europe, and Australia), approximately 80% of microbusinesses were found to be using consumer-grade subscriptions rather than business packages.

This creates a clear upsell opportunity. If service providers design targeted business packages with self-service onboarding and automation, they can migrate existing consumer subscribers to higher-value plans without significant sales overhead. Initial revenue modelling referenced in the original source suggested incremental revenue potential of roughly €8–€15 per user per month in Western Europe—on top of what microbusinesses already pay for consumer subscriptions.

The scale of the segment amplifies this: the Ovum data referenced approximately 28 million microbusiness enterprises and 52 million employees across the geographies studied. At scale, the addressable incremental revenue opportunity is significant—but capturing it requires automation and smart marketing rather than a large direct salesforce.

Expanding Beyond Microbusiness

A successful microbusiness launch builds the operational foundation—billing systems, self-service portals, eSIM provisioning pipelines—needed to move upmarket. The next logical step is targeting SMEs and larger enterprises, but with an important filter: focus on organisations that are not looking for custom-built solutions. These are businesses that prioritise speed of adoption and operational simplicity over deep integration with proprietary internal systems.

Service providers that establish this progression—from microbusiness to mainstream SME—will be well positioned as cloud communication becomes a standard expectation rather than a differentiator.

Key Takeaways for DevOps and Platform Teams

For engineering and platform teams supporting service providers or building cloud communication products, the practical implications are:

• Design for self-service from day one—automated provisioning, including eSIM, is not optional in a high-volume, low-touch segment.
• Adopt a microservices architecture so that communication capabilities (calling, messaging, conferencing) can be bundled and unbundled per customer segment without full re-engineering.
• Build robust CI/CD pipelines that allow new service bundles to reach market quickly—time-to-market is a primary competitive lever.
• Prioritise observability and quality-of-service controls at the API layer so that service-level guarantees can be contractually offered to business customers.
• Automate billing and subscription management to support the ‘as a service’ model at the scale microbusiness volumes require.

Original perspective: Ericsson (ericsson.com), February 2020.

Overview

Ericsson announced four additions to its 5G platform aimed at enhancing user experience, reducing complexity and total cost of ownership (TCO), enabling faster service deployment, and introducing automated provisioning. As operators move to 5G, the mobile network must support a broader range of services and significantly higher data volumes than previous generations, demanding greater levels of automation and intelligence throughout the stack.

David Bjore, Head of R&D and Portfolio, Business Area Digital Services at Ericsson, commented: “Through our core networks, service providers can get to market faster and can capitalize on new services, through leading consumer and enterprise communication and monetization solutions, enabling them to stay ahead in the race for 5G business, today and tomorrow.”

Key Additions to the 5G Platform

• Dual-mode 5G Core with built-in software probes, integrated with Ericsson Expert Analytics
• Ericsson Cloud Native Infrastructure: bare-metal container infrastructure for 5G Core deployments
• Ericsson Communication Accelerator: cloud-based microservices for business communication
• Automated eSIM offering for expanded device connectivity

Securing 5G Experience with Built-In Software Probes

Traditional appliance-based probing is not sustainable at 5G Core scale. Hardware probes add cost and operational complexity that conflicts with the cloud-native design principles underpinning 5G architecture. Ericsson’s dual-mode 5G Core addresses this by embedding software probes directly into the core network, eliminating the need for separate probing appliances and the associated capital expenditure.

These built-in probes are pre-integrated with Ericsson Expert Analytics, providing correlated end-to-end insights that extend from the core to the Radio Access Network (RAN). Transparent and secure interfaces in the 5G Core architecture also ensure that sensitive subscriber data remains protected during analysis.

Anil Rao, Principal Analyst at Analysys Mason, stated: “The traditional appliance-based probes technology and the associated CEM approaches are not fit for purpose to guarantee customer experiences in cloud-based 5G networks. Ericsson’s dual-mode 5G Core with built-in software probes, pre-integrated with Ericsson Expert Analytics’ intelligence, enables CSPs to deliver superior 5G customer experiences and accelerate 5G roll-out.”

Cloud Native Infrastructure: Containers on Bare Metal

Ericsson introduced Ericsson Cloud Native Infrastructure, a bare-metal container platform designed to simplify the deployment of cloud-native applications such as 5G Core, both at central data centers and at edge sites. By removing the virtualization layer—eliminating the hypervisor overhead present in traditional VM-based deployments—the solution reduces complexity and improves hardware efficiency and application performance.

Ericsson claims TCO savings of 30% or more compared to VM-based infrastructure, though this figure should be treated as a vendor estimate rather than an independently verified benchmark. Automated deployments across distributed sites are a core design goal, which aligns with the operational requirements of large-scale 5G rollouts.

Caroline Chappell, Research Director at Analysys Mason, noted: “A bare metal container infrastructure makes network deployments and operations simpler and automation easier as well as enhancing cloud native function (CNF) performance. The announcement of a bare metal solution is an important contribution to further progress telecom operators’ implementations of cloud native applications.”

Ericsson Communication Accelerator: Business Communication Services

The Ericsson Communication Accelerator is a portfolio of cloud-based microservices that communication service providers (CSPs) can combine to rapidly deliver advanced mobile business communication offerings. The solution is delivered as-a-service and is designed to leverage a service provider’s existing network assets, reducing time to market while maintaining security and quality of service controls.

New Service Opportunities for Operators

• Enterprise Voice Services: Combines traditional business voice with innovative features to differentiate operator offerings in the enterprise market.
• IoT Voice Services: Provides automated, centralized management of voice services for IoT deployments.
• Contextual Communication Services: Enables straightforward integration of advanced communication and collaboration capabilities into websites or third-party applications.

Diane Myers, Senior Research Director for VoIP, UC and IMS Technology at IHS Markit, commented: “Cloud communications services for business users have been the playground for pure-play UCaaS and CPaaS providers. It is time for mobile operators to accelerate their business communication offerings to the market. An initial focus on the microbusiness segment is a good steppingstone for expansion and growth in the business segment.”

Automated eSIM and Consumer Demand

Complementing the Communication Accelerator, Ericsson also launched a fully automated eSIM offering. eSIM simplifies multi-device connectivity for consumers and enterprises by enabling over-the-air SIM provisioning without physical SIM card swaps. According to an Ericsson ConsumerLab report cited at the time of announcement, 94% of survey respondents indicated willingness to pay extra to connect additional devices to their existing subscription plan, and 86% expressed interest in “try and buy” service offerings.

Together, these additions position Ericsson’s 5G platform as an end-to-end portfolio covering network infrastructure, operational analytics, business communication services, and consumer connectivity — addressing the commercial as well as technical requirements operators face in a 5G transition.

Summary

As 5G deployments mature, orchestration, automation, and cloud-native design will increasingly separate competitive operators from those still managing legacy infrastructure. These additions reflect Ericsson’s strategy of tying together core network modernization with commercial service enablement on a single platform.

The Growing Pressure on Enterprise IT

Businesses are increasingly recognizing that their applications are the business — the primary gateway to customers and revenue. As organizations pivot toward becoming app-centric, enterprise IT faces enormous strain. Silos between application development teams and infrastructure operations teams widen, creating blind spots that lead to degraded user experiences, outages, and slow incident resolution.

To address this challenge, Cisco announced a multi-domain strategy that connects application performance data with infrastructure telemetry, giving both DevOps engineers and IT operations teams a unified, full-stack view of their environments.

Key Innovations Announced by Cisco

1. AppDynamics Experience Journey Map

Cisco’s AppDynamics application performance monitoring (APM) platform introduced the Experience Journey Map, a feature that automatically surfaces the most critical user journeys within mission-critical applications. Rather than surfacing raw metrics in isolation, the Experience Journey Map correlates:

• Business metrics — conversion rates, transaction values, and other KPIs
• User experience data — page load times, error rates, and session quality
• Application performance signals — service response times, dependency health, and error traces

This single correlated view is designed to break down the communication barrier between business stakeholders and engineering teams, allowing both groups to reason from the same data when prioritizing incidents or feature work.

2. AppDynamics and Cisco Intersight Workload Optimizer Integration

One of the more significant announcements was the direct data-sharing integration between AppDynamics and Cisco Intersight Workload Optimizer. Historically, application teams and infrastructure teams operated with separate toolchains and vocabularies, making cross-team troubleshooting slow and error-prone.

This integration enables:

• A shared view of infrastructure dependencies that affect application performance and business outcomes
• Common tooling and datasets so that both teams are looking at the same ground truth
• Application insight directly coupled to infrastructure automation — described by Cisco as an industry first at the time of announcement
• Real-time response to application-centric demands without sacrificing cost control or compliance

In practice, this means that when AppDynamics detects application degradation, Intersight Workload Optimizer can automatically correlate the symptom to its infrastructure root cause — whether that lies at the VM layer, the container layer, or deeper in storage, compute, or networking hardware.

3. Intersight Workload Optimizer: Cost and Performance Optimization

Cisco Intersight Workload Optimizer extended its capabilities to cover hybrid application architectures more completely. Key capabilities include:

• Performance optimization — proactive identification of resource bottlenecks using historical and real-time telemetry
• Cost optimization — flagging over-provisioned resources and surfacing opportunities to right-size workloads
• Compliance constraints — ensuring workload placement decisions respect policy guardrails
• Full-stack root cause analysis — pinpointing whether application degradation originates at the application tier, virtualization/container layer, or physical infrastructure

Unlike tools that limit their scope to virtualized infrastructure alone, Intersight Workload Optimizer is designed to traverse the entire stack — from the application down to bare-metal hardware — to identify the true origin of a performance problem.

4. Cisco HyperFlex Application Platform

The Cisco HyperFlex Application Platform is a new integrated container-as-a-service (CaaS) offering built around Kubernetes. It targets a common pain point: Kubernetes is the de facto standard for modern application deployment, but operating it consistently across cloud, data center, and edge environments remains operationally complex for many enterprise IT teams.

HyperFlex Application Platform addresses this by:

• Curating open-source tooling into a validated, integrated stack, reducing the burden of tool selection and compatibility testing
• Automating routine Kubernetes operations such as cluster provisioning and lifecycle management
• Providing a consistent operational model across multicloud, on-premises data center, and edge deployments
• Integrating with AppDynamics and Intersight for real-time monitoring and optimization of the complete application-to-infrastructure stack

The platform is aimed at bridging the gap between DevOps engineers who want Kubernetes flexibility and IT operations teams who need standardized, supportable infrastructure.

Cisco’s Strategic Position: Bridging Three Layers

Osama Al-Zoubi, Cisco CTO for Middle East and Africa, articulated the strategic differentiation at announcement:

“While some vendors provide visibility into apps or an individual tier of physical or virtual infrastructure, Cisco is the first to bridge all three with insight and proactive optimization up and down the stack. And with the HyperFlex Application Platform we are making Kubernetes, the new de facto standard for app developers, much easier to deploy and manage for both app and infrastructure teams.”

Osama Al-Zoubi, Cisco CTO, Middle East and Africa

The broader theme of these announcements is breaking down silos — between business and engineering, between application teams and infrastructure teams, and between on-premises and cloud environments. By correlating data across these boundaries and automating remediation actions, Cisco is positioning its portfolio as a unified control plane for hybrid multicloud application operations.

What This Means for DevOps and Platform Engineering Teams

For practitioners, the practical implications of these announcements fall into a few categories:

• Observability across the full stack — integrating APM data (AppDynamics) with infrastructure telemetry (Intersight) reduces mean time to detect (MTTD) and mean time to resolve (MTTR) by eliminating the need to correlate data manually across separate tools.
• Kubernetes adoption at enterprise scale — the HyperFlex Application Platform lowers the operational barrier to running Kubernetes consistently in hybrid environments, which is a significant concern for enterprises moving beyond single-cloud or single-datacenter deployments.
• FinOps alignment — workload optimization features that surface over-provisioning and cost reduction opportunities align with growing enterprise interest in cloud cost governance.
• Automated remediation — coupling application insight directly to infrastructure automation (rather than generating alerts for humans to act on) moves operations teams closer to a self-healing infrastructure model.

Note: This article is based on Cisco’s February 2020 announcements as reported at the time. Product names, features, and integrations may have evolved since then. Consult cisco.com for current product documentation.

The Serverless Lock-In Problem

Serverless computing has delivered genuine productivity gains for development teams, but it has come at a cost: every major cloud provider’s serverless offering is essentially a walled garden. AWS Lambda, Azure Functions, and Google Cloud Functions each use proprietary APIs and event models. Moving workloads between providers—or running them consistently across hybrid and multi-cloud environments—is difficult, often requiring teams to maintain separate deployment pipelines for each platform.

Knative is the open-source project designed to break that pattern. Originally initiated by Google and developed with contributions from IBM, Pivotal, Red Hat, and others, Knative layers a serverless runtime on top of Kubernetes, making it possible to deploy event-driven functions on any infrastructure that runs Kubernetes—whether that’s a private data center, a public cloud, or a combination of both.

What Serverless Actually Means

The term “serverless” is frequently misunderstood. Functions-as-a-service (FaaS) workloads absolutely run on servers; the key distinction is that developers don’t manage those servers. Instead, functions are packaged in containers, started on demand when an event triggers them, scaled automatically to meet load, and shut down when the task is complete. Users pay only for the compute time consumed while the function is active.

AWS popularised this model with the launch of Lambda in 2014. Microsoft Azure followed with its own Functions service. The appeal is straightforward: tasks that don’t need to run continuously—sending a notification when a database record changes, processing an uploaded file, responding to a webhook—are a natural fit for short-lived, event-triggered execution.

Serverless is sometimes conflated with microservices, but they are distinct. Microservices decompose an application into loosely coupled services that are typically always running. Serverless functions, by contrast, are dormant until triggered. As Brian Gracely, then senior director of product strategy for Red Hat OpenShift, explained to Data Center Knowledge:

“Those types of tasks don’t need to run all the time, they just need to run when an event happens. Maybe a database table got updated for an order, so I’m going to kick off a small job to send a text message to the customer with this updated status. There are lots of things like that which go on in IT with applications all the time, so this became something that a subset of developers found really appealing.”

How Knative Works

Because serverless workloads run in containers, Knative integrates directly with Kubernetes. It also relies on a service mesh—most commonly Istio or Linkerd—to handle request routing and traffic management. In Kubernetes terms, Knative introduces a new deployment type tailored to event-driven, short-running, auto-scaling workloads, sitting alongside existing primitives like Deployment (for long-running applications) and StatefulSet (for stateful services that need stable network identities).

Richard Seroter, then VMware’s senior director of technical marketing and developer relations, described Knative’s scope to Data Center Knowledge:

“It’s not just a function platform, it is a kind of a Kubernetes native app runtime. Vendors might use it to put a ‘dev experience’ on top of Kubernetes that developers who don’t want to know all the plumbing of Kubernetes can use.”

This is an important point for platform teams: Knative is not only about serverless. It can serve as a higher-level abstraction that makes Kubernetes more accessible to application developers who don’t need—or want—to understand every detail of cluster configuration.

Knative’s Core Components

Knative is designed with a modular architecture. At the time of writing (early 2020), it comprised two primary components developed on independent release tracks:

Serving

The Serving component handles the actual execution of application code. It manages the lifecycle of containerised workloads: starting them when a request or event arrives, scaling them up under load, scaling them down to zero when idle, and routing traffic to the appropriate revision of a service. Serving is closely aligned with existing Kubernetes patterns and was the more mature of the two components.

Eventing

The Eventing component defines how external signals—a new database entry, a file appearing in object storage, a message on a queue, an inbound webhook—trigger Serving workloads. Eventing is broader in scope than Serving because it must accommodate a wide variety of event sources and delivery semantics, which is why it lagged behind Serving in its progression toward general availability.

Gracely summarised the relationship between the two components concisely:

“Events are the things that trigger your application code to work… Those are going to be the things that trigger your function to start. ‘Serving’ means actually start the application, do whatever computation I need to do, and then I have an action that comes out of that.”

Tekton: The Spun-Off Build Component

Early Knative development included a third component, Build, intended to provide CI/CD pipeline capabilities. The community decided that build functionality was generic enough to be useful far beyond the Knative project itself, so it was extracted and released as an independent project called Tekton. Tekton has since become a widely adopted, Kubernetes-native CI/CD framework in its own right.

Governance: Who Controls Knative?

Google transferred control of the Kubernetes project to the Cloud Native Computing Foundation (CNCF), a Linux Foundation project, in 2018. Developers widely expected Knative to follow the same path. However, shortly before KubeCon North America 2019 in San Diego, Google announced that it would retain stewardship of Knative for the foreseeable future—a decision that surprised parts of the community and raised questions about the project’s long-term neutrality.

This governance question is worth monitoring for any organisation evaluating Knative as a strategic platform component.

Ecosystem Integration

By early 2020, several commercial Kubernetes platforms were incorporating Knative. Red Hat indicated that Knative would become an integrated part of OpenShift and included in its core subscription. VMware (which had acquired Pivotal) was also positioning Knative as a layer for delivering improved developer experience on top of Kubernetes.

Why Knative Matters for DevOps Teams

• Portability: Knative workloads run on any conformant Kubernetes cluster, eliminating the need to rewrite function code when changing or adding cloud providers.
• Hybrid and multi-cloud support: Teams can run the same serverless workloads on-premises and in the public cloud without maintaining parallel deployment pipelines.
• Kubernetes simplification: The Serving abstraction provides a higher-level interface to Kubernetes that shields application developers from cluster-level complexity.
• Ecosystem compatibility: Tekton integration gives teams a Kubernetes-native CI/CD path that works alongside Knative without being tightly coupled to it.
• Cost model: Scale-to-zero behaviour means idle workloads consume no compute resources, preserving the economic advantage of serverless even when running on self-managed infrastructure.

Summary

Knative represents a practical attempt to standardise serverless on top of Kubernetes, giving DevOps teams a path to event-driven, auto-scaling workloads that aren’t tied to any single cloud provider. Its modular design—separating the concerns of event ingestion (Eventing) and workload execution (Serving)—makes it flexible enough to fit into a range of infrastructure configurations. For teams already invested in Kubernetes, Knative is a natural extension worth evaluating as serverless adoption grows beyond individual cloud platforms.

The Customer Is Still the Weakest Link

To date, the majority of well-documented cloud security incidents have been caused by customer-side failures rather than breaches of the cloud service provider’s (CSP’s) own infrastructure. This is an important distinction. CSPs typically have far greater visibility into network configuration and data flows than their customers do — yet they often shield that infrastructure behind proprietary tooling and interfaces, creating a meaningful information asymmetry.

Customers can begin to close this gap by adopting a shared security model with their CSP and by layering in their own zero-trust controls. Before defining solutions, however, it is worth cataloguing the threats that multicloud teams most commonly face.

Common Threats to Cloud Security

1. Misconfiguration and Insufficient Security Settings

Misconfiguration is consistently cited as one of the leading root causes of cloud breaches across both government agencies and commercial organisations. In practice, misconfiguration most often means incorrect Identity and Access Management (IAM) role assignments — giving cloud service accounts more privilege than they need, or failing to restrict access at all.

The canonical example is improperly configured AWS S3 buckets left publicly readable. AWS has since introduced default-block settings and improved its console warnings to help customers avoid this mistake, but misconfigured object storage remains a widespread problem across all major cloud platforms.

2. Insecure APIs

APIs are the primary interface through which customers manage and export cloud data. When APIs are poorly designed, inadequately authenticated, or sourced from third-party vendors with weak security postures, they become high-value targets. Attackers who discover an exposed or weakly authenticated API endpoint can potentially enumerate resources, exfiltrate data, or pivot deeper into a cloud environment without triggering conventional perimeter alerts.

3. Insider Threats — Intentional and Unintentional

Insider threats sit on a wide spectrum. At one end are untrained or negligent employees who hold cloud accounts without appropriate controls — a misconfigured resource or an accidentally shared credential can cascade into a significant incident. At the other end are malicious actors, either employees or external attackers who have obtained insider-level access.

The Capital One breach (2019) is frequently referenced as a case where an attacker exploited a misconfigured Web Application Firewall to assume a cloud IAM role and access sensitive data stored in S3 — illustrating how an outsider can effectively operate as a privileged insider once a foothold is established.

4. Network Misconfiguration

The elasticity of cloud infrastructure — spinning up servers and network segments in minutes — creates significant risk when the people performing those actions do not fully understand the underlying network model. Specific examples include:

• Servers exposed without SSH key authentication or with default/weak credentials
• Unnecessarily open inbound ports creating attack surfaces for DDoS and brute-force campaigns
• Overly permissive rules on cloud-native Security Groups
• Misconfigured Network Access Control Lists (NACLs) that fail to restrict lateral movement

Because cloud environments democratise infrastructure provisioning, it is unsafe to assume that every team member who can click “Launch” also understands the network security implications of what they are deploying.

Four Mitigation Strategies for Multicloud Security

No single control eliminates multicloud risk. The following four strategies, used in combination, can meaningfully reduce an organisation’s attack surface and improve its overall security posture.

1. Zero-Trust Security

Zero trust operates on the principle of “never trust, always verify.” In a multicloud context this is especially relevant: workloads span environments that fall entirely outside the traditional corporate perimeter, making perimeter-based security controls ineffective by design.

Key zero-trust techniques applicable to cloud include:

• Microsegmentation: Dividing cloud workloads into small, independently controlled network segments so that a breach of one workload cannot automatically reach others.
• Identity-aware proxies: Authenticating and authorising every request based on user and device identity rather than network location.
• Single access gateways: Centralising ingress and egress inspection, analogous to the US government’s Trusted Internet Connection (TIC) architecture.
• Mandatory verification of every access request: No implicit trust based on IP address, VPN membership, or previous authentication.

When implemented consistently, zero trust reduces the blast radius of any single compromise and provides greater visibility into who is accessing what across your cloud estate.

2. Cloud Access Security Brokers (CASBs)

A CASB sits between users and cloud services, enforcing security policies — visibility, compliance, data security, and threat protection — across sanctioned and unsanctioned SaaS, IaaS, and PaaS usage. CASBs are particularly useful for discovering shadow IT and enforcing consistent data-loss prevention (DLP) policies across multiple cloud vendors.

Adoption of CASBs has historically been slower than analysts anticipated. According to Gartner’s Hype Cycle reporting referenced in the original Forbes article, CASBs were entering the “trough of disillusionment” at the time of writing (circa 2019–2020). Several independent CASB vendors have since been acquired and folded into broader security platforms. Microsoft, for example, has integrated CASB capabilities directly into Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security).

When evaluating a CASB, consider whether it provides native integrations with each cloud platform in your estate, and whether it will be maintained as a discrete product or absorbed into a larger suite.

3. Workforce Training Tailored to Multicloud Environments

Cloud migration plans frequently budget for tooling and architecture but under-invest in people. Teams trained exclusively on one CSP’s console and security model can introduce risk when the organisation adds a second or third cloud platform, because security assumptions from AWS do not map directly onto Azure or Google Cloud — and vice versa.

Effective multicloud security training should cover:

• The shared responsibility model as it applies to each CSP in use
• IAM fundamentals and least-privilege principles specific to each platform
• Safe storage and API configuration practices across vendors
• Incident recognition and escalation procedures for cloud-native environments

Training should be treated as a continuous programme, not a one-time onboarding exercise, given how rapidly CSP feature sets and security controls evolve.

4. Choosing the Right Partners and Integrators

In a fast-moving cloud ecosystem, vendor and integrator selection has long-term security implications. Partners who have worked across multiple CSPs — and who have direct experience with regulated industries or public-sector requirements — bring institutional knowledge that is difficult to build internally in a short timeframe.

For federal agencies in particular, working with integrators who hold relevant certifications (FedRAMP authorisation experience, for example) and who understand compliance frameworks such as NIST SP 800-53 is critical. The same principle applies to commercial organisations operating in regulated sectors such as healthcare or financial services.

Partner selection criteria should include demonstrated multicloud experience, a clear security methodology, and a track record of working within shared responsibility frameworks — not just technical delivery capability.

Looking Ahead: Shared Responsibility at Scale

As enterprises operate across increasingly complex combinations of multicloud, hybrid cloud, and on-premises infrastructure, the shared security model becomes harder to maintain consistently. The information asymmetry between CSPs and their customers remains a structural challenge, and closing it requires CSPs to be more proactive about educating customers on risk — not just providing the tools to address it.

In the meantime, organisations that combine zero-trust architecture, CASB-based visibility, ongoing workforce education, and carefully selected partners will be meaningfully better positioned than those relying on any single control in isolation.

Original source: Forbes.com. This article summarises and expands on the key recommendations from that piece for a DevOps and cloud engineering audience.

Overview: Why the Intelligent Cloud Segment Matters

Microsoft (NASDAQ: MSFT) operates three major reporting segments: More Personal Computing, Productivity & Business Processes, and Intelligent Cloud. As of fiscal year 2019, all three segments contributed roughly equal shares of total revenue — but it is the Intelligent Cloud segment that has driven the most significant growth in both absolute and percentage terms since 2017, and that growth has been a key factor behind a dramatic rise in Microsoft’s stock price over that period.

According to Trefis estimates published in late 2019, the Intelligent Cloud segment was projected to contribute approximately $41.9 billion to Microsoft’s fiscal 2020 revenues — representing around 31.2% of a total projected revenue of roughly $134 billion. Between fiscal years 2017 and 2020, Microsoft was expected to add approximately $37.8 billion in total revenue, with the Intelligent Cloud segment accounting for an estimated $14.5 billion — or about 38.3% — of that increase.

Microsoft’s Business Model: Three Segments Explained

Microsoft is a diversified technology company that generates revenue from software, cloud services, hardware, gaming, and professional networks. Its products span operating systems, server applications, productivity suites, developer tools, gaming consoles, and enterprise business solutions. Revenue is reported across three operating segments:

1. More Personal Computing

This segment covers Windows operating system licensing, Surface devices, Xbox gaming (hardware, software, and services), and Bing search advertising. Revenue grew from approximately $39.3 billion in fiscal 2017 to $45.7 billion in fiscal 2019, with Trefis projecting approximately 3.2% growth to around $47.2 billion in fiscal 2020.

2. Intelligent Cloud

The Intelligent Cloud segment generates revenue from public, private, and hybrid server products and related cloud services. This includes Azure (Microsoft’s public cloud platform), SQL Server, Windows Server, GitHub, and enterprise support services. It is the fastest-growing segment in both absolute dollar terms and percentage growth rate. Revenue grew from approximately $27.4 billion in fiscal 2017 to $39 billion in fiscal 2019, with Trefis projecting approximately 7.4% growth to around $41.9 billion in fiscal 2020.

3. Productivity and Business Processes

This segment includes Microsoft 365 (formerly Office 365) subscription revenue, LinkedIn, and Dynamics 365 — Microsoft’s cloud-based CRM and ERP platform. Revenue from this segment is driven by subscription growth across both consumer and enterprise customers and by continued monetization of LinkedIn since its 2016 acquisition.

Revenue Growth: 2017–2019 in Context

Microsoft’s total revenue grew from approximately $96.6 billion in fiscal 2017 to $125.8 billion in fiscal 2019 — an increase of roughly $29 billion over two years. The Intelligent Cloud segment was the primary engine of that growth, expanding by approximately $11.6 billion in the same period. The cloud and business processes segments together were responsible for the majority of Microsoft’s top-line expansion.

Source: Trefis estimates, late 2019. Productivity & Business Processes FY2020 figure is implied from totals and may differ from Trefis’s published figure.

Why the Intelligent Cloud Segment Drives Stock Valuation

Cloud infrastructure and platform services command significantly higher operating margins than traditional software licensing or hardware sales. Azure, in particular, benefits from substantial economies of scale, long-term enterprise contracts, and deep integration with Microsoft’s productivity and developer tooling ecosystem. This combination of high growth rate and expanding profit margins is a key reason why investors and analysts attribute a premium valuation multiple to Microsoft’s cloud business.

The Intelligent Cloud segment’s strong performance since 2017 was cited by Trefis as a primary driver of the roughly 200% appreciation in Microsoft’s stock over that period — though stock price movements reflect many factors, including broader market conditions, share buybacks, and earnings growth across all segments.

Competitive Landscape

Microsoft competes across multiple markets, often against some of the world’s largest technology companies. Key competitive dynamics by segment include:

• Cloud infrastructure (Intelligent Cloud): Microsoft Azure competes primarily with Amazon Web Services (AWS) and Google Cloud Platform (GCP), and to a lesser extent IBM Cloud.
• Productivity software: Microsoft 365 competes with Google Workspace and various open-source alternatives.
• Enterprise databases and ERP: Microsoft competes with Oracle, SAP, and Amazon (through Amazon RDS and Aurora).
• Gaming (More Personal Computing): Xbox competes with Sony PlayStation, Nintendo, and increasingly with cloud gaming platforms from Google and others.
• Search (More Personal Computing): Bing competes primarily with Google Search.
• Operating systems: Windows competes with Apple macOS, ChromeOS, and Linux distributions.

Competition across all these markets is intense and driven by innovation cadence, pricing, ecosystem lock-in, and enterprise relationships. Microsoft’s ability to cross-sell Azure with Teams, Microsoft 365, GitHub, and Dynamics 365 gives it a structural advantage in enterprise accounts.

Key Takeaways for DevOps and Cloud Practitioners

For DevOps engineers and cloud architects, the financial trajectory of Microsoft’s Intelligent Cloud segment has practical implications:

• Azure investment is substantial and sustained. Microsoft’s cloud segment growth signals continued heavy R&D investment in Azure services, tooling, and infrastructure — which translates into new features, regions, and compliance certifications over time.
• Enterprise focus shapes the roadmap. Azure’s growth is heavily enterprise-driven, meaning the platform prioritizes hybrid connectivity, governance, compliance, and integration with on-premises workloads — via services like Azure Arc and Azure Stack.
• GitHub and developer tooling are part of the cloud strategy. GitHub’s acquisition and integration with Azure DevOps, Azure Pipelines, and Copilot reflects a deliberate strategy to capture developers early in the toolchain.
• Competitive pressure from AWS and GCP keeps pricing competitive. Organizations evaluating multi-cloud or cloud-native strategies benefit from competitive pricing and feature parity across the major platforms.

Further Reading

For a deeper analysis of Microsoft’s revenue model and valuation, Trefis maintains an interactive dashboard — Microsoft’s Revenues: How Does Microsoft Make Money? — that breaks down revenue drivers by segment. Microsoft’s investor relations page provides official segment financials updated quarterly.

Why Cloud Migration Myths Still Cause Real Problems

Cloud computing has been a top-tier technology investment priority for enterprises across every industry for several years running. Despite that momentum, many organizations transitioning to a cloud-only or hybrid cloud environment continue to hit unnecessary roadblocks—almost always rooted in security misconceptions rather than genuine technical limitations.

The core problem is that security teams often try to retrofit on-premises security practices into cloud environments. When that approach fails, the cloud itself gets blamed. In reality, the cloud is inherently capable of being highly secure—provided you follow cloud-specific best practices rather than carrying over assumptions from the pre-cloud era.

Below, we address four of the most persistent and damaging myths about cloud security and migration.

Myth 1: On-Premises Security Is More Robust Than Cloud Security

This is one of the most stubborn misconceptions in enterprise IT. The assumption that a physical, on-premises data center is inherently more secure than a cloud environment is fundamentally flawed.

Because cloud infrastructure is software-defined, it is far more malleable than physical hardware. It can be updated, audited, patched, and locked down in ways that physical infrastructure simply cannot match. Configuration changes that once required physical access and manual intervention can be automated, version-controlled, and rolled back in seconds.

That same malleability, however, is a double-edged sword. The leading causes of cloud security incidents are security misconfigurations and human error—not inherent weaknesses in the cloud platform itself. Misconfigured storage buckets, overly permissive IAM policies, and unpatched guest operating systems are the real culprits behind most cloud breaches.

Identity and Access Management (IAM) deserves particular attention. Compromised credentials are a leading vector for cloud data breaches, which is why a well-designed, least-privilege IAM policy must be a first-class concern in any cloud adoption strategy—not an afterthought.

The verdict: Cloud environments can be significantly more secure than on-premises equivalents, but only when cloud-native best practices are followed rigorously. Importing old security habits into a new environment undermines security by design.

Myth 2: Migrating to the Cloud Eliminates the Need for Backup and Recovery Plans

Cloud providers operate large, resilient infrastructure with redundancy built in—but that does not make your data immune to loss or corruption. The cloud still runs on physical servers. Your cloud service provider manages cooling, power, physical security, and hardware maintenance, but data backup and recovery remain your responsibility.

Consider the scenarios where a backup plan is essential even in the cloud:

• Application bugs that silently corrupt data over time
• Accidental deletions by administrators or automated scripts
• Ransomware and cyberattacks that encrypt or destroy data
• Misconfigured infrastructure-as-code that overwrites production data

The ability to restore from a known-good state requires deliberate backup configuration. No major cloud provider—AWS, Azure, or Google Cloud—automatically handles application-level backup for you unless you explicitly configure and pay for that capability. Treat backup and disaster recovery planning as a mandatory workstream in every cloud migration project.

Myth 3: Deploying to the Cloud Automatically Makes You Secure and Compliant

Cloud service providers invest heavily in certifications—SOC 2, ISO 27001, FedRAMP, PCI DSS, HIPAA eligibility, and more. This leads many organizations to assume that running workloads on a certified platform automatically satisfies their own compliance obligations. It does not.

Understanding the Shared Responsibility Model is non-negotiable for any cloud security strategy.

The Shared Responsibility Model Explained

Cloud providers divide security ownership clearly:

• Cloud provider responsibilities (security of the cloud): Physical facilities, host operating system, hypervisor/virtualization layer, global network infrastructure.
• Customer responsibilities (security in the cloud): Guest OS configuration and patching, application security, data encryption at rest and in transit, access control and IAM policies, network configuration (security groups, firewall rules), and meeting applicable regulatory requirements.

Compliance in a cloud environment requires continuous monitoring of both technical controls (encryption status, patch levels, network rules) and non-technical controls (access reviews, policy documentation, audit trails). A one-time configuration is not enough—cloud environments change constantly, and compliance posture must be actively maintained.

Myth 4: The Cloud Is Difficult to Audit

The fear that cloud environments are opaque black boxes that resist auditing is understandable for teams accustomed to on-premises tooling—but it is not accurate. In practice, well-configured cloud environments can offer better auditability than physical data centers.

Cloud platforms generate detailed, structured logs for virtually every action taken in the environment—API calls, authentication events, configuration changes, data access, and network flows. Native services such as AWS CloudTrail, Azure Monitor, and Google Cloud Audit Logs make it possible to reconstruct a complete history of who did what, when, and from where.

Bridging the gap between what the tooling can do and what auditors need requires investment in both training and process:

• Work directly with your audit team to understand what evidence they require and what their current pain points are.
• Map cloud-native logging and monitoring capabilities to those requirements.
• Automate evidence collection where possible to reduce manual effort and the risk of gaps.
• Use cloud security posture management (CSPM) tools to maintain a continuously updated view of compliance status.

The Foundation: Full-Stack Visibility

Each of the myths above shares a common thread: they arise when teams lack a complete, real-time view of what is happening across their cloud environment. Addressing this requires full-stack visibility—a comprehensive understanding of every layer of the cloud environment:

• Cloud infrastructure layer: Virtual networks, storage buckets, compute instances, and their configurations.
• Operating system layer: Patch levels, running processes, installed packages, and open ports on every workload.
• Application layer: Runtime behavior, dependencies, and exposed APIs.
• Data layer: Where sensitive data resides, how it is classified, and who has access to it.

Without visibility across all four layers, security teams are effectively operating blind. Misconfigurations go undetected, compliance drifts unnoticed, and the attack surface grows without anyone realizing it.

Practical Takeaways for DevOps and Security Teams

• Treat cloud security as a shared responsibility from day one. Define ownership boundaries clearly before a single workload migrates.
• Implement IAM least-privilege policies. Over-permissioned roles are one of the most common and consequential misconfigurations in cloud environments.
• Build backup and recovery into your migration plan. Decide on RPO/RTO targets and configure backup policies before you go live—not after an incident.
• Automate compliance monitoring. Use CSPM or equivalent tooling to continuously check configuration against your compliance baselines.
• Invest in cloud-specific training for audit teams. Help them understand what cloud-native logging and monitoring can provide, and align that to audit requirements.
• Prioritize visibility. You cannot secure what you cannot see. Ensure your security tooling covers every layer of the stack across all cloud accounts and regions.

Cloud migration is not inherently risky—but it is inherently different from managing on-premises infrastructure. Teams that acknowledge that difference, adopt cloud-native practices, and invest in visibility and shared responsibility will find the cloud to be a genuinely secure and auditable environment.

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.