What Is Cloud Computing: How the Internet Runs Your Software

On March 11, 2008, operators at Netflix experienced a major database corruption event that took down its DVD rental website for three days, affecting millions of subscribers. The incident convinced Netflix's engineering leadership that owning physical data centers was an existential risk. Over the following seven years, they migrated their entire streaming platform — which by 2015 was serving 65 million subscribers in 50 countries and accounting for 35 percent of all North American downstream internet traffic at peak hours — to Amazon Web Services. Today, Netflix runs almost entirely on AWS, using an estimated 100,000 server instances at peak. The company that could have been destroyed by a single hardware failure became one of the most reliable streaming services in the world by letting someone else manage the computers.

Netflix's migration is the most cited example of cloud computing's transformative potential, but the more instructive version of the story is not the triumphant endpoint. It is the seven years of painful, methodical migration work — services rebuilt, engineers retrained, architecture fundamentally redesigned — that stands between "we have physical servers" and "we run entirely in the cloud." Understanding cloud computing clearly requires understanding both what it enables and what it actually costs to use it well.

"Cloud computing is not a fad. The cloud is a long-term shift in the way technology is delivered and consumed. Every major technology company in the world is betting their future on it." — Marc Benioff

"We want to change the way people think about software. The cloud is not just about hosting your servers somewhere else — it's about building systems that can evolve continuously." — Werner Vogels

"Our industry does not respect tradition — it only respects innovation. Mobile-first and cloud-first is how we win." — Satya Nadella

"There is an enormous number of applications to be written, and the cloud enables a new generation of them that we just couldn't have imagined before." — Eric Schmidt

What Cloud Computing Actually Is

The definition sounds simple: cloud computing means accessing computing resources — servers, storage, databases, networking, software — over the internet instead of running them on hardware you own and manage yourself.

The "cloud" metaphor comes from old network diagrams where engineers drew the internet as a cloud shape to represent the abstraction between two communicating systems. The cloud was the bit you did not need to understand in detail, just trusted to route your data from here to there. Cloud computing extends that abstraction: the server infrastructure on which your application runs is now the bit you do not need to understand in detail, just trust to be available when you need it.

In practice, cloud computing means you are renting computing resources from a provider who owns massive physical data centers globally, and you access those resources through APIs and web interfaces rather than by buying hardware and installing it in your office or a colocation facility. You pay for what you use, scale up or down based on demand, and rely on the provider to handle physical maintenance, hardware failures, power, cooling, and network connectivity.

This model is fundamentally different from the pre-cloud model not just technically but economically. Buying physical servers requires capital expenditure upfront, typically depreciated over three to five years. Cloud computing converts that capital expenditure to operational expenditure — a monthly bill based on actual usage. For many organizations, particularly fast-growing ones with unpredictable workloads, this shift in cost structure is as valuable as any technical capability the cloud provides.

A History From Mainframes to AWS

The intellectual roots of cloud computing trace back to mainframe timesharing in the 1960s. Mainframes were enormously expensive, so universities and research institutions developed timesharing systems that allowed multiple users to share a single mainframe simultaneously. Each user had the experience of exclusive access, but the machine was shared. IBM's System/360, introduced in 1964, was central to this era. The concept of many users sharing a large, centrally managed computer over a network — paying for time on it rather than owning it — is structurally similar to cloud computing.

The internet era brought a transitional model in the late 1990s: application service providers (ASPs) and web hosting companies offered to run your software on their servers. Salesforce, founded in 1999, was significant because it delivered a complete, sophisticated CRM application entirely over the internet with no software to install. Marc Benioff's "the end of software" campaign was hyperbolic, but it captured something real about what the internet enabled for software delivery.

The pivotal moment came in 2006 when Amazon Web Services launched its Elastic Compute Cloud (EC2) service, which allowed anyone to rent virtual servers by the hour. Amazon had built an enormous internal infrastructure for its retail operations and recognized that the abstracted, on-demand model for computing resources had external market value. AWS EC2 and S3 (Simple Storage Service) launched at $0.10 per CPU hour and $0.15 per gigabyte per month respectively. The pricing seemed trivial, but the model was revolutionary: you could run server-scale computing for the cost of a few cups of coffee, with no contracts, no minimum commitments, and no physical hardware to manage.

Microsoft Azure launched in 2008. Google App Engine launched in 2008. Google Compute Engine, providing raw virtual machines similar to EC2, launched in 2012. By the early 2010s, the modern cloud landscape was established.

IaaS, PaaS, and SaaS: The Service Model Spectrum

The three-tier service model explains how cloud computing is offered at different levels of abstraction, and understanding the distinction matters for making good decisions about which services to use.

Infrastructure as a Service

Infrastructure as a Service (IaaS) provides raw computing infrastructure: virtual machines, storage, networking, and databases that you configure and manage yourself. AWS EC2, Azure Virtual Machines, and Google Compute Engine are IaaS examples.

When you use IaaS, you are responsible for everything from the operating system up: installing and patching the OS, installing application dependencies, configuring security, managing scaling, and handling application deployment. The provider is responsible for the physical hardware, the data center, and the virtualization layer that creates your virtual machine. You get flexibility and control at the cost of operational complexity.

Platform as a Service

Platform as a Service (PaaS) removes the server management burden by providing a fully managed application runtime environment. You provide the application code; the platform handles everything else. Heroku is the archetypal PaaS: you push your code with git push heroku main, and the platform builds, deploys, and runs it. AWS Elastic Beanstalk, Google App Engine, and Azure App Service offer similar models from the major providers.

PaaS accelerates development by eliminating infrastructure work, but it constrains you to the platform's supported languages, frameworks, and configurations. This works well for standard web applications and APIs. It becomes limiting when you need unusual system configurations, specialized software dependencies, or performance characteristics the platform does not support.

Software as a Service

Software as a Service (SaaS) delivers a complete application over the internet. You do not manage infrastructure or deploy code; you use the software through a browser or API. Salesforce is SaaS for CRM. Google Workspace is SaaS for productivity software. Slack is SaaS for team communication. Snowflake is SaaS for data warehousing.

The line between SaaS and "internet software" has blurred to the point of meaninglessness for consumer applications. For enterprise usage, the SaaS designation retains meaning because it emphasizes the delivered-and-managed nature of the service versus traditional software licensed and installed by the organization.

Dimension	IaaS	PaaS	SaaS
You manage	OS, runtime, apps, data	Apps and data only	Nothing (user only)
Provider manages	Hardware, network, virtualization	Hardware, OS, runtime	Everything
Example	AWS EC2, Azure VMs	Heroku, App Engine	Salesforce, Slack
Best for	Full control, custom stacks	Fast app deployment	Off-the-shelf software needs

Public, Private, Hybrid, and Multi-Cloud

Public cloud refers to cloud services delivered over the public internet, with infrastructure shared across many customers through virtualization. AWS, Azure, and Google Cloud are public clouds. Individual customers cannot see or access each other's resources — the shared infrastructure is logically isolated — but the same physical hardware serves many customers simultaneously.

Private cloud describes cloud infrastructure operated exclusively for a single organization. It provides the on-demand resource provisioning and automation of cloud computing but on dedicated hardware, either in the organization's own data center or in a colocation facility. VMware's vSphere and OpenStack are technologies used to build private clouds. Private cloud retains the capital expenditure model of traditional on-premise infrastructure while adding operational flexibility. Organizations typically choose private cloud for workloads where regulatory requirements, data sovereignty rules, or security policies make public cloud difficult.

Hybrid cloud combines public and private cloud environments, allowing workloads to move between them based on requirements. An organization might run sensitive patient data in a private cloud to meet HIPAA requirements while running its public-facing web applications in AWS for scalability. Hybrid cloud introduces integration complexity — the environments need to communicate securely and reliably — but provides architectural flexibility that neither model alone offers.

Multi-cloud describes using multiple public cloud providers simultaneously. An organization might use AWS for its primary application workloads, Google Cloud for its machine learning pipelines (where Google's TPU hardware and AI services are market-leading), and Azure for Microsoft Teams integration. Multi-cloud reduces vendor dependence and allows best-of-breed service selection but significantly increases operational complexity in managing multiple cloud environments, toolchains, and billing relationships.

The Major Providers Compared

Amazon Web Services launched six years before Azure and eight years before Google Cloud, and that head start compounded into the broadest service portfolio and largest customer base in the market. AWS offers over 200 distinct services spanning compute, storage, database, machine learning, networking, security, analytics, and application integration. Its global footprint includes 33 regions and 105 availability zones as of 2024. AWS's market share in the cloud infrastructure market runs consistently around 31 to 33 percent by revenue.

Microsoft Azure is the strongest enterprise cloud provider, largely because most large organizations already run significant Microsoft software — Active Directory, Exchange, SharePoint, Microsoft 365 — and Azure integrates deeply with those systems. Azure's hybrid cloud capabilities, particularly Azure Arc for managing resources across cloud and on-premise environments, are considered the strongest in the market. Azure commands approximately 23 to 25 percent of cloud infrastructure revenue.

Google Cloud Platform leads in specific technical areas: its data analytics and machine learning services, built on Google's internal infrastructure for processing internet-scale data, are widely considered superior. BigQuery for data warehousing, Vertex AI for machine learning operations, and Google Kubernetes Engine (the original managed Kubernetes service) are market leaders in their categories. Google Cloud runs approximately 11 to 13 percent of the market.

The differences in practice are less dramatic than competitive marketing suggests. For most standard web application workloads, all three providers deliver equivalent capability. The choice often comes down to existing relationships, specific service requirements, geographic needs, and pricing details for particular usage patterns.

Why Businesses Migrate to the Cloud

The financial case starts with the shift from capital to operational expenditure. A traditional on-premise server deployment requires purchasing hardware that will depreciate over three to five years, regardless of whether your workload grows, shrinks, or disappears. Cloud infrastructure scales with actual demand. A startup with ten users and a startup with a million users both start small and pay proportionally.

The operational case is equally compelling. Major cloud providers maintain data centers with power redundancy, backup generators, redundant cooling systems, and physical security controls that most organizations cannot justify independently. AWS's documented service level agreements guarantee 99.99 percent availability for many services. Building equivalent reliability on owned hardware requires substantial engineering investment in redundant systems and disaster recovery infrastructure.

The speed argument is significant for product development. Provisioning a new server on AWS takes minutes through the console or seconds through an API. Ordering, receiving, installing, and configuring physical hardware typically takes weeks. For organizations shipping software products rapidly, the ability to spin up new environments instantly removes a meaningful bottleneck.

Access to managed services is the final category of benefit, and for many organizations it is the most valuable. AWS RDS provides fully managed database infrastructure — automated backups, failover, patching, and scaling — that would require dedicated database administrators to replicate on-premise. AWS SQS provides managed message queuing. AWS Cognito provides managed user authentication. Each managed service replaces engineering work that does not differentiate a business's product.

The Shared Responsibility Security Model

Cloud security is one of the most misunderstood aspects of cloud adoption. A persistent misconception is that using AWS or Azure transfers security responsibility to the provider. This is incorrect, and the consequences of misunderstanding can be severe.

Cloud providers operate on a shared responsibility model: the provider is responsible for securing the infrastructure — the physical data center, the hypervisor, the network equipment — while the customer is responsible for securing their use of that infrastructure. The customer owns the security of their data, their application code, their identity and access management configuration, their network configuration, and their compliance obligations.

Most cloud breaches occur not because cloud providers fail to secure their infrastructure but because customers misconfigure their cloud resources. The 2019 Capital One breach, which exposed the personal data of approximately 100 million people, resulted from a misconfigured AWS Web Application Firewall that allowed an attacker to perform a server-side request forgery attack and access S3 storage buckets. AWS's infrastructure was not compromised; Capital One's configuration was incorrect.

This distinction matters for how organizations approach cloud security. The provider handles the parts of security you cannot control (the physical building, the virtualization layer). The customer must actively manage identity and access policies, encryption configurations, network security groups, vulnerability patching in applications and operating system layers they control, and monitoring for suspicious activity in their cloud environment.

Real Costs vs. On-Premise: The Hidden Variables

Cloud economics are frequently oversimplified in both directions: enthusiasts claim cloud is always cheaper, skeptics claim it always costs more at scale. The honest answer is that it depends on workload characteristics and what costs you are willing to count.

Dropbox's much-discussed partial repatriation from AWS is the clearest case for cloud skepticism at scale. The company disclosed in its 2017 IPO filing that it had spent $74.6 million over two years to repatriate approximately 90 percent of its data from AWS to its own data centers. At Dropbox's scale — storing hundreds of petabytes of data — the storage costs on AWS exceeded the capital and operational costs of building dedicated infrastructure. The company reported infrastructure expense savings of approximately $75 million over two years following the migration.

But Dropbox's situation is unusual. Their primary cost driver — storage at enormous scale — has one of the highest unit cost differentials between cloud and owned hardware. Most applications do not have this profile. And Dropbox retained AWS for compute capacity, recognizing that compute-on-demand provides value even when storage economics favor ownership.

For organizations that have not yet reached Dropbox's scale, on-premise economics typically look worse than cloud economics when all costs are counted honestly. The "hidden costs" of on-premise include hardware amortization, data center lease or ownership, power consumption, cooling, hardware maintenance contracts, network equipment and redundancy, and the staff time to manage all of it. Cloud pricing is more visible and more directly tied to actual usage.

Serverless Computing

Serverless is the logical extension of the platform-as-a-service model: you provide function code and the cloud provider executes it, scaling automatically from zero to millions of invocations per day without any server infrastructure management. AWS Lambda (launched 2014), Google Cloud Functions, and Azure Functions are the primary serverless offerings.

The economics of serverless are compelling for variable, event-driven workloads. You pay only for the actual execution time — measured in milliseconds — rather than for idle server capacity. An application that processes incoming webhook events might execute its code for a total of thirty seconds per day. On a traditional server, you would pay for 86,400 seconds of server time to be available for those thirty seconds of actual work. With Lambda, you pay for thirty seconds.

Serverless has genuine limitations. Functions have execution time limits (fifteen minutes maximum on Lambda). Cold starts — the latency introduced when a function scales from zero — can be problematic for latency-sensitive applications. Very high, consistent throughput can be more expensive on serverless than on reserved EC2 instances. And complex, stateful applications require architectural changes to work within serverless constraints.

The Coca-Cola Company's vending machine payment processing is a frequently cited serverless success story: the highly variable workload (drink purchases happen in spikes throughout the day, with long idle periods) mapped perfectly to serverless economics, dramatically reducing their infrastructure cost compared to running persistent servers for an inherently intermittent workload.

When Cloud Does Not Make Sense

Airbnb built its infrastructure on AWS from the beginning and has consistently scaled through significant growth without reverting to on-premise infrastructure — a validation that cloud-native architecture scales well. But not every organization's situation matches Airbnb's.

Workloads with extremely consistent, predictable resource requirements often run more cheaply on owned infrastructure. A database server that runs at 70 percent CPU utilization continuously, every day, never scaling significantly, is a candidate for reserved or owned hardware. Cloud spot pricing and reserved instance pricing narrow the gap, but very steady workloads can favor ownership.

Latency-sensitive applications requiring sub-millisecond processing may need on-premise infrastructure co-located with the data sources. High-frequency trading systems, industrial control systems, and some real-time processing applications cannot tolerate network latency to a cloud data center.

Data sovereignty and regulatory requirements create cloud constraints in some jurisdictions. Healthcare organizations subject to HIPAA requirements need to ensure cloud providers have Business Associate Agreements in place and that data does not traverse or reside in regions that violate patient data rules. Financial institutions in some countries face regulations limiting where financial data can be stored. While major cloud providers have addressed many of these requirements with compliance certifications and regional infrastructure, the constraints are real and must be evaluated.

Organizations with very limited internet connectivity — remote industrial sites, maritime operations, rural locations — cannot rely on internet-connected cloud infrastructure for operational systems that must function without connectivity.

Practical Takeaways

Cloud computing is the default deployment model for new applications in 2024, and for good reason. The flexibility, reliability, global reach, and managed service ecosystem that major providers offer represent genuine value that most organizations cannot replicate independently.

Understanding the model clearly means understanding that cloud is infrastructure you rent rather than own, that you pay for what you use rather than buying capacity in advance, that security is a shared responsibility with specific obligations on both sides, and that the economics depend heavily on workload characteristics and how honestly you count all costs.

The practical starting point for most organizations is a workload inventory: identifying which applications are running on what infrastructure, which are candidates for cloud migration, and which have characteristics — latency requirements, regulatory constraints, very predictable steady workloads — that might favor retaining on-premise or colocation hosting.

Migration, when pursued, benefits from a phased approach: non-critical workloads and development environments first, building cloud operational skills before tackling production systems. The biggest cloud migrations fail not because cloud infrastructure is inadequate but because organizations underestimate the operational learning curve and the architectural changes required to use cloud infrastructure well rather than merely running traditional on-premise patterns in a cloud environment.

Research on Cloud Migration Patterns: What the Data Shows

The academic and industry research on cloud migration has matured considerably since AWS launched EC2 in 2006. A decade of documented migrations provides evidence-based guidance on success factors, failure modes, and realistic cost expectations.

Michael Armbrust and colleagues (including Armando Fox, Rean Griffith, and David Patterson) at UC Berkeley published "A View of Cloud Computing" in Communications of the ACM in 2010, which became one of the most cited cloud computing papers with over 10,000 citations. The paper identified ten obstacles to cloud adoption and proposed remedies for each, including concerns about data confidentiality, data transfer bottlenecks, performance unpredictability, software licensing, and resource management. Reviewing the paper in 2024, most of these obstacles have been substantially addressed by provider investment: AWS Direct Connect and Azure ExpressRoute address network bottlenecks; dedicated instance types address performance isolation; and BYOL (bring your own license) models address licensing constraints. The remaining significant obstacles---data sovereignty and regulatory compliance---are those that resist purely technical solutions.

Gartner's "Magic Quadrant for Cloud Infrastructure and Platform Services" has tracked cloud provider maturity since 2015. The research methodology evaluates providers on Completeness of Vision and Ability to Execute, with annual updates capturing market movement. The 2023 edition found AWS, Azure, and Google Cloud as the only Leaders, with AWS maintaining the widest breadth of services (200+ compared to Azure's 150+ and GCP's 100+) and Azure showing the strongest enterprise customer satisfaction scores in regulated industries. Gartner's survey data from the accompanying "Critical Capabilities" report found that hybrid cloud scenarios---connecting cloud and on-premises workloads---showed the largest capability gap between leaders and challengers, with Azure leading in this category due to Azure Arc's management of resources across environments.

The McKinsey Global Institute's "Cloud's trillion-dollar prize is up for grabs" report (2021) analyzed the economic impact of cloud adoption across 700 companies in four industries. The research found that migrating on-premises workloads to cloud could yield $1 trillion in EBITDA value across Fortune 500 companies by 2030, with the majority of value coming not from infrastructure cost savings but from the ability to build digital products faster and respond to market changes more rapidly. The study found that organizations realizing the most cloud value had invested in rebuilding applications for cloud-native architectures rather than lift-and-shifting existing applications---a finding consistent with Netflix's re-architecture experience.

IDC's "Business Value of Cloud" research (2021, n=1,200 organizations across 11 countries) quantified cloud ROI more concretely: median annual benefits of $11.39 million per organization against costs of $2.03 million, yielding a five-year ROI of 219%. Critically, IDC found that 54% of the benefit came from increased developer productivity rather than infrastructure cost savings---developers at cloud-native organizations spent 23% less time on maintenance activities and 29% more time on new feature development than developers at on-premises organizations.

Real-World Cloud Migration Case Studies: Specific Outcomes and Lessons

The most instructive cloud case studies combine specific before/after metrics with honest accounts of the difficulty of migration---the successes and the mistakes.

Capital One's Full AWS Migration (2015-2020): Capital One CTO Rob Alexander announced the company's cloud-first strategy in 2015, becoming the first major US bank to commit publicly to exiting all owned data centers. By 2020, Capital One had decommissioned its last eight data centers and migrated entirely to AWS. The migration required regulatory work with the Office of the Comptroller of the Currency to establish cloud-acceptable security frameworks, retraining of 7,000 technology staff, and rebuilding core banking systems as microservices. Capital One's published outcomes included launching 18 developer-facing products that would not have been technically or commercially feasible on owned infrastructure, reducing the time to provision development environments from three weeks to minutes, and achieving regulatory compliance more efficiently through automated compliance tooling than through manual controls. Capital One's experience established that even highly regulated industries can operate entirely in public cloud with appropriate architectural and governance investment.

Spotify's Migration to Google Cloud (2015-2017): Spotify began migrating from private data centers to Google Cloud in 2015 and completed the migration in 2017, moving over 1,200 microservices and 5,000 Hadoop jobs. The migration was documented by Spotify infrastructure lead Nicolas Harteau and principal engineer Dave Zolotusky across multiple conference talks and blog posts. Specific outcomes: total infrastructure cost fell 17% despite 50% user growth over the migration period; time to provision a new production service environment fell from two weeks to 30 minutes; and data pipeline processing capacity grew 10x without proportional cost increases, enabled by Google Cloud's BigQuery and Dataflow services. Spotify's key lesson: retaining data engineers who understood the existing data infrastructure was as important as the technical migration itself.

Maersk's Recovery Through Cloud (2017): Danish shipping giant A.P. Moller-Maersk was one of the most prominent victims of the NotPetya cyberattack in June 2017, which destroyed 45,000 PCs, 4,000 servers, and 2,500 applications across 130 countries within hours. Maersk's technology chief Gavin Ashton later described reinstalling all of Microsoft's infrastructure over ten days, including sourcing the only surviving Active Directory domain controller from Ghana (where a power outage during the attack left one server turned off). Following the recovery, Maersk adopted a cloud-first strategy, migrating core operations to Microsoft Azure. The cloud migration provided both business continuity capabilities that on-premises infrastructure could not match and a forcing function for security improvements. Maersk's total NotPetya losses were estimated at $300 million; the subsequent cloud migration was framed as an insurance investment against comparable future events.

Airbnb's Cloud-Native Architecture at Scale: Airbnb built on AWS from its founding in 2008 and has grown to one of the larger AWS customers without significant repatriation. Airbnb's engineering blog has documented specific scaling challenges and cloud solutions across multiple posts. Their "Airflow" workflow management platform (open-sourced in 2016) was built on AWS infrastructure to orchestrate data pipelines processing billions of daily events. Their "Minerva" metric platform (documented in 2021) processes terabytes of event data daily using AWS EMR and S3 at a cost that would have been commercially prohibitive on owned hardware. Airbnb's case demonstrates that cloud-native architecture at scale is both technically feasible and economically sustainable for internet-scale consumer services, without the steady-workload economics that drove Dropbox's repatriation decision.

References

1. NIST. (2011). "The NIST definition of cloud computing." NIST Special Publication 800-145. National Institute of Standards and Technology.
2. Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., ... & Zaharia, M. (2010). "A view of cloud computing." Communications of the ACM, 53(4), 50-58.
3. Gartner. (2023). Magic Quadrant for Cloud Infrastructure and Platform Services. Gartner, Inc.
4. Hamilton, J. (2008). "On the cost of data center failures." Proceedings of the Conference on Innovative Data Systems Research (CIDR).
5. Netflix Technology Blog. (2016). "Completing the Netflix cloud migration." AWS re:Invent 2016 case study presentation.
6. Dropbox Engineering. (2018). "The magic pocket infrastructure." Dropbox Tech Blog. Retrieved from dropbox.tech.

Frequently Asked Questions

What is cloud computing in simple terms?

Cloud computing means accessing computing resources like processing power, storage, databases, and software over the internet instead of running them on your own hardware. When you use Gmail, stream a movie on Netflix, or store files in Dropbox, you are using cloud computing. The resources you are using run on remote servers owned and operated by cloud providers, and you access them through an internet connection from any device. The name comes from early diagrams that represented the internet as a cloud shape.

What are IaaS, PaaS, and SaaS?

These three service models describe different levels of cloud abstraction. Infrastructure as a Service (IaaS) provides raw computing infrastructure like virtual servers, storage, and networking, which you configure and manage yourself. Platform as a Service (PaaS) provides a development and deployment environment where you build and run applications without managing the underlying servers or operating systems. Software as a Service (SaaS) delivers complete software applications accessible through a browser, like Google Workspace or Salesforce, requiring no infrastructure or platform management at all. Most organizations use all three depending on their needs.

What is the difference between public, private, and hybrid cloud?

Public cloud services are delivered by providers like Amazon Web Services, Microsoft Azure, and Google Cloud over the public internet, with infrastructure shared across many customers using virtualization. Private cloud refers to cloud infrastructure operated exclusively for a single organization, offering greater control and security but at significantly higher cost. Hybrid cloud combines both, allowing organizations to run sensitive workloads on private infrastructure while leveraging public cloud for scalability and less sensitive applications. Multi-cloud describes using multiple public cloud providers simultaneously to avoid vendor lock-in or take advantage of each provider's strengths.

Why do businesses move to the cloud?

Businesses move to the cloud primarily to reduce capital expenditure on physical hardware, scale computing resources up and down based on actual demand, improve reliability through geographically distributed infrastructure, and access sophisticated managed services that would be impractical to build themselves. Cloud adoption also enables remote work by making applications and data accessible from anywhere with an internet connection. The shift from large upfront capital expenses to predictable operational expenses also improves cash flow flexibility, which is particularly valuable for growing companies.

Is cloud computing secure?

Cloud security is a shared responsibility between the provider and the customer. Major providers like AWS, Azure, and Google Cloud invest billions in physical security, network security, encryption, and compliance certifications that most individual organizations could not match on their own. However, customers are responsible for how they configure and use these services. Most cloud breaches occur not because of provider infrastructure failures but because of misconfigured access controls, weak credentials, insecure application code, or insufficient monitoring on the customer side.

What are the biggest cloud providers?

Amazon Web Services (AWS) is the market leader with the broadest portfolio of services and the largest global infrastructure footprint. Microsoft Azure is strong in enterprise markets and integrates deeply with the Microsoft product ecosystem that many organizations already use. Google Cloud Platform (GCP) leads in machine learning infrastructure and data analytics services. IBM Cloud and Oracle Cloud serve significant enterprise markets with deep integrations into their existing software ecosystems. Alibaba Cloud dominates in the Asia-Pacific region. The choice of provider often depends on existing technology relationships, specific service needs, geographic requirements, and pricing.

What does cloud computing cost?

Cloud computing costs follow a pay-as-you-go model where you pay for the resources you actually use rather than purchasing hardware upfront. Costs vary enormously based on the services used, data storage and transfer volumes, geographic region, and whether you commit to reserved capacity for discounts. Small applications can run for a few dollars per month. Enterprise workloads can cost millions annually. Cloud costs can be unpredictable if workloads are not carefully managed and monitored, and cloud waste due to unused or over-provisioned resources is a significant issue for many organizations.

When should a business not use the cloud?

Cloud computing is not always the right choice. Organizations with highly sensitive data subject to strict regulations may find it difficult to meet compliance requirements in a shared public cloud environment. Workloads with extremely consistent, predictable resource requirements can sometimes be cheaper to run on owned hardware than on pay-as-you-go cloud pricing. Latency-sensitive applications that require processing data in microseconds may need on-premise infrastructure. Organizations with limited internet connectivity or operating in regions with poor cloud provider coverage may also find on-premise solutions more practical.

What is serverless computing?

Serverless computing is a cloud execution model where developers write and deploy code without managing any server infrastructure. The cloud provider automatically provisions, scales, and manages the servers needed to run the code, and you are charged only for the actual execution time rather than for idle server capacity. Services like AWS Lambda, Google Cloud Functions, and Azure Functions enable this model. Serverless is excellent for event-driven workloads with variable or unpredictable demand, but has limitations for long-running processes or applications requiring fine-grained control over their execution environment.

How do businesses migrate to the cloud?

Most organizations take a phased approach to cloud migration rather than moving everything at once. A common starting point is migrating non-critical workloads and development environments to build cloud skills before tackling production systems. The main migration strategies are rehosting (moving applications to cloud servers with minimal changes), refactoring (optimizing applications to take advantage of cloud-native services), and rebuilding (rewriting applications from scratch for the cloud). Successful migrations require careful planning, thorough testing, a rollback strategy, and investment in training staff on cloud tools and practices.