Exploras

Cloud-Native and AI Ecosystems: Journey of Exploration

Tag: Cloud Adoption

Strategies, models, and practices organizations use to adopt and scale cloud computing effectively

  • Cloud Service Models

    Cloud Service Models

    In this post, we introduce the definition of service models according to NIST. The concept of a service model is central to planning a cloud adoption process. In 2011, NIST classified three service models for cloud resource management:

    • Software as a Service (SaaS)
    • Platform as a Service (PaaS)
    • Infrastructure as a Service (IaaS)
    • Extended Service Models (BPaaS)

    Cloud Service Models Explained

    In this chapter, we introduce the definition of service models according to NIST. The concept of a service model is central to planning a cloud adoption process. In 2011, NIST classified three service models for cloud resource management:

    • Software as a Service (SaaS)
    • Platform as a Service (PaaS)
    • Infrastructure as a Service (IaaS)

    Software as a Service (SaaS)

    The consumer can use the provider’s applications running on a cloud infrastructure.

    These applications are accessible from various client devices through a thin client interface, such as a web browser (e.g., web-based email) or an application program interface (API).

    The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, storage, or even individual application functionalities, except for limited user-specific application settings.

    Platform as a Service (PaaS)

    The capability provided to the consumer is to deploy onto the cloud infrastructure applications created or acquired using programming languages, libraries, services, and tools supported by the provider.

    The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems, or storage, but has control over the deployed applications and, possibly, configuration settings for the application hosting environment.

    Infrastructure as a Service (IaaS)

    The capability provided to the consumer is to provision processing, storage, networking, and other fundamental computing resources where the consumer can deploy and run arbitrary software, which can include operating systems and applications.

    The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications and, possibly, limited control of selected networking components (e.g., host firewalls).

    Service Model Insights

    Service models implicitly introduce a responsibility matrix dictated by contractual agreements specific to each model.

    A comparative analysis of service models and the ISO/OSI stack helps clarify the impact of the service model on the cloud adoption journey.

    • IaaS: The cloud provider typically ensures service availability up to layer 4 of the ISO/OSI stack (Transport layer).
    • PaaS: The guaranteed level varies between layer 4 and layer 5, sometimes extending to layer 6.
    • SaaS: Services are typically maintained at layer 6, and in specific cases where no user interaction occurs through a web or mobile application, it can reach layer 7.

    The division of responsibility between the cloud provider and the consumer plays a crucial role in defining the service model.

    Another key aspect to consider is scalability expectations in the cloud. Opting for an IaaS model does not necessarily take full advantage of the cloud’s scalability capabilities. In fact, scalability responsibility falls on the hosted content within the IaaS service, which may result in classical scalability limitations, potentially leading to higher operational costs rather than reduced expenses.

    While it is relatively easy to classify cloud resources managed through IaaS models, this becomes more complex with PaaS and SaaS models.

    Many complex cloud resources are delivered via hybrid service models, such as PaaS/IaaS or PaaS/SaaS.

    For example:

    • Recognizable SaaS solutions include Salesforce CRM, Microsoft 365, and Google Workspace, all of which offer complex suites of SaaS-based solutions.

    Below, we provide a deeper insight into each service model.

    IaaS

    Classic IaaS services include basic network resources (firewalls, VPNs, etc.).

    Virtual machines (VMs) not managed by the cloud provider also fall under IaaS. This is one of the most comparable cloud services to traditional IT system management, making it one of the most considered options in lightweight cloud adoption strategies.

    The cloud provider guarantees hardware operation, including both physical and logical security.

    The security responsibility is typically covered up to layer 4 of the ISO/OSI stack.

    The consumer is responsible for configuring and managing the operating system and any additional application software installed on the VM.

    A hybrid case between IaaS and PaaS is a VM with a managed operating system. Here, the provider manages OS updates and security patches autonomously but does not enforce version changes until official support ends. However, the provider does not assume responsibility for third-party applications installed by the consumer.

    IaaS/PaaS and PaaS

    PaaS is the first service model that truly defines cloud computing, though finding purely PaaS-classifiable resources can be challenging.

    Many cloud resources use hybrid service models (IaaS/PaaS), including Kubernetes and Red Hat OpenShift.

    Some databases are offered as PaaS services, where the consumer only defines:

    • DDL (Data Definition Language): Schema structures, stored procedures, functions, and user permissions.
    • DML (Data Manipulation Language): CRUD (Create, Read, Update, Delete) operations.

    Notable PaaS database services include Azure Database and AWS Aurora.

    Other pure PaaS services include Azure Functions and AWS Lambda.

    In a pure PaaS model, the consumer relinquishes control over the cloud resource’s state, which is contractually managed by the provider. The responsibility matrix is clear: the consumer is only responsible for the functional and application layer.

    SaaS

    SaaS is one of the most widely adopted cloud service models in the public cloud.

    Consider the early free webmail providers, available for more than two decades.

    SaaS encompasses social media services and widely used B2C sales platforms, some of which are expanding into enterprise solutions (e.g., WhatsApp for Business).

    The boundary between SaaS and PaaS is sometimes ambiguous, and even cloud providers themselves may struggle to classify services technically, often relying on marketing terminology instead.

    Examples of Paid SaaS Services

    Azure:

    • Microsoft 365: A well-known SaaS application that allows users to access cloud-based productivity tools such as email, calendars, and document management.
    • Microsoft Dynamics.
    • Microsoft Business Central.
    • Microsoft Teams.
    • Microsoft Chat GPT: One of the most widespread AI-driven prompt services powered by OpenAI.
    • Microsoft Copilot: A productivity acceleration service leveraging OpenAI technology.

    AWS:

    • AWS Elastic Beanstalk: A plug-and-play platform supporting multiple programming languages and environments.

    Google Cloud Platform (GCP):

    • Google Mail: One of the most widely used free and paid email services.
    • Google Workspace: A suite of productivity tools used worldwide.
    • Google Gemini: Emerging as an AI-integrated service within Google’s productivity offerings, with promising integration into BigQuery .
    • BigQuery: Google’s serverless, multi-cloud data warehouse , offered as a SaaS solution. It integrates machine learning algorithms to provide real-time insights into business processes.

    This classification helps organizations understand which service models best fit their operational and strategic needs when adopting cloud computing.

    Ambiguity in Service Model Interpretation

    In personal-use solutions, many cloud services function as pure SaaS, offering a fully managed experience with minimal user-specific customization.

    However, in enterprise environments, these services evolve into hybrid models, providing organizations with extensive customization and control over service configurations.

    While activating a solution like Microsoft 365 or Google Workspace may be simple, its enterprise-level deployment introduces significant complexity. Advanced setup demands strong networking and security expertise to ensure full-service functionality while maintaining corporate compliance.

    Additionally, enterprise versions often offer API-based integrations, allowing deep customization and automation. As a result, responsibility for service management shifts from solely the provider to a shared responsibility model, where both the provider and the consumer play key roles in governance and maintenance.

    Extending Cloud Service Models

    Cloud Service Model
    Extended Cloud Service Model

    In the initial chapters of this section, we introduced fundamental concepts regarding cloud service and distribution models.

    IaaS, PaaS, and SaaS—delivered via public cloud providers—are the primary service models offered by major cloud vendors.

    However, hybrid cloud and cloud-native solutions are evolving, creating new service opportunities.

    For example, as a software provider, I may have shifted from installing my product on customers’ local machines to offering it as a web service, with only lightweight local applications mimicking the traditional desktop experience.

    In parallel, we have defined the key roles in the cloud supply chain and the cloud consumption chain, introducing the responsibility matrix (RACI) as a simplified representation of service responsibility management.

    The cloud is continuously evolving, introducing increasingly complex cloud resources designed to address specific consumer needs—sometimes creating new demands through marketing strategies.

    For example, instead of offering my software as a web service, I might distribute it as a cloud marketplace product:

    • The customer downloads my product, which is automatically deployed in their cloud environment.
    • The software runs within their cloud but sends me usage analytics on how the customer interacts with my service.

    Alternatively, I might offer a dedicated cloud ecosystem for each client, running on my own cloud infrastructure.

    As these hybrid models emerge, cloud providers are launching more specialized solutions to prevent customer migration based on cost optimization alone.

    At the center of this strategy is data.

    If I offer a unique service that no competitor provides—even at an acceptable price—my customers will find it very difficult to switch to another provider.

    To reinforce customer retention, public cloud providers are introducing hybrid PaaS/SaaS services that are native to their specific cloud platform and not easily replicable on other clouds.

    Impact on IT Operations and Organizational Restructuring

    We have already seen how cloud consumption structures introduce specialized roles, leading to a reorganization of IT operations.

    Figure 30 attempts to illustrate how the cloud service market is adapting to this growing complexity.

    In Figure the term “hyperscaler” is used to represent a primary public cloud provider.

    Hyperscalers collaborate with telecommunications providers, ensuring the first level of service—data transport, which corresponds to the lower layers of the ISO/OSI model.

    Above this, we find:

    • The three primary cloud service models (IaaS, PaaS, SaaS).
    • Infrastructure as Code (IaC), enabling automated cloud ecosystem lifecycle management.
    • DevSecOps operations, which integrate with the Cloud Architecture COE and FinOps COE to mediate service deployment.

    What If an Organization Has a Low Cloud Maturity Level?

    Some enterprises may be unable to fully implement cloud-native operations, due to:

    • Low cloud maturity
    • Cultural gaps that cannot be easily addressed within the budget of a single business project

    In these cases, cloud services allow organizations to outsource the creation and management of a dedicated cloud ecosystem tailored to a specific business project.

    This is known as Business Process as a Service (BPaaS).

    BPaaS allows businesses to adopt cloud services incrementally, while preparing for future cloud-native transformations.

    Holistic Vision

    Choosing among IaaS, PaaS, and SaaS is not a purely technical decision; it’s an orchestration of technology, organization, finance, risk, and portability. The “right” model is the one that best aligns these lenses for a specific business outcome—now and as it evolves.

    The big picture

    • Value speed vs. control: PaaS/SaaS accelerate delivery by abstracting infrastructure; IaaS maximizes control at the cost of more operational burden.
    • Shared responsibility ≠ zero responsibility: As you move from IaaS → PaaS → SaaS, what you manage changes, but governance and data accountability remain yours.
    • Data gravity rules: Application code can be portable; data creates inertia. Plan for data lifecycle, residency, and egress from day one.

    Four lenses to decide

    1. Architecture & Ops
      • IaaS: bespoke environments, full control over OS/network; demands solid IaC, GitOps, and runbooks.
      • PaaS: managed runtimes/databases, faster releases; design to provider SLOs/limits and use 12‑factor practices.
      • SaaS: consume capabilities (e.g., email, CRM, analytics) with minimal ops; integration and identity become first‑class work.
    1. Organization & Roles
      • Define a RACI: who’s Accountable for uptime, security, backups, cost?
      • Create a Platform Team (even small) to offer “golden paths” and guardrails for IaaS/PaaS users.
    1. Risk, Compliance & Security
      • Treat identity (IAM), encryption, logging, and backup/restore as non‑negotiable baselines across all models.
      • Map data classification to service choice (e.g., regulated data may require private networking, KMS ownership, or specific regions).
    1. FinOps & Unit Economics
      • IaaS: variable costs + idle risk → rightsize, schedule, and autoscale.
      • PaaS: managed scaling; watch per‑request/GB‑second style pricing.
      • SaaS: per‑seat/per‑usage; model over 3–5 years and include egress/integration costs.

    When to prefer each model (rule of thumb)

    • SaaS for commodity capabilities (email, docs, ITSM, CRM, analytics UI). Demand: export formats, APIs, clear exit plan.
    • PaaS for differentiated apps where speed matters (functions, containers, managed DBs). Demand: SLOs, scaling policy, quotas.
    • IaaS for specialized workloads (legacy, low‑level tuning, strict isolation). Demand: automation (IaC), hardening, cost guards.

    Guardrails that travel with you

    • Policy‑as‑code (tagging, budgets, SCPs/OPA), secrets management, immutable builds, observability SLOs, DR patterns (RTO/RPO defined).
    • Standardize on containers + IaC even when using PaaS, to keep future options open.

    Reducing vendor lock‑in (pragmatically)

    • Favor open interfaces (e.g., S3‑compatible storage, OpenAPI for services).
    • Decouple domain logic from provider SDKs behind adapters.
    • Keep data export pipelines and schema ownership internal.
    • Track a short reversibility doc: what would it take to move in 90 days?

    Decision checklist (copy/paste)

    • Exit strategy (export formats, data volumes, notice periods)?
    • Data class & residency? Encryption & key ownership?
    • Required SLOs (latency, availability) and RTO/RPO?
    • Who is Accountable for uptime, security, and cost?
    • 12‑month run rate vs. 36‑month TCO (incl. egress & staff time)?
    • What business KPI does this service impact?

    References

    This article is an excerpt from the book

    Cloud-Native Ecosystems

    A Living Link — Technology, Organization, and Innovation

    KEY references and Bibliography
    Book DETAILS
  • NIST Definition of Cloud Computing: Essential Characteristics

    NIST Definition of Cloud Computing: Essential Characteristics

    More than two decades after NIST first defined the essential characteristics of cloud computing, these principles continue to shape how organizations adopt the cloud. Understanding them is the first step toward building scalable, resilient, and cost-efficient digital ecosystems.

    NIST Definition of Cloud Computing: Essential Characteristics

    The essential characteristics define the cloud as a service that is directly manageable by the customer, available across a wide geographical area, and structured with organized resources.

    The concept of cloud consumption is introduced from the perspective of the buyer, who is identified as a consumer of “resources” or “services” provided by the cloud provider. The commonly used terminology refers to “cloud provider” and “cloud consumer.”

    Cloud computing, as an IT service, has distinctive features that set it apart from other IT services.

    The NIST (National Institute of Standards and Technology) (20) is a U.S. government agency that develops standards, guidelines, and best practices to support technological innovation and enhance the security and reliability of information systems. Founded in 1901, its goal is to promote industrial competitiveness and scientific progress through the adoption of shared standards.

    In this article, we will rely on NIST publications to understand the meaning of cloud computing.

    NIST has provided formal definitions of cloud computing through descriptions of certain essential properties. A cloud service must possess these characteristics to be classified as such.

    On-Demand Self-Service

    A consumer can unilaterally configure and utilize computing capabilities, such as server time and network storage, based on their needs, autonomously and without requiring interaction with each cloud service provider.

    Broad Network Access

    The functionalities are available over the network and can be accessed through standard mechanisms that promote usability across various heterogeneous devices (e.g., mobile phones, tablets, laptops, and workstations). This ensures ease of access and a wide availability of resources.

    Resource Pooling and Utilization

    The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned based on consumer demand.

    NIST also specifies that cloud consumers typically do not have control or detailed knowledge of the exact location of the provided resources. However, they may be able to specify higher-level attributes such as the country, state, or data center where resources are hosted. Examples of cloud resources include storage, processing, memory, and network bandwidth.

    Elasticity and Scalability of Cloud Resources

    In some cases, provisioning and releasing functionalities can be performed elastically and automatically, allowing rapid scaling up and down based on demand.

    From the consumer’s perspective, cloud resources appear to be highly scalable and can be allocated based on the required consumption at any given moment (just-in-time upscaling/downscaling).

    Measured Service

    Cloud systems automatically control and optimize resource usage by leveraging a metering capability. At an appropriate level of abstraction relevant to the type of service (e.g., storage, processing, bandwidth, and active user accounts), resource usage can be monitored, controlled, and reported, ensuring transparency for both the provider and the consumer.

    Cloud Computing as an OPEX-Based Expense

    Beyond NIST’s technological and functional definition, it is useful to consider that cloud computing—especially in the B2B (Business-to-Business) context discussed in this book—represents an operational expense (OPEX) rather than a capital expenditure (CAPEX).

    The field of FinOps has emerged to address the necessary integration between technology, finance, and treasury operations. The recurring cost, calculated on a monthly basis, introduces challenges in budget planning and financial management for organizations. This disrupts the traditional model in which IT expenses were typically categorized as capital investments (CAPEX) within long-term budget plans.

    This shift requires organizations to adopt service models that can fully leverage the benefits of cloud computing’s adaptability while ensuring cost predictability.

    This change also demands scalable architectures, both at the infrastructure and application levels, as well as data models oriented toward secure data sharing based on access rights. These aspects, while beneficial, introduce complexity in cost forecasting and financial planning.

    Cloud computing is not a one-size-fits-all solution. It should be interpreted and adopted only after fully understanding its potential and limitations, which is the objective of this section of the book.

    Further Considerations

    More than two decades after NIST first defined the essential characteristics of cloud computing, these principles still largely hold true in today’s market.

    Yet, the increasing complexity of cloud services often makes dynamic scaling a challenge, particularly when dealing with full-fledged cloud-based IT ecosystems.

    This difficulty stems from various factors, primarily related to the management of cloud resource configuration and distribution. Consequently, achieving precise and immediate cost predictability for scalability remains elusive.

    Public cloud models, in particular, tend to simplify scaling up while making scaling down more complex unless managed through automated systems with predictive controls.

    Many organizations still find themselves integrating traditional IT systems with cloud services, resulting in hybrid ecosystems rather than purely cloud-native solutions. This adds an intermediate layer of complexity, impacting Total Cost of Ownership (TCO) and Return on Investment (ROI), as these environments still follow OPEX models.

    Moreover, many companies opt for multi-cloud strategies, not necessarily to duplicate environments, but to take advantage of specialized SaaS or PaaS services like Microsoft 365, Google Workspace, Google Cloud BigQuery, or Microsoft Azure Fabric.

    In these scenarios, services cannot always be replicated across different cloud providers. High availability and geographical reliability are guaranteed by contracts with a single provider.

    Over time, regulations have introduced mandatory measures for cloud ecosystems hosting core and sensitive applications. Businesses must ensure service continuity by replicating services across multiple clouds to mitigate risks such as provider bankruptcy, prolonged cyberattacks, or service outages.

    This has led to the need for further classification of cloud resources, independent of the service model, to assist in corporate strategy planning:

    • Cloud resources are generally not portable or transferable across different cloud providers.
    • What can be transferred is the configuration—the software defining the cloud resources—provided the ecosystem follows a cloud-native operational model (as described in the book’s second section).
    • Applications can also be transferred, but only if they have been designed to be compatible with cloud-native principles.

    Navigating cloud adoption is a challenging but feasible journey. Much like an expedition, success requires careful preparation, endurance, and a well-charted map of the landscape.

    Having a guide can be invaluable.

    There are multiple paths to cloud adoption. Some are narrow, requiring technical expertise to reach peak efficiency, while others are more accessible but still yield tangible results in terms of efficiency and effectiveness.

    Understanding the cloud, mapping its capabilities, and assessing an organization’s actual potential is crucial in choosing a realistic path to achieving cloud computing success.

    Holistic Vision

    The NIST definition of cloud computing, with its essential characteristics, continues to serve as a compass more than two decades after it was first introduced. While technology has evolved, and the cloud has become more layered and complex, these principles still form the backbone of how organizations approach adoption.

    Beyond the technicalities of on-demand resources, elasticity, and measured services, cloud computing is also a matter of culture and economics. The shift from CAPEX to OPEX redefines how businesses plan, invest, and innovate. FinOps practices, hybrid strategies, and multi-cloud ecosystems are not exceptions but the natural evolution of NIST’s foundational vision.

    Seen holistically, the essential characteristics of cloud computing are less about the mechanics of servers and storage, and more about trust, adaptability, and transparency. They remind us that the cloud is not simply infrastructure: it is a shared environment where resilience, scalability, and financial sustainability converge.

    In this light, adopting the cloud is less a technical migration and more an expedition into a dynamic ecosystem. Success depends not only on technology but on preparation, governance, and the ability to align financial strategies with digital ambitions. The NIST framework remains the map — but every organization must chart its own path across the terrain.

    References

    This article is an excerpt from the book

    Cloud-Native Ecosystems

    A Living Link — Technology, Organization, and Innovation

    KEY references and Bibliography
    Book DETAILS