Cloud. When you read this term, you might immediately think of the advantages that the cloud offers to your business: flexibility, scalability, cost reduction … just to mention a few. It’s evident that today cloud computing is considered a key ingredient of any digital transformation strategy; your company might have already embraced or started looking at the cloud as a strategy to innovate and differentiate from competitors. As a result, you likely are considering new ways to allow for faster service creation, easier experimentation, and more customer engagement without reducing the security and compliance of your network. The cloud can provide this for you.
Cloud adoption is expanding, and IT architects are growing more sophisticated in how they think about cloud computing. A lot of market research confirms this trend. For example, IDC CloudView reports that cloud adoption is accelerating rapidly in recent years, as shown in Figure 11-1.
As of 2017, enterprise adoption of cloud computing has truly moved into the mainstream, with 68 percent currently using a public or private cloud for more than one to two small applications, a 61 percent increase over the previous year’s figure.
The trend toward cloud adoption is clear and the advantages are well understood, but if your organization hasn’t already embraced cloud integration, answers that may be less obvious to you are how to integrate the cloud into your existing enterprise network, the challenges it might introduce, and how to overcome them.
The goal of this chapter is to describe how Cisco Digital Network Architecture brings together networking, security, analytics, and management components to simplify, secure, and optimize the way your organization integrates and works with the cloud.
The chapter starts with a quick introduction to the cloud as it pertains to cloud networking so that you are familiar with the terminology used. The rest of the chapter explains the following:
Cloud service models
Cloud deployment models
Multi-cloud
Cisco DNA for the cloud
The “Cisco DNA for the Cloud” section examines how Cisco DNA enables the cloud for three distinct domains: applications, network automation, and analytics and assurance.
The National Institute of Standards and Technology (NIST) Special Publication 800-145 defines cloud computing as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”1
1 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
From this definition and having the enterprise customer in mind, it is clear that adopting the cloud is much more than just moving some applications from a private data center to a cloud service provider. Cloud computing is really a new architectural approach that considers the transport layer, the networking aspects, the security, and the analytics components. This is the main reason why in the Cisco DNA architecture the cloud is considered as another “domain,” in addition to the campus, WAN, and data center, that must be fully integrated to provide the advertised advantages.
Let’s consider some of the main advantages of embracing the public cloud:
Flexibility: The cloud offers the capability to spin up a service when needed without having to provision the required software and hardware in advance.
Elasticity: You get a potentially endless pool of resources at your disposal and you can configure your solutions to dynamically increase or decrease the amount of resources needed. If built correctly, a cloud application or service easily scales vertically (same instance with more or less processing power) or horizontally (dynamically increase or reduce the number of instances to cope with a change in service demand).
Reliability and availability: Most cloud providers offer a service-level agreement (SLA) that guarantees 99.99 percent availability. If a server fails, hosted applications and services are automatically moved to any of the available servers in another availability zone. Imagine if you were required to build this capability with your in-house IT infrastructure; doable but not easy or inexpensive.
Utility pricing: The end user pays only for the resources it consumes.
From CAPEX to OPEX: There is a shift from a capital expenditure (buying up front) model to an operational expenditure (pay as you go) model. If done correctly, adopting the cloud provides a cost reduction in operating your business. It allows you to save substantial CAPEX costs by reducing the network and server infrastructure on site. This also removes associated operational costs in the form of power, air conditioning, and administration costs.
Metering: Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage is monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.
Let’s consider a scenario to see how these advantages may apply in the real world. Suppose your company is an innovative market analysis and research firm called DA13. You, as the chief IT architect, are in charge of designing and implementing the infrastructure to support a machine learning (ML) application to analyze business data for a new service that the company will be launching.
The first thing you need to do is prototype the solution and decide what type of computing infrastructure you need to run the application effectively and reliably. From a quick analysis of server specifications, if you want to run this solution on premises, you need to purchase and test multiple different physical flavors of the server (with different CPU, memory capacity, type of memory, etc.) to choose the one that gives you the best results. This process is not optimal in multiple ways:
You have to purchase all the servers in advance.
You have to wait for the time it takes to deliver the physical hardware, to install and cable it in the rack, and to install and upgrade the related software and patches.
Once the tests are done, the unused server becomes redundant.
Compare this process to provisioning a server in the public cloud from a cloud service provider (CSP) such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP), which enables you to do the following:
Provision the servers in minutes
Change the server specs dynamically
Pay only for the time you have used the servers
Deprovision the instances that you don’t need
Continuing the scenario, suppose your ML application is now in production and it’s becoming evident that the server you have chosen isn’t capable of handling the amount of data it needs to process. If your firm has chosen to run the solution on premises with its own server, it now must add processing power (scale up) in order to have better performance.
Suppose that a few months later, DA13 decides that there is another important use for this ML solution and another team needs to leverage it. This means that you have to add additional servers. If you run the solution in the cloud, it’s fairly simple to spin up another instance of the same server and put a load balance in front and just scale horizontally (scale out in this case). If the demand decreases you can always scale down (reduce the resources per instance) and scale in (reduce the number of instance) to save money.
It’s becoming pretty clear from this scenario that for most enterprise customers, the greater the adoption of the cloud, the greater the benefits may be. But sometimes people forget that cloud computing poses challenges as well, and it’s important to call them out in order to have an informed decision on whether to move to the cloud and, if so, how to plan this move.
Some of the challenges of cloud computing are as follows:
Reduced control: The infrastructure and services may be completely owned by the CSP; this can pose challenges when, for example, the enterprise customer has some internal strict policy for certifying and upgrade software.
Regulation and privacy: Although CSPs usually implement the best security standards and industry certifications, organizations that are subject to regulations such as the Payment Card Industry Data Security Standard (PCI DSS) or the Health Information Portability and Accountability Act (HIPAA) must consider data privacy issues that may make use of a public cloud more challenging. The global availability of the services that CSPs provide makes them an attractive target for hackers.
Legacy environment: For start-up companies, adopting cloud services usually is a very easy decision because they can start from scratch. For a typical enterprise, applications and services are usually written and deployed using a traditional approach and hence tightly coupled to local hardware resources (storage and network), local firewall, local load balancers, etc. It’s not easy to move the applications to the cloud.
New IT skills: Adopting cloud technologies requires specific skills that might not be already present in your organization. Acquiring these skills takes time and investment.
It’s important to note that there are many other factors an enterprise likely would need to consider for a complete analysis when looking into selecting the right cloud solution. For example, when it comes to data backup, factors such as service-level objective (SLO), recovery point objective (RPO), and recovery time objective (RTO) are important to understand and take into consideration. But a complete analysis of the many possible factors is beyond the scope of this book and would unnecessarily complicate things.
To be successful in adopting the cloud, the most critical decision is which cloud service model and type of deployment (public, private, or hybrid cloud) to choose, a decision that is based on a combination of business, technology, and internal organizational factors. The cloud model is composed of three service models and four deployment models, and it’s very important to understand them very well when deciding which combination best fits your needs.
The next two sections discuss the three different cloud service models and the four cloud deployment models.
There are three cloud service models commonly available, as described by NIST SP 800-145:
Software as a Service (SaaS)
Platform as a Service (PaaS)
Infrastructure as a Service (IaaS)
Figure 11-2 shows a representation of the service models, highlighting the most important stack components and the areas of responsibility between the cloud provider and you, the consumer.
The SaaS model provides the highest level of abstraction and simplification. The whole “service” stack, from the infrastructure to the application level, is provided by the cloud service provider. As the customer, you directly access the service through an application running on the cloud infrastructure. The application typically is accessible through a user web interface or an application programming interface (API). On the other side, the consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
In the PaaS model, the cloud service provider provides all the components of the platform needed to run your own applications. This includes the underlying cloud infrastructure with networking devices, servers, operating systems, and storage. As a user you enjoy more control over the applications and possibly configuration settings for the application-hosting environment.
Finally, in the IaaS model, you have the highest level of control and lowest degree of abstraction. The cloud service provider provides the building blocks for the infrastructure but it’s up to you to put them all together into a working solution. In other words, the IaaS model provides the computing resources, the storage, and networking components (e.g., routers, firewalls, etc.) and leaves you to deploy the applications. This translates into a lot of flexibility but also additional work for the integration required.
As discussed a bit later in the chapter, Cisco DNA plays a role in helping you to deploy one or a combination of these models. The reality is that, based on your company business and internal organization, any of these models may be effective, and quite often a combination of models provides the ideal solution.
Most people immediately associate the cloud with a public cloud deployment. In reality there are four different cloud deployment types and usually the success of an enterprise cloud adoption strategy is dependent on leveraging a mix of these. The four deployment types as defined by NIST SP 800-145 are as follows:
Private cloud
Community cloud
Public cloud
Hybrid cloud
Private cloud means that the infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and exists either on or off premises.
In the case of the community cloud, the infrastructure is provisioned for exclusive use by a specific community of consumers from organizations with shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It is owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it exists either on or off premises.
In a public cloud the infrastructure is provisioned for open use by the general public. It is owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.
Finally, for hybrid cloud the infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).
For a startup company that is starting to build its services from scratch, leveraging the public cloud is usually a natural choice. For an enterprise that has legacy applications that were not written for the cloud, often the winning strategy is adopting a hybrid model that leverages the ease of deployment of some public cloud services with the more controlled environment of the private cloud. So, most of enterprise customers end up with what is called a multicloud.
Cloud. You say cloud, but probably you should say multicloud.
There is no one cloud model or deployment type that meets your requirements. Customers today live in a multicloud world: you may use Cisco Webex as a collaboration tool and Salesforce.com for your enterprise resource planning (ERP) application, all of which are consumed via a SaaS model. But you may also leverage the Microsoft Azure Active Directory service for implementing single sign-on (SSO) to your cloud applications, and this is Platform as a Service. You may also have a Cisco Cloud Services Router 1000v (CSRv) deployed in AWS to implement Infrastructure as a Service and connect securely hundreds of branches to your applications in the cloud.
So, a hybrid cloud strategy is seen as critical by many organizations, and working with multiple clouds from multiple providers is the new normal. International Data Corporation (IDC) in April 2017 conducted a study called “IDC CloudView”2 which covered 31 countries and reached 8188 respondents. The results of this survey, presented in Figure 11-3, confirm the growing trend toward adopting both cloud and multicloud computing.
2 IDC CloudView: https://www.idc.com/getdoc.jsp?containerId=IDC_P37198
Let’s look at the numbers: 85 percent of respondent are using or considering a cloud strategy, and 94 percent of current cloud users plan to use multiple clouds. And the latter number is up from 85 percent the previous year. This increase is the result of different cloud models serving different needs, as explained before, but it’s also due to the fact that cloud computing has become a strategic initiative for transforming and digitizing the business. What’s even common is multiple business entities within the same organization adopting the cloud in different ways that fit their needs but may result in an unclear company cloud strategy.
This is to say that there is no single cloud. It’s common to see an enterprise customer using multiple public service providers such as AWS, Azure, and Google for IaaS or PaaS services and the same customer also leveraging SaaS providers such as Salesforce and Workday. And of course, let’s not forget the customer’s own private clouds.
Sum it all up and the result is a network that extends to multiple private and/or public cloud services from multiple providers, a network that, contrary to the premise of cloud computing being a great simplifier, might be pretty complex to manage, control, and secure.
That’s the reason the Cisco cloud strategy and solutions3 focus on delivering a level of independence and consistency across multiple clouds. The Cisco Multicloud Portfolio brings together networking, security, analytics, and management, from the infrastructure to any application and across your network, to
3 For more about Cisco cloud solutions, go to https://www.cisco.com/c/en/us/solutions/cloud/overview.html.
Simplify your multicloud operations
Secure your adoption of any cloud model
Optimize performance and agility across your clouds
Of course, there are many aspects of this multicloud strategy. In the next section, the focus is on how Cisco DNA integrates the cloud for applications, automation, and analytics and assurance.
Cisco DNA is the architecture blueprint for the enterprise network that connects users and things to applications in support of the digitalized enterprise business processes. Where these applications reside, it doesn’t really matter: they can be in your data center, in a private cloud, or moved to a public cloud. Cisco DNA treats the cloud as another domain of the enterprise network, allowing a smooth integration with the existing areas of branch, campus, WAN, and data center, as shown in Figure 11-4.
The Cisco DNA platform fully integrates different cloud models, including private clouds, virtual private clouds, hybrid clouds, or public cloud environments. This integration is designed both at the transport layer and the control layer of the network.
At the transport layer, the various cloud environments are fused into the enterprise network seamlessly by use of tunneling techniques. For example, a virtual IP Security (IPsec) gateway can be instantiated in a virtual private cloud (VPC) and connected to the enterprise-operated fabric by means of an IPsec tunnel. Configuring the virtual router with similar policies and functions as the enterprise-operated branch environments then makes the VPC behave like other branches that are part of the network infrastructure. For example, if the virtual router in the VPC has SD-WAN capabilities, path optimization could also be leveraged for architectures where multiple connections to the VPC are available.
The cloud becomes an essential tenet in Cisco DNA for orchestration and management, allowing Cisco DNA services and the network infrastructure to be governed by using cloud technologies. At the control layer, management and orchestration tools are deployed in the cloud to operate the network at scale and are reachable from anywhere. Analytics and telemetry engines accessing and storing information in the cloud are also part of the cloud service management aspect of Cisco DNA. By making the cloud an integral part of the enterprise network, Cisco DNA is addressing the requirement for cloud enablement to drive rapid application prototyping, fast application deployment, and continuous feedback loops to speed digitized business processes.
In summary, in Cisco DNA all architecture functions—whether control plane or data plane related—are cloud enabled: orchestration, automation, network transport functions, and analytics either run in the cloud or are able to interact with the cloud. This is an important Cisco DNA principle.
The following sections explain how Cisco DNA helps connect your application to the cloud, enable automation from the cloud, and provide a scalable Analytics and Assurance solution. This is a journey that you have just started, but Cisco DNA lays the foundation for securely and smoothly integrating your enterprise network with the cloud of your choice.
Let’s revisit the scenario with the DA13 market analysis and research firm introduced earlier. Assume that, thanks to the public cloud, you have conducted a quick prototyping exercise and have decided to leverage an IaaS solution to install a server and the related storage in the cloud and run the machine-learning application there. This choice gives you the advantages of lowering the entry budget to deploy the solution while being fast to market and enabling DA13 to start providing the service within the aggressive Marketing department timelines. Also, leveraging the cloud allows the service to scale both vertically and horizontally in case the market analysis service turns out to be a success and you are asked to dynamically provide more performance and scale according to user demand.
Now you need to decide how to allow internal consumers to connect to the application. Your company has multiple locations and employees should be able to access the service from anywhere. Also, the data analyzed in the cloud is very sensitive customer data and hence you need a secure solution to provide a connection to upload the data.
Based on these requirements, you decide to extend your data center in the cloud by building a VPC and providing a secure connection to it. You also want to maintain all the advanced network services you have today on your head-end routers where you connect your branches to the main company data center: enterprise-class routing features, flexible virtual private networks (VPN), a stateful firewall, and application inspection, all integrated in your on-premises routers.
The solution that meets your requirement leverages a Cisco CSRv router in the public cloud VPC. By deploying this virtual router in Amazon AWS, for example, every branch office, campus, and data center location can directly access your application in the AWS VPC securely. You can choose from a wide variety of VPN technologies supported on the Cisco CSR 1000V, including point-to-point IPsec, Cisco FlexVPN, Cisco Dynamic Multipoint VPN (DMVPN), and Cisco Easy VPN. Your IT staff is familiar with the Cisco Aggregation Services Router (ASR) and hence with the same Cisco IOS XE software and VPN configuration used with the CSRv. This allows IT to quickly integrate an Amazon AWS VPC into the existing enterprise VPN topologies.
The Cisco CSR 1000V also includes advanced software security features, including access control lists (ACLs) and a stateful zone-based firewall (ZBFW). You can extend the enterprise security policies to access the ML service into the public cloud using a familiar platform and configuration syntax and providing the same security you have on premises.
As shown in Figure 11-5, from a Cisco DNA architecture perspective, the VPC becomes an extension of your data center.
Last but not least, Cisco DNA Center automates the whole instantiation of the CSRv router in the cloud and the VPN integration with your physical router on premises. This is done via a new Cisco DNA Center application called Cloud Connect. You simply create a Cisco DNA Center profile with your public cloud provider account and credentials, and then an automated provisioning flow guides you through the setup. You select the site and the router you want to connect to the cloud. You specify the cloud provider (AWS, Azure, etc.) and the VPC you want to connect to. You pick the type of router based on the desired performance, and then Cisco DNA Center takes care of the whole process of creating the CSRv instance in the cloud and configuring the VPN. Figure 11-6 is a screen-shot of Cisco DNA Center showing the instantiation.
This is a great example of how Cisco DNA helps you automatically and securely integrate your application regardless of whether it’s located on premises, in a private cloud, or even in a public cloud.
Cisco DNA automation provides the necessary abstraction layer to implement your business intent in an easy way, without dealing with all the underlying network configuration complexity. This is what provides the simplicity you need to make your deployment fast, secure, and reproducible. Cisco DNA automation is represented by the Cisco DNA Center platform that embeds the Cisco DNA controller and provides a single pane of glass to design your network, define network policy, provision your network, and ensure it is continuously available.
In the Cisco DNA architecture, the automation layer can be either on premises or in the cloud; it orchestrates network functions and resources that can be either on premises or in a private or public cloud, as demonstrated in the previous section with the automation of a CSRv router in the public cloud VPC.
From an architecture point of view, placing the automation layer in the cloud requires the proper security to be in place to ensure reachability into the network infrastructure from the cloud-based automation. In Cisco DNA this is done by defining the relative policy enforcement point (PEP). The PEP is either a secure Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) tunnel initiated from the device on premises to the cloud, or a secure Restful API. It really depends on what function or service you need to manage. This is represented in Figure 11-7.
Cisco has multiple network automation solutions in the cloud that apply to different network domains: Meraki Dashboard4 allows the lean enterprise to automate from the cloud the deployment of a whole network stack, including wireless, switching, routing, and security. Meraki is consumed as a SaaS model and the integration in Cisco DNA is through Cisco DNA Center, which is capable of managing your Meraki devices.
4 Learn more about Meraki at https://meraki.cisco.com.
Another example is the Cisco SD-WAN5 solution, which is orchestrated from the cloud. The automation component deploys an overlay WAN architecture capable of meeting SLA requirements for business-critical and real-time applications and providing end-to-end segmentation for protecting critical enterprise compute resources.
5 Learn about SD-WAN solutions at https://www.cisco.com/c/en/us/solutions/enterprise-networks/sd-wan/index.html.
At the time of writing, Cisco DNA Center is not available in the cloud … yet. Cisco DNA Center was built from the ground up as a platform based on modern cloud technologies, so it’s not hard to imagine that Cisco strategy is oriented to provide this important automation and orchestration component directly from the cloud.
Analytics is a major building block of Cisco Digital Network Architecture. It’s main functions are
Gathering operational telemetry from the underlying network via southbound APIs.
Ingesting, normalizing, and de-duplicating the telemetry data.
Extracting meaningful information by correlating multiple contextual data. This process may include leveraging machine learning.
Sharing insights with applications via northbound APIs. One such application is Assurance.
Communicating directly with the Cisco DNA controller to automate recommended data-driven actions. This is what is referred to as the “Cisco DNA circle of life” or closing the automation loop.
Figure 11-8 shows how Analytics fits in the Cisco DNA architecture and highlights all the different communication interfaces that are established in the architecture to integrate Analytics. Most of these leverage secure APIs and thus are independent from where the actual function runs, on premises or in the cloud.
As explained in Chapters 15 to 17, to perform the tasks described earlier, the Cisco DNA architecture leverages an enterprise analytics engine, Network Data Platform, that is one of the services provided by the Cisco DNA Center common application infrastructure framework.
This software infrastructure platform is built with the latest big data cloud technologies and provides an abstraction layer to deploy the different Cisco DNA services (DNA controller, Cisco DNA Analytics, Assurance, etc.) on premises, in the cloud, or in multiple deployments. In other words, it gives you the flexibility to deploy the services where it makes sense. Other advantages of the Cisco DNA Center common application framework layer are
Built-in operational capabilities to manage and monitor the infrastructure
Cluster and node management
Services management
Multitenancy (roadmap)
The Analytics engine may ingest and analyze data from different sources (syslog, SNMP, NetFlow v9/IPFIX, Cisco Identity Service Engine [ISE] for contextual user/device info, IP address management [IPAM], AND CMX for Location). Cisco DNA Center is designed to scale and leverages built-in collectors to interface with the different information sources to optimize the data ingestion and transform it in common data models for all types of telemetry for easier application consumption.
Considering the huge amount of data that a network generates and the fact that the analytics engine is designed to keep a long-term state of this data to continuously validate and correlate it, it’s pretty clear that the analytics component is a perfect candidate to be deployed in the cloud.
The cloud gives Analytics important benefits:
Elastic scale and performance: The platform scales horizontally to adapt to the amount of data being received. Also, if more processing power is needed the platform scales vertically to the desired performance
Global footprint: For a distributed enterprise, the public cloud, with its global presence, represents a great way to have a data repository closest to where data is generated.
Machine learning: ML implies running complex algorithms against billion of data records per day to find and highlight traffic patterns and compute models to detect anomalies. This is done effectively only in the cloud.
Ongoing cross learning: Again for ML, when it comes to building network behavioral models, using anonymized data sets covering a broad range of deployment models from different customers is a huge plus.
Cost effectiveness: The installation costs and infrastructure requirements for the customer are reduced and hence time to production is expedited.
Today, Cisco DNA already has examples of running Analytics in the cloud. For example, the Cognitive Threat Analytics component of Stealthwatch for Encrypted Traffic Analytics (ETA)6 runs completely in the cloud and leverages machine learning to process huge amounts of data received from the Cisco DNA network to gain insight into threats in encrypted traffic with real-time analysis correlated with user and device information. The platform analyzes information such as Sequence of Packet Lengths and Times (SPLT) and Initial Data Packet (IDP) to obtain packet data from the first packet of a flow and extract interesting data such as an HTTP URL or Domain Name System (DNS). It also looks at the byte distribution, analyzing the probability that a specific byte value will appear in the payload of a packet within a flow. Finally, it processes TLS-specific information found in the TLS handshake, which can reveal interesting, unencrypted metadata used to extract data elements, such as cipher suite, TLS version, and the client’s public key length. This is done for every interesting flow. Actually, the extraction is done in hardware, in the Catalyst 9000 innovative ASICs, but the data processing is done in the Cognitive Threat Analytics engine; how could it scale if not deployed in the cloud?
6 To learn more about ETA, check out Chapter 22 and https://www.cisco.com/c/en/us/solutions/enterprise-networks/enterprise-network-security/eta.html.
Another great example of how Cisco DNA is running analytics in the cloud is the Cisco Connected Mobile Experiences (CMX) Operational Insights, part of the Cisco DNA Spaces solution.7 This is a cloud-enabled platform for managing, monitoring, and optimizing your enterprise assets, such as Internet of Things (IoT) sensors. The solution uses a wide range of tags and sensors, including Wi-Fi, Bluetooth Low Energy (BLE), and radio-frequency identification (RFID) to continually integrate, monitor, and manage your connected operations, as shown in Figure 11-9. Again, potentially you are dealing with an incredibly large amount of data that needs to be processed in order to classify, categorize the data, and extract business-relevant information.
7 To learn more about CMX Operational Insights, go to https://www.cisco.com/c/en/us/solutions/enterprise-networks/connected-mobile-experiences/operational-insights.html.
CMX Operational Insights leverages the power of the Cisco DNA infrastructure to collect and transport the information, but the Operational Insights service is provided using a SaaS model to leverage the power and ease of deployment in the cloud.
The cloud is a critical enabler of any enterprise network digitization strategy. Cisco DNA embraces the cloud as a main component of the network blueprint and helps customers fully exploit the benefits the cloud gives in terms of flexibility, agility, high availability, and scale.
This chapter provided an introduction to cloud computing and reviewed the Cisco DNA solution for the cloud, including
An overview of the different cloud service models (SaaS, PaaS, IaaS) and deployment models (private, public, hybrid cloud) available today
The Cisco DNA architecture for cloud integration
A overview of the specific domains of Cisco DNA in the cloud: applications, automation, and analytics and assurance
Cisco Multicloud Portfolio: https://www.cisco.com/c/en/us/solutions/cloud/overview.html
Cisco DNA Center: https://www.cisco.com/c/en/us/products/cloud-systems-management/dna-center/index.html