Cisco Blogs

Cloud Architecture Considerations and The Open Group

July 26, 2011 - 0 Comments

Last week I presented and participated at the The Open Group Forum in Austin, TX. It was a great event, with insights into Enterprise Architecture, Business Architecture and Emerging Architectures. There were several breakout tracks in the Forum, including, the most popular – Cloud Architectures Track. The sessions ranged from connecting architecture frameworks (TOGAF) to Cloud Architectures, to Cloud Architectures development. My session was on “Architecture & Considerations for IaaS Clouds”.  This session was more focused on technology aspects of the Cloud Architecture. Also, it could be applied to either an enterprise private cloud or a service provider cloud settings. Just to level set everyone in the audience, I started out with a taxonomy and reference architecture (RA) review. I utilized both NIST’s published and a simplified version of Cisco Cloud RA. The Cisco RA review was the case in point for this session, where Infrastructure, Service orchestration, Delivery/Management and consumer layers were discussed.

So, here are some of the salient (non-exhaustive) considerations that I discussed in the allotted time of the session.  Namely, Integrated Compute Stack (ICS) approach, Points of Distribution (PODs) and Service Class Containers. ICS approach is a building block with integrated compute and storage elements into defined standardized units of deployment. This approaches serves as the method of operating expense containment, predictability in performance and hence means to meet business SLAs. Standalone ICS are valuable only if they get “inserted” into a point of distribution (PODs) for service delivery. PODs essentially take ICSs to the next level in the architecture by standardizing on elements like Network Access and Security/L4-L7 services. Some of the common traits for the above mentioned POD elements are virtualization, multi-tenancy, capacity, oversubscription, availability, performance and service tier ratio. Finally, Service Class Containers consideration allows organizations to pre-define cloud offerings in form of service classes (for example Bronze, Silver, Gold Services) that abstract a rigid underlying infrastructure elements. A service container may contain combination of elements such as dedicated or shared VLANs, various forms of data stores, QoS and like offerings, data protection offerings and network service offerings, like load balancer and firewall. However, the goal of Service containers is to provide a menu of cloud offering based on features, SLA and pricing value. The types of service class offering will depend on the organization or service provider.

The above considerations are address the infrastructure components of the architecture. Service orchestration, with Service delivery and management, actually give life (creation and retirement) to a cloud service for a cloud consumer. Lets walk thru a service-stitching life cycle and see how this is done.  But before we do that, some basic terminology on Configuration Management Data Base (CMDB) and Service Catalogues. CMDB is “single source of truth” for infrastructure, services and their status. It tracks what has been provisioned and already allocate. Service Catalogue is also the critical piece of life cycle, as it advertises what services are available to the consumer.  Now, the lifecycle approach, the cloud consumer typically requests a service via self-service portal. This triggers a fulfillment request, assuming the entitlement functions are passed. The fulfillment is handled by service governor, which sequences the provisioning tasks and executes provisioning actions based on requested service and blueprints. Once provisioned, services are regularly managed for performance, and compliance. The above steps are performed with updates and queries to CMDB.  Finally, similar lifecycle approach is performed for service retirement.

In order to address cloud security, one has to take a step back and think about Trust. Trust in the cloud, centers on four core concepts: Security – Traditional issues around data and resource access control, encryption and incident detection. Control – The ability of the enterprise to directly manage how and where data and applications are deployed, used and destroyed. Service-Levels: The definition, contracting and enforcement of service level agreements between a various parties. Compliance –  Conformance with required regulatory, legal and general industry requirements (such as FISMA, FedRAMP, PCI, HIPAA and Sarbanes-Oxley).  Hence, one has to approach trust with a balancing act of the four core concepts.

In the end, the above-mentioned cloud architecture considerations are as good as the adoption roadmap. Hence, here are the steps to cloud adoption in an enterprise private cloud. First, discover and capture enterprise landscape. Second, map business architecture to technology architecture. Third, cloud architecture development based on some the above-mentioned considerations. Fourth, cloud implementation and apps/user migration. Fifth, operation and management, via PMO/AMO functions. Finally, Sixth, on-going cloud optimization and review.

Hope this was helpful. It certainly resonated with the audience.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.