This is part 3 of the "Your Business Powered By Cisco Customer Solutions Architecture (CSA)" blog series.

Physical Infrastructure Layer

The physical infrastructure layer is where the physical resources reside. This includes equipment typically used in a data center such as network devices (switches, routers, firewalls, and load balancers), computing resources, storage and facilities.  Physical infrastructure products and the connectivity to the cloud, customer networks, partners and cloud brokers are secured in this layer.

Virtual Infrastructure Layer

The main purpose of this layer is to abstract the underlying physical resources into pools of logical resources with attributes and service assurance parameters. In addition, it greatly simplifies management processes, accelerates service delivery to market, and reduces operating expenses.  Simplicity of provisioning and management along with security can be obtained by creating many logical networks from one physical network.  The physical infrastructure layer is virtualized using various methods (hypervisor technology, Application Centric Networks, etc.) into a virtualized infrastructure layer. This is analogous to creating VLANs within a physical LAN.  The Resource Abstraction and Control functionality in this layer views the physical layer in a more holistic fashion by allowing the orchestration, network and security controllers to enforce appropriate policies to the traffic and the underlying network infrastructure.

Service Layer

The Services Layer iswhere the IT organization orchestrates and exposes services. This layer is required to make services available to end customers. The Services Layer manages the cloud infrastructure providing the services and runs the software that implements the services. This layer receives instructions from the Service Management and Automation layer above and uses the virtualized infrastructure layer below to instantiate service requests based on the instructions received from higher layers.  The major functional services required here include Identity Management, Entitlement, and services that enable application reliability and assurance.

As-a-Service (aaS) models provide businesses with dynamic and scalable compute capabilities, allowing them to reduce overall costs, while focusing on core projects and addressing variable IT capacity needs. This layer offers Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) options.

This layer offers a true highly availability (HA) solution that accounts for every aspect of an Infrastructure environment, from development to production. This includes provisioning and maintaining servers, network, storage, software and security.

Segmentation of customer environments is extremely important and must be protected and secured in this layer.  Segmentation applies at two levels - segmentation within a customer i.e. line of business segmentation and segmentation of customer environments within the multi-tenant applications operating in this layer.

Service Management and Automation Layer

This layer focuses on service delivery automation & verification.  It provides access to remote cloud service offerings to ensure the desired services are delivered if not locally available.  The major functional components within this layer include Service Catalog, Fulfillment, Assurance, Billing, and Orchestration.

The Service Catalog contains information about applications and services, prices, contact points and processes for requesting a service. There are two components to a Catalog; a customer view from which business users can browse and select services, and a technical view that documents exactly what is required to deliver each service in the catalog. Fulfillment is responsible for delivering products and services to the customer. This includes order handling, service configuration and activation, and resource provisioning.  Assurance consists of proactive and reactive maintenance activities, service monitoring (SLA or QoS), resource status (monitoring) and performance monitoring, event correlation and troubleshooting. This includes continuous resource status and performance monitoring to proactively detect possible failures, and the collection of performance data and analysis to identify and resolve potential or real problems.   Billing requires resource usage records -such as call detail records-be measured, rated, assigned, and communicated between appropriate parties.

Orchestration delivers coordinated provisioning of virtualized resources as well as the runtime coordination of resource pools and virtual instances. Service Orchestration also provides static and dynamic mapping of virtual resources to physical resources, and overall management capabilities such as capacity, assurance systems, billing systems, interfaces to external clouds through cloud broker, and interfaces to services grid for support management. In addition, the configuration of the underlying infrastructure components metering aspects required for service assurance and billing need to be configured and collection intervals automated.

The security capabilities embedded in this layer encrypt traffic communication from the automation controller to all the other components (such as service catalog, assurance and billing) of the architecture.

Applications / Portal Layer

End customers initiate service requests using the Application layer's portal.  This portal leverages the underlying service management and services API's to create a user experience that enables services to be created, deployed and consumption ready in minutes. The portal interacts with the service fulfillment function which includes service catalog, service abstractions (servers, storage, network, and application services), cloud automation layer, Identity and access management (IAM) and many other systems in the layers below, all of which will be transparent to the customer, to provision the requested service.  In this layer, the security capability ensures that communication (in and out) is encrypted and the entities mutually authenticate by trusting a common authentication framework.

Communication between layers of the CSA enables the orchestration, delivery and management of services as discussed in the previous discussion of the Cisco CSA layers.  Application Programming Interfaces (API) built into the functional components within each CSA layer facilitate this communication.  Additionally, Cisco CSA API's expose capabilities for external use to authorized parties and components so they may order, manage and consume CSA-delivered services.  The next section provides further detail on the Cisco CSA API's.

CSA APIs

There are different types of API's provided by CSA. At the highest-level of abstraction, there are two categories: internal and external. The internal API's provide the interaction between the different layers of this architecture. On the other hand, the CSA external (i.e. customer facing) API's, provide three different and distinct functionalities. They are as follows:

• Southbound API's: These are the API's accessing the lower layer of the physical architecture such as devices, sensors and networking components. Typically the communication is performed via an agent on the device or an aggregator or a gateway on the fog computing on the edge.  OnePK and Open Flow are examples of this category.
• Northbound API's: Opposite to the previously mentioned set of API's, these are API's that allow communication with the higher-level of architecture components. An example of that would be business software applications, portals and user higher layer control applications. Typically Northbound API's are provided via HTTP protocol, such as SOAP or REST interfaces with XML or JSON data representation.
• East-West API's: Typically these types of API's exist in the Service Management and Automation layer. They are externalized API's provided for integration with external components (mostly cloud-based) and applications. An example of east-west API is the SolveDirect API's used to integrate ticketing systems. Business process integration API's is another example.

Cisco Services API's are using HTTPs for SOAP or REST interfaces with XML/JSON data representation. There is an ongoing effort to have a common single API platform (development, management, deployment, security, etc.) in Cisco Services using MuleSoft.

This CSA is applicable to many use cases.  My next blog highlights one possible use case. Future white papers will cover additional use cases in depth.

Tweet me @CiscoSP360 if you have any questions or comments.