blueprint-and-gearsCloud Reference Architecture Lite

Source: (Haukioja, 2013)

Introduction

This section is a high-level reference architecture for Cloud. There are a number of detailed books about this already, and this chapter represents an amalgamation of those. Again, I have covered some of this earlier in the book, so some items are noted for completeness only.

Cloud Definition

This has been covered at the beginning of the book. As part of the reference architecture you should include information on:

  1. Cloud attributes
  2. Cloud services
  3. Private Cloud
  4. Community Cloud
  5. Hybrid Cloud
  6. Consumer Cloud
  7. Public Cloud
  8. Cloud Maturity

Reference Architecture Lite

The reference architecture is comprised of:

A platform

This section needs to select a platform, or platforms on which your Cloud services will be based. A selection criteria should be developed for the platform that takes into account the various needs of the ICT service. There are a number of global platforms available currently that can help support your move into Cloud. Each comes with its own advantages and disadvantages. As a starter for ten, these are platforms worth investigating:

  • Amazon
  • Google
  • Microsoft Azure
  • Private (build it yourself)
  • Intuit
  • Facebook
  • Salesforce
  • Engine Yard
  • Rackspace
  • GoGrid

There are many other providers of platforms that are also country specific.

It is worth bringing the Appendix A – Risk and Assurance Sample Model into play at this point to assist in selection.

A presentation layer

The direct interface between your users and the Cloud requires a presentation layer. Remember to consider items such as:

  • Browser support, now, and in the future. This is critical, particularly for SaaS deployments.
  • How your current clients will need to be managed from mobile applications through to company desktop clients.
  • Other end device support.

This is a complex piece of work given the proliferation of devices, operating systems, browser types, all with their own particular quirks, roadmaps, and versions.

Security and Privacy (Identity)

The ugly step sisters are commonly known by the name “identity”. This section requires a significant amount of thought as it is still the number one area that puts companies off utilising Cloud services. Ensure you consider:

  • Authentication.
  • Federation.
  • Single Sign on (including personalisation).
  • Identity architecture.
  • Identity service providers.
  • Access controls.
  • Application management.

This area is extremely complex, especially if you intend on a hybrid model across multiple Cloud providers.

Integration

One of the greatest impediments to the wholesale adoption of Cloud services is the lack of skilled integrators in the marketplace. Because it touches every layer of the technology stack, it further increases the complex web that allows you to integrate with Cloud services. Ensure that you cover:

  • Network connectivity from LAN, WAN, Internet gateways, mobile access, and any other content delivery mechanisms.
  • Integration with your ICT services including Legacy systems, back office, and any other external Cloud systems you have.
  • A data model is essential.
  • Consider the use of Application Integration services.
  • Middleware.

Getting integration right is the difference between success and failure.

Data

A section broken into three parts, this called also be called “Information.” Consider:

  • Storage. Capacity planning, other storage requirements, analysing the various storage (IaaS) options that are available along with planning your interfaces, and, most importantly, defining your Information Lifecycle policies.
  • Relational Databases. Ensuring that these are able to be transported and supported.
  • Non-Relational Data. Analysis the demand for this and completing a capacity plan while ensuring that the services you take up are fit for the type of data. I.e. Documents versus images.

Understanding and building for data is important for three reasons. Firstly, performance. Secondly, capacity that increases without planning will cost you. Lastly, it drives a conversation (information lifecycle management) with your business about what is important and what is less important. Beware the organisation that has a policy of “keeping everything.”

Service Resilience

This is an often missed component of architecture (or often ignored by the sponsors) which is critical. What happens when something breaks? Resilience planning needs to include:

  • Availability. What hours must the service be up and running?
  • Reliability. What percentage of the availability metric must the service be reliable? I.e. 99.999% between 9am and 5pm.
  • Recoverability. How long will the service take to restore post disaster and how much data will be lost? I.e. Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
  • Elasticity. Ensure this covers vertical and horizontal scaling along with sharding particularly where high performance burst computing is important.

These metrics in particular need to be agreed with your business as part of the architectural process.

Deployment

Largely covered earlier in the book, you should still consider these high-level processes:

  • Development.
  • Testing.
  • Staging.
  • Productionisation including:
    • Release
    • Data Migration
    • Ongoing Release Management and Cycles
    • Rollback

Operation

This is largely covered as part of the Service Design chapter in this book. However, it is worth noting for completeness the following areas to be covered:

  • Configuration of the Service. Including a potential CMDB, how provisioning works, and other automation of the service.
  • Administration. This covers the ICT operations of the services and needs to include:
    • Portals
    • Operations Processes
    • Service Request Fulfilment
    • Change Management
    • New Release Management
    • Monitoring
    • Capacity Management
    • Availability Management
    • Access Management
    • When it breaks. Ensure that incident, problem, and event management are catered for.
    • Continuous improvement. Define the process, ensure the business is included in the circle, and keeping an eye on the technical horizon.

These posts are taken from my book “Embracing Cloud: How to migrate your ICT Services into the Cloud.” The full book is available via Gumroad as a PDF or Amazon in Kindle Format. 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s