Tuesday, August 13, 2013

CCSK Study - Domain 6: Interoperability and Portability

Notes
  • Scenarios
    • interoperability and portability allows you to scale a service across multiple disparate providers on a global scale
    • could allow the easy movement of data/applications/services from one provider to another
  • Not a unique concept to cloud
  • Interoperability
    • High level: requirement for the components of a cloud eco-system to work together
    • mandates that components be replaceable by new or different components and continue to work
      • Sorta like how management views employees ??? ;)
    • also extends to exchange of data
    • Reasons to change providers (short-list)
      • Unacceptable increase in cost
      • New provider provides more/better features
      • Provider ceases business operations
      • Provider is shutdown due to legal/disaster
      • Unacceptable decrease in service quality
      • Dispute between cloud customer and provider
    • Remember, cloud companies are also in the business of making money!
    • Lack of interoperability will lead to vendor lock-in
  • Portability
    • easy of ability to which application components are moved and reused elsewhere regardless of provider, platform, OS, infrastructure, location, storage, data format, or APIs
    • Generally only feasible to be able to port from cloud providers in the same "class" (eg:  IaaS to IaaS)
      • referring to the octant of the cloud cube
  • Failure to plan for I & P Can lead to unforeseen costs
    • Vendor Lock-In
    • incompatibilities across different cloud infrastructure causing disruption of service
    • unexpected application re-engineering
    • costly data migrations or data conversion
    • retrain or retooling new applications or management software
    • loss of data or application security
  • Moving services to the cloud is a form of outsourcing; the golden rule of outsourcing is "understand up-front and plan for how to exit the contract"[sic]
  • Interoperability Recommendations
    • hardware
      • do not access direct hardware if you don't have to
      • virtualize when you can
    • physical network devices
      •  try to ensure APIs have the same functionality
      •  try to use network and security abstractions
    • virtualization
      • use open virtualization formations (OVF) when possible
      • Understand and document vendor customized virtualization hooks or extensions in use
    • Frameworks
      • investigate CSP APIs and plan for changes
      • use open and published APIs
    • Storage
      • use portable formats for unstructred data
      • understand database system used for structured data and conversion requirements
      • assess the need for encryption of data in transit
    • Security
      • Use SAML or WS-Security for auth controls (more portable)
      • Encrypt data, understand how keys are used/stored
      • Ensure that log data is portable and secured
      • Ensure data can be securely deleted from the original system
  • Portability Recommendations
    • Understand SLA differences
    • Understand different architectures
      • understand portability issues which may include API, hypervisors, application logics, and other restrictions
    • Understand encryption, keys, etc
    • Remember to check for metadata
  • Recommendations for different Cloud models
    • IaaS
      • use OVF
      • document/eliminate provider-specific extensions
      • understand the de-provisioning of VM process (secure?)
      • understand the decommissioning of storage
      • understand costs involved for moving data
      • understand the process/governance of encryption keys
    • PaaS
      • use platforms with standard syntax and apis and that use open standards such as OCCI
      • understand the tools available for secure data transfer/backup
      • understand how base services such as monitoring and logging transfer to a new provider
      • understand functionality of old provider vs new (control)
      • understand impact of performance and availability 
    • SaaS
      • Perform regular data extractions and backups
      • understand what metadata can be exported
      • understand custom tools that may need to be redeveloped
      • ensure backups of logs/access records are preserved for compliance reasons
    • Private Cloud
      • ensure interoperability between hypervisors
      • use standard APIs
    • Public Cloud
      • ensure cloud providers use open/common interfaces
    • Hybrid cloud
      • ensure the ability to federate with different cloud providers to enable higher levels of scalability
Summary

I personally found this chapter hard to get through.  Portability and Interoperability are fundamental tenants of any solution, in my mind.  Being a developer, you use concepts such as abstraction to make your code more modular.  Modularity leads to code being able to be ported to different environments and allow for extensions to be built to handle specific scenarios.  I think that this chapter basically echos those fundamental tenants (over and over again).  Although it is probably better as a checklist, there are some good points that are given.  Bottom line, use open standards.  Use open technologies.  Use open APIs.  Use Industry standards.  Plan for any deviations from the above.

No comments:

Post a Comment