Source: (Haukioja, 2013)
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.
This has been covered at the beginning of the book. As part of the reference architecture you should include information on:
- Cloud attributes
- Cloud services
- Private Cloud
- Community Cloud
- Hybrid Cloud
- Consumer Cloud
- Public Cloud
- Cloud Maturity
Reference Architecture Lite
The reference architecture is comprised of:
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:
- Microsoft Azure
- Private (build it yourself)
- Engine Yard
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:
- 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.
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.
Getting integration right is the difference between success and failure.
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.”
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.
Largely covered earlier in the book, you should still consider these high-level processes:
- Productionisation including:
- Data Migration
- Ongoing Release Management and Cycles
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:
- Operations Processes
- Service Request Fulfilment
- Change Management
- New Release Management
- 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.