Cloud computing has rapidly evolved over the past decade, transforming how organizations build, deploy, and scale applications. In this article, we explore the state of cloud computing in 2025, examining the latest trends, technologies, and best practices that are shaping the future of software development and infrastructure management.

0. Self-hosted servers

In 2025, the concept of Self-hosted infrastructure on physical servers is largely a thing of the past for most organizations. While some niche use cases still exist, the vast majority of software delivery and infrastructure management has moved to cloud-based solutions.

Just so you know, you can technically build or buy a physical server and run it at your home or office. This was a common practice years ago. Though by 2025, it’s more of a relic than a reality.

1. Virtual Machines

For a short period, many companies transitioned from on-premises hardware to renting virtual machines (VMs) in the cloud, seeking flexibility and reduced maintenance. However, this approach has become uncommon for most software delivery scenarios. The industry has largely moved beyond VMs as the primary method for deploying applications, favoring more modern, scalable, and efficient cloud-native solutions.

2. PaaS (Platform as a Service)

Platform as a Service (PaaS) is a category of cloud computing that provides developers with a ready-to-use platform to build, deploy, and scale applications without managing the underlying infrastructure. PaaS solutions abstract away server management, operating systems, and runtime environments, allowing teams to focus on writing code and delivering features faster.

Why?

PaaS emerged around the 2010s as a response to the growing complexity of deploying and maintaining applications. As cloud adoption increased, developers sought ways to avoid repetitive infrastructure tasks (like provisioning servers, configuring networks, and patching OSes). PaaS platforms automate these concerns, offering a streamlined developer experience and accelerating time-to-market.

What Does PaaS Offer?

• Build: Automated build pipelines, dependency management, and environment configuration.
• Deploy: Simple deployment via git push, CLI, or web UI.
• Scale: Effortless horizontal and vertical scaling, load balancing, and monitoring.
• Managed Services: Integrated databases, caching, messaging, and more.
• Security & Compliance: Built-in security patches, SSL, and compliance features.

Real Use Cases

• Rapid prototyping and MVPs
• SaaS product development
• Internal tools and APIs
• Event-driven applications
• Startups and small teams with limited DevOps resources

Limitations

• Limited control over underlying infrastructure
• Vendor lock-in (proprietary APIs and deployment models)
• Customization constraints (e.g., OS-level tweaks, custom networking)
• Cost can grow with scale or advanced features
• Not ideal for legacy workloads or highly specialized requirements

Popular PaaS Examples & Comparison

Platform	Language Support	Free Tier	Scaling	Notable Features	Typical Use Cases
Heroku	Node, Python, Ruby, Go, Java, PHP, Scala	Yes	Dynos (auto/manual)	Add-ons marketplace, git deploy	MVPs, APIs, web apps
Google App Engine	Python, Node, Java, Go, PHP, Ruby, .NET	Yes	Auto (flex/standard)	Deep GCP integration, auto-scaling	Web/mobile backends, APIs
Railway	Any (Dockerfile, Buildpacks)	Yes	Auto/manual	Simple UI, instant deploys	Prototypes, microservices
Render	Node, Python, Go, Ruby, Docker	Yes	Auto/manual	Static sites, background workers	Full-stack apps, static sites
Azure App Service	.NET, Node, Python, Java, PHP	Yes	Auto/manual	Azure integration, staging slots	Enterprise apps, APIs
AWS Elastic Beanstalk	Node, Python, Java, Go, Ruby, .NET, PHP	Yes	Auto/manual	AWS integration, environment configs	Web apps, microservices

Example Highlights

• Heroku: Known for its simplicity and developer-friendly workflow. Great for quick launches and prototyping, but can become expensive at scale.
• Google App Engine: Offers deep integration with Google Cloud services and strong auto-scaling. Good for apps that need to leverage GCP’s ecosystem.
• Railway: Focuses on ease of use and supports any language via Docker or Buildpacks. Ideal for rapid prototyping and microservices.
• Render: Combines PaaS with static site hosting and background jobs. Good for full-stack apps and static content.
• Azure App Service: Integrates tightly with Microsoft Azure, supports enterprise workloads, and offers advanced deployment options.
• AWS Elastic Beanstalk: Provides a balance between control and convenience, with access to AWS’s vast infrastructure and services.

PaaS platforms continue to evolve, offering more flexibility, integrations, and developer-centric features. Choosing the right PaaS depends on your team’s language preferences, scalability needs, and integration requirements.

3. FaaS (Function as a Service / Serverless)

Function as a Service (FaaS), commonly known as serverless computing, is a cloud computing model where developers write individual functions that are executed in response to specific events or requests. Unlike traditional server-based models, FaaS abstracts away all server management—developers simply deploy code, and the cloud provider handles provisioning, scaling, and execution.

Concept

• Event-driven: Code is triggered by events such as HTTP requests, file uploads, database changes, or scheduled timers.
• No server management: Developers do not manage or provision servers; everything is handled by the provider.
• Ephemeral execution: Functions run only when needed and scale automatically with demand.

Why?

FaaS emerged in the mid-2010s as a way to further simplify cloud development, reduce operational overhead, and enable highly scalable, cost-efficient architectures. It allows teams to focus on business logic, paying only for actual usage (per execution or compute time), rather than for idle infrastructure.

When Did FaaS Appear?

The first major FaaS platform, AWS Lambda, launched in 2014. It was soon followed by Azure Functions, Google Cloud Functions, and other providers, each expanding the capabilities and integrations of serverless computing.

What Does FaaS Offer?

• Automatic scaling: Instantly scales to handle any number of requests.
• Pay-per-use: Billing is based on actual function execution time and resources consumed.
• Integrated event sources: Easily connect to cloud services, APIs, databases, and more.
• Stateless execution: Each function invocation is independent, making it easy to parallelize workloads.

Ideal Use Cases

• REST APIs and microservices
• Event-driven data processing (e.g., image/video processing, ETL jobs)
• Real-time file or data transformation
• Scheduled tasks (cron jobs)
• Chatbots and notification systems
• IoT data ingestion and processing
• Backend for mobile/web applications

Limitations

• Execution time limits: Functions typically have a maximum execution time (e.g., 15 minutes for AWS Lambda).
• Cold starts: Initial invocation after inactivity can be slower due to environment spin-up.
• Statelessness: Functions cannot maintain state between invocations (external storage required).
• Resource limits: Memory, CPU, and package size are constrained.
• Debugging and monitoring: Can be more complex than traditional apps.
• Vendor lock-in: Proprietary event models and APIs can make migration difficult.

Popular FaaS Examples & Comparison

Platform	Language Support	Max Execution Time	Scaling	Notable Features	Typical Use Cases
AWS Lambda	Node, Python, Go, Java, .NET, Ruby, Custom	15 min	Auto	Huge event source ecosystem, Step Functions	APIs, ETL, automation
Azure Functions	C#, JavaScript, Python, Java, PowerShell, Custom	60 min (Premium)	Auto	Durable Functions, Logic Apps	APIs, workflows, automation
Google Cloud Functions	Node, Python, Go, Java, .NET, Ruby	9 min	Auto	Deep GCP integration, EventArc	APIs, data processing
Cloudflare Workers	JavaScript, Rust, C, C++, Python (beta)	30 sec (unbound: 15 min)	Edge (global)	Runs at edge, super low latency	Edge APIs, webhooks
IBM Cloud Functions	Node, Python, Swift, PHP, Java	10 min	Auto	Based on Apache OpenWhisk	APIs, automation

Example Highlights

• AWS Lambda: The most mature and widely adopted FaaS platform, with deep AWS integration and support for complex workflows via Step Functions.
• Azure Functions: Offers advanced workflow orchestration (Durable Functions), strong enterprise integration, and long execution times on premium plans.
• Google Cloud Functions: Focuses on simplicity and tight integration with Google Cloud services and EventArc for event-driven architectures.
• Cloudflare Workers: Runs code at the edge for ultra-low latency, ideal for APIs, webhooks, and content manipulation close to users.
• IBM Cloud Functions: OpenWhisk-based, supports a wide range of languages and integrations.

Low-Code/Workflow Orchestration

• Step Functions (AWS): Visual workflow service to coordinate multiple Lambda functions and services.
• Azure Logic Apps: Drag-and-drop workflow automation integrating with Azure Functions and external services.
• Google Workflows: Orchestrates Google Cloud Functions and services.
• N8N: Open-source workflow automation tool that can trigger FaaS functions and connect APIs.

FaaS and serverless architectures are ideal for building scalable, event-driven systems with minimal operational overhead. However, they require careful consideration of cold starts, statelessness, and vendor-specific limitations.

4. Containers

Containers have become the backbone of modern cloud-native development, offering a standardized way to package, deploy, and run applications across diverse environments. This section explores the core technologies and practices in deploying containerized workloads.

4.1. Docker

Docker is an open-source platform that enables developers to package applications and their dependencies into lightweight, portable containers. Containers ensure consistency across environments, making it easy to move applications from development to production without the classic “it works on my machine” problem. Unlike virtual machines, containers share the host OS kernel, resulting in faster startup times and lower resource usage.

A typical Docker workflow involves writing a Dockerfile to define the app environment, building an image, and running containers from that image. Docker images can be shared via registries like Docker Hub, supporting collaboration and reproducibility. Docker is widely used for microservices, CI/CD pipelines, and simplifying local development.

While Docker offers many advantages—such as consistency, efficiency, and scalability—it also comes with challenges like managing persistent storage, networking, and security. Despite these, Docker has become the foundation for modern DevOps and cloud-native practices, often used alongside orchestration tools like Kubernetes.

4.2. Docker-compose

Docker Compose is a tool that allows you to define and manage multi-container Docker applications using a simple YAML file. With Compose, you can specify all the services, networks, and volumes your application needs, making it easy to spin up complex development or testing environments with a single command. This is especially useful for microservices architectures, where multiple containers (such as databases, caches, and app servers) need to work together seamlessly.

By running docker-compose up, developers can orchestrate the startup and configuration of all defined services, ensuring consistency and simplifying local development, integration testing, and even some production deployments. While Docker Compose is most commonly used in development and testing, it can be used in production for simpler workloads, though larger-scale deployments typically rely on orchestration platforms like Kubernetes.

4.3. Container registries

Container registries are centralized repositories where Docker images and other container artifacts are stored, managed, and shared. Public registries like Docker Hub and GitHub Container Registry make it easy to distribute images across teams and organizations, while private registries (such as AWS ECR, Google Container Registry, or Harbor) offer additional security and access control for enterprise use. Registries play a crucial role in CI/CD pipelines, enabling automated builds, versioning, and deployment of containerized applications to any environment.

By pulling images from a registry, developers and deployment systems can ensure they are running the correct, trusted version of an application. Registries also support image scanning for vulnerabilities and can enforce policies to improve security and compliance in the software supply chain.

4.4. Cloud-native services for Containers: AWS ECS, AWS Fargate, Google Cloud Run, Azure Container Instances

Cloud-native container services provided by major cloud vendors make it easy to run and manage containers without having to maintain your own infrastructure. Services like AWS ECS (Elastic Container Service), AWS Fargate, Google Cloud Run, and Azure Container Instances abstract away much of the operational complexity, allowing you to deploy containers directly from registries and scale them automatically based on demand.

These platforms are ideal for teams that want the benefits of containerization—portability, scalability, and isolation—without the overhead of managing servers or orchestrators. They support a variety of use cases, from running stateless web applications and APIs to background jobs and microservices, and are often used as a simpler alternative to full Kubernetes clusters for many production workloads.

These managed container services are often more cost-effective than running a full Kubernetes cluster, as you only pay for the resources your containers consume and avoid the overhead of managing control plane infrastructure. When these services scale, the cloud provider automatically provisions additional resources and instances to handle increased demand, ensuring your applications remain responsive without manual intervention.

4.5. K8S (Kubernetes)

Kubernetes (K8s) has become the industry standard for orchestrating containers at scale, powering everything from small startups to the largest cloud-native enterprises. It was originally developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF). Kubernetes automates the deployment, scaling, and management of containerized applications, making it possible to run complex, distributed systems with high availability and resilience.

Main Kubernetes Components:

• Cluster: A Kubernetes cluster is the overall system that brings together a control plane (which manages the cluster) and a set of worker nodes (which run your applications). The control plane handles scheduling, scaling, and maintaining the desired state, while nodes provide the compute resources.

• Node: Each node is a physical or virtual machine that runs containerized workloads. Nodes are managed by the control plane and host the necessary services to run pods, such as the container runtime and kubelet agent.

• Pod: The smallest deployable unit in Kubernetes, a pod encapsulates one or more tightly coupled containers that share storage, network, and configuration. Pods are ephemeral and are replaced if they fail or are rescheduled.

• Namespace: Namespaces provide a way to divide cluster resources between multiple users or teams. They help organize and isolate resources, making it easier to manage environments like development, staging, and production within a single cluster.

• Service: A service is an abstraction that defines a logical set of pods and a policy by which to access them. Services enable load balancing and provide a stable network endpoint, even as pods are created and destroyed.

• Ingress: Ingress manages external access to services within the cluster, typically HTTP and HTTPS traffic. It provides routing, SSL termination, and can enforce security policies, making it easier to expose applications to the outside world.

• Volume: Volumes provide persistent storage for pods, allowing data to survive pod restarts and rescheduling. Kubernetes supports various volume types, including local disks, network storage, and cloud provider solutions.

• ConfigMap & Secret: ConfigMaps are used to inject configuration data into pods, while Secrets are designed for sensitive information like passwords or API keys. Both allow you to decouple configuration from application code and manage it securely.

• Helm: Helm is the package manager for Kubernetes, enabling you to define, install, and upgrade complex applications using reusable charts. Helm simplifies the management of Kubernetes manifests and makes deploying applications more consistent and repeatable.

4.6. Cloud-native services for Kubernetes: (GKE, EKS, AKS)

Major cloud providers offer managed Kubernetes services: Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), and Azure Kubernetes Service (AKS).Created to simplify cluster setup, maintenance, and scaling. These services handle the control plane, upgrades, and security patches, letting teams focus on deploying and managing workloads rather than infrastructure.

Pricing for managed Kubernetes services typically includes a fee for the control plane (which may be free or low-cost for small clusters) and charges for the underlying compute, storage, and network resources used by your workloads. These platforms also integrate tightly with other cloud services, such as managed databases, storage, monitoring, and identity management, making it easier to build secure and scalable cloud-native applications.

4.7. Deploy to cloud

Deploying containerized workloads to the cloud can be managed through a variety of tools and approaches, each offering different levels of automation, flexibility, and control. Infrastructure as Code (IaC) tools like Terraform and Pulumi allow you to define cloud infrastructure—including Kubernetes clusters, networking, and storage—in code, making deployments repeatable, versioned, and auditable. These tools support multiple cloud providers and are widely used for provisioning and managing both infrastructure and application resources.

For Kubernetes-specific deployments, tools like Kustomize and Helm help manage and customize Kubernetes manifests, enabling teams to deploy complex applications with reusable, parameterized configurations. Helm, in particular, is popular for packaging applications as charts, while Kustomize allows for overlaying environment-specific changes. In addition, many teams use CI/CD pipelines (e.g., GitHub Actions, GitLab CI, ArgoCD, Flux) to automate the build, test, and deployment process, ensuring consistent and reliable releases.

4.8. Pros and cons

Pros:

• Portability: Containers run consistently across different environments, from local development to production, and across cloud providers.
• Scalability: Kubernetes automates scaling up and down based on demand, making it easy to handle variable workloads.
• High availability: Built-in self-healing, rolling updates, and failover mechanisms ensure resilient applications.
• Ecosystem: A rich ecosystem of tools and integrations supports monitoring, security, networking, and CI/CD.
• Resource efficiency: Containers share the host OS kernel, resulting in lower overhead compared to virtual machines.

Cons:

• Complexity: Kubernetes has a steep learning curve and requires expertise to operate and troubleshoot effectively.
• Operational overhead: Managing clusters, upgrades, and security patches can be time-consuming, even with managed services.
• Cost: While containers are efficient, running and maintaining clusters (especially at scale) can become expensive.
• Debugging: Distributed systems can make debugging and tracing issues more challenging.
• Overkill for simple apps: For small or straightforward projects, containers and Kubernetes may introduce unnecessary complexity compared to simpler deployment models.

5. Comparison of PaaS, FaaS, and Containers

Choosing between PaaS, FaaS, managed container services (like ECS, Fargate, Cloud Run), and Kubernetes depends on your application’s requirements, team expertise, scalability needs, and operational preferences. Each model offers unique trade-offs in terms of use cases, scalability, complexity, cost, and vendor lock-in.

Use Cases

• PaaS: Best for rapid prototyping, SaaS products, web apps, and APIs where speed and simplicity are priorities. Ideal for startups and small teams with limited DevOps resources.
• FaaS: Suited for event-driven workloads, microservices, automation, and applications with unpredictable or spiky traffic. Great for APIs, data processing, and backend tasks that can be split into discrete functions.
• Managed Containers (ECS, Fargate, Cloud Run, etc.): Good for stateless web services, APIs, background jobs, and microservices that need more control than PaaS but less complexity than Kubernetes.
• Kubernetes: Designed for complex, distributed systems requiring high scalability, resilience, and flexibility. Used by organizations with mature DevOps practices and a need for multi-cloud or hybrid deployments.

Scalability

• PaaS: Automatic scaling, but may have platform-specific limits or require manual intervention for advanced scenarios.
• FaaS: Instantly and automatically scales to zero and up, handling massive spikes in traffic with minimal configuration.
• Managed Containers: Scales containers up and down based on demand, with some manual tuning possible.
• Kubernetes: Highly customizable, supports advanced scaling strategies (horizontal/vertical pod autoscaling, custom metrics), but requires configuration and monitoring.

Complexity

• PaaS: Lowest complexity; abstracts away infrastructure and most operational concerns.
• FaaS: Low to moderate; no server management, but requires rethinking app architecture for stateless, event-driven design.
• Managed Containers: Moderate; more control over environment and networking, but less operational overhead than Kubernetes.
• Kubernetes: Highest complexity; steep learning curve, requires expertise in cluster management, networking, and security.

Cost

• PaaS: Pay for resources allocated, such as dynos or instances. For example, Heroku’s hobby dynos start at around $7/month, while production plans can range from $25 to $500+/month per dyno. Costs can become significant at scale or with advanced features.
• FaaS: Pay-per-use (per execution and compute time). AWS Lambda, for instance, charges $0.20 per 1 million requests and $0.00001667 per GB-second of compute time. This can be very cost-effective for bursty or low-traffic workloads, but costs can rise with high sustained usage.
• Managed Containers: Pay for container resources used. AWS Fargate, for example, charges about $0.04048 per vCPU-hour and $0.004445 per GB-hour. This is often more cost-effective than running full clusters, but less granular than FaaS.
• Kubernetes: Pay for all underlying infrastructure (nodes, storage, network) and, in managed services, a control plane fee (e.g., GKE charges $0.10 per cluster per hour, while EKS charges $0.10 per hour per cluster). Operational costs can be significant at scale, especially for large clusters or high-availability setups.

Vendor Lock-in

• PaaS: High; proprietary APIs and deployment models can make migration difficult.
• FaaS: High; event models and integrations are often provider-specific.
• Managed Containers: Moderate; containers are portable, but service features and networking may be cloud-specific.
• Kubernetes: Low; open standard with broad support across clouds and on-premises, though managed service features may vary.

Feature Comparison Table

Model	Use Cases	Scalability	Complexity	Cost	Vendor Lock-in	Example Providers/Services
PaaS	Web apps, APIs, SaaS	Auto	Low	Medium-High	High	Heroku, App Engine, Azure App Service
FaaS	Event-driven, APIs, ETL	Auto (to zero)	Low-Med	Low-High	High	AWS Lambda, Azure Functions, GCF
Managed Containers	Web/API, jobs, microservices	Auto/Manual	Medium	Medium	Medium	ECS, Fargate, Cloud Run, ACI
Kubernetes	Complex, distributed	Customizable	High	Medium-High	Low	GKE, EKS, AKS, self-hosted

Summary

• PaaS is best for teams seeking simplicity and fast time-to-market, but may hit limits as needs grow. It is ideal for projects where infrastructure management is not a priority and rapid iteration is needed. However, as applications scale or require more customization, teams may encounter platform constraints, higher costs, or vendor lock-in.

• FaaS offers unmatched scalability and cost efficiency for event-driven workloads, but can be restrictive for stateful or long-running tasks. It excels in scenarios with unpredictable or spiky traffic, such as APIs, automation, and data processing pipelines. The stateless nature and execution time limits of FaaS require careful architectural planning, and deep integration with provider-specific services can make migration challenging.

• Managed container services strike a balance between control and simplicity, ideal for most stateless applications. They provide more flexibility than PaaS or FaaS, allowing custom runtimes, networking, and scaling policies, while abstracting away much of the operational burden. These services are well-suited for teams that want to leverage containers without managing clusters, but may still face some cloud-specific limitations.

• Kubernetes provides maximum flexibility and power for large-scale, complex systems, but comes with significant operational overhead. It is the platform of choice for organizations with advanced DevOps practices, multi-cloud or hybrid needs, and workloads that demand fine-grained control over deployment, scaling, and networking. While Kubernetes enables portability and avoids vendor lock-in, it requires substantial expertise and investment in automation, monitoring, and security.

In practice, many organizations adopt a hybrid approach, combining PaaS for simple apps, FaaS for event-driven components, managed containers for scalable services, and Kubernetes for mission-critical or highly customized workloads. The optimal solution depends on your team’s skills, business goals, and the specific requirements of each application. Regularly reassessing your architecture as your needs evolve will help ensure you are leveraging the best mix of cloud technologies for your organization.