I thought I’d put together an overview of Cloud Strategy Considerations. This isn’t an exhaustive list, is provided for discussion and as with many of my blog posts is partly an aide memoir.
We need a cloud strategy!
Cloud services are not going away, they are very much here to stay. Many organisations will be reviewing strategies for adopting cloud services. It could be argued that early adopters have proved that organisations can live in the cloud, paving the way for every organisation to look again at what is configured in the data centre. To look again at the traditional approach to providing IT services, to perhaps revisit existing plans for legacy application upgrades.
For most organisations this will need to be evolution rather than revolution. mature organisations, by virtue of being older, will most likely be carrying additional technical debt. By that I mean these organisations made decisions that whist correct at the time, perhaps tie them to a technology stack that doesn’t naturally translate to cloud services. Many organisations have invested in data centre technologies perhaps on a path to the software defined data centre. these organisations will not be in a position to write off this existing investment. Something that will need to for part of an organisations cloud strategy considerations.
Why do we need to think about our Cloud Strategy considerations? Do we even need a Cloud Strategy?
Cloud computing, its related products and services are now firmly established and provide end users with quick and easy access to ready to use products, including email, project planning software, collaboration and document management products. These services are available and accessible online with out the need to follow any process, can be purchased in the company name with a credit card and an email address. They can be purchased without any governance or guidance.
- Data security cannot be guaranteed.
- Data ownership cannot be guaranteed.
- Intellectual property rights (IPR), cannot be guaranteed.
- Guaranteed Service Levels defined through Service Level Agreements (SLA’s) and Operating Level Agreements (OLA’s).
- Initial cost considerations can be wildly inaccurate when numbers of users and data usage are considered.
- Circumvention of rigour and supplier due diligence.
- Compliance and solution auditability.
In the absence of a cloud strategy an unmanaged and ungoverned cloud will be created. The organisation is going to work around architecture and the IT department if a cloud strategy is not agreed and put in place.
What is the Cloud again?
Cloud Computing has been used as a marketing label in the IT industry, the label itself isn’t particularly helpful for understanding what cloud computing is or what it delivers for the business. For the purposes of this discussion we can think of cloud computing as a general term for the delivery of hosted services over the internet.
To expand upon this, cloud computing can be seen as an evolution of internet delivered services, enabled by infrastructure advances, most notably with networking and connectivity. Typically these services are delivered from multi-tenanted data centres. These contain multiple unique individual companies hosting information within the same infrastructure, to achieve economies of scale.
Those services that twenty five years ago required deployment on premise, and fifteen years ago moved to managed hosting at a co-location have now evolved in symbiosis with infrastructure advances to a point where nearly every infrastructure element has a cloud service equivalent. Think of the speed of your home internet connection, how the available bandwidth has increased and what that has enabled.
Being able to leverage the economies of scale in the cloud has created the ability to quickly investigate opportunities and deliver services. All provided by computing on a scale and flexibility that would have been previously cost prohibitive to organisations without the financial muscle to invest.
Cloud computing is generally labelled as fitting into one of the following categories;
• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Software as a Service (SaaS)
Separation of responsibilities
Each of these services can be understood a little better by comparing where the cloud providers responsibilities end. and the customers begin. The below diagram aids this discussion.
From the diagram you can conclude that there is a risk/control difference within each level of service. Where the services are de-risked and wrapped up in an SLA by the cloud vendor, they are done so by the customer relinquishing control over those elements. This is not a new model. IT risk and costs have often been reduced through partnerships with strategic vendors. Cloud is a natural further extension of that. Virtualisation technologies coupled with cost effective higher bandwidth connectivity, provide opportunities to extend the reduction of IT risk and cost.
Cloud Strategy Considerations
CapEx vs OpEx
I mentioned cost in the last paragraph, this is another major differentiation between the utilising cloud services and self hosting and managing those services. Cloud computing works on an operational expenditure model (OpEx), by that I mean that you only pay for the services that are configured and are being consumed. This is a departure from the capital expenditure model (CapEx) which requires up front strategic investments that need to be realised. Being realistic, cost is always going to be chief amongst any cloud strategy considerations.
On-Premises or Cloud
For many organisations the move to the cloud has to be an evolution rather than revolution. This could be for a vast number of reasons ranging from technical debt, data classification and residency challenges or depreciation of previous CapEx. These are items that any cloud strategy needs to address. The existing environment needs to be understood, as that understanding will feed into your cloud strategy considerations.
We touched upon technical debt previously. This is the term coined to describe the scenario where for all the right reasons and organisation might have implemented a solution that was quick and easy to implement, but might not have been the best overall solution. A solution that was implemented for a short term tactical goal, that wasn’t designed for longevity and then became entrenched as service perhaps. Or a solution that with the benefit of hindsight might have been implemented differently. Nobody has a crystal ball and as a result a degree of technical debt is always going to exist. This technical debt might make the moving those services to the cloud painful or even cost prohibitive. So an alternative path is required.
Data classification, identification of compliance requirements and data residency is another big challenge. If as an organisation you are unaware of the data that you are holding then how can that data be moved to the cloud? How can the services that interact with that data be designed and built? how can the storage policies for that data be designed and built? I would like to point out that in the UK, every organisation should be aware of the data it holds and it’s classification under the Data Protection Act 1998, forget GDPR, organisations are supposed to already know!
Perhaps an organisation has data that ranges from tightly regulated data sets, to data that has no regulatory obligations and is freely shared within the public sphere. In this scenario an organisation might have a regulatory obligation to hold some data sets on-premises, where as some could be utilised in the cloud with little concern.
Both in the case of technical debt, where some services cannot transition to the cloud and data classification whereby some data is obligated to remain on-premises, describes scenarios covered by a hybrid cloud.
A hybrid cloud is the term used to describe an environment that makes use of a mix of on-premises private and public cloud services, with either communications and ideally orchestration between the two platforms. This orchestration aims to simplify the moving and placement of workloads to the correct cloud platform dependent on compliance, computing and budgetary requirement.
A hybrid cloud solution does not need to be a distinct relationship to a single cloud vendor, hybrid configurations could indeed take into consideration multiple cloud suppliers and technologies.
Cloud Code Deployment
In an organisation with an existing development team, there will be a defined method for writing, reviewing, version control and releasing code. Perhaps this is managed on-premises, perhaps this is already managed from the cloud, via GitHub, BitBucket or VSTS. Perhaps continuous integration is already a reality within the organisation?
Whatever the existing arrangements are these need to be considered as part of the cloud strategy. To ensure whatever cloud solutions are implemented they function with development tooling and working methods. Again the existing environment needs to be understood, as that understanding will feed into your cloud strategy considerations.
Technologies to cover
As part of the cloud strategy, it might be appropriate to document individual strategies for the following technologies.
Public cloud providers. What strategy is require or in place for each cloud vendor? Does one coverall strategy and guidance document apply to all of them? Or are the differences in approach and the offered service mean that a different strategy is required for AWS, Azure, Google Cloud or vCloud Air?
IaaS. As is apparent in the segregation of responsibilities diagram, deploying IaaS cloud infrastructure still comes with a heavy management commitment for the OS up. How are those elements going to be managed? What are the strategic principles governing patching, anti virus, backup, monitoring or any management stack element? What are the strategic principles and guidance that governs storage policies, networking, connectivity, availability, continuity, disaster recovery for example? What are the principles around vendor lock in? does the vendor use a proprietary VM format, that cannot be exported or converted?
PaaS. Deploying PaaS infrastructure still comes with a management overhead for the data and applications. Whilst the hosting of the environment up to the data tier is managed by the cloud provider SLA, configuration of and adherence to that SLA is still a customer responsibility. What are the strategic principles regarding the deployment of PaaS services? What are the strategic principles and guidance that governs monitoring, storage policies, networking, connectivity, availability, continuity, disaster recovery for example? What are the principles around vendor lock in? At the PaaS level cloud vendors are going to have very different ways of operating, how do you maintain portability? is that important?
SaaS. The level of control of how a SaaS service is deployed and managed is minimal. However, strategic consideration should be made to agree what type of features these services should have. For example, does the strategy recommend that an organisation only adopt SaaS services hosted within a specific country? Where the supply chain is transparent? Where the data is portable and exportable or that work with other key building blocks?
On-Premise, Private cloud. What is the strategy for these environments? How do they connect to cloud service providers? How do they consume cloud services? How do they mirror or replicate cloud services? Does the management stack need to integrate with the cloud services? How do local and cloud services communicate at a service layer (Biztalk, Service Bus, sftp)?
Hybrid Cloud. What are the principles that govern workload placement? What are the principles that govern data placement? How are those principles communicated and audited? What principles and guidance governs the orchestration and automation between the on-premises and cloud environments?
The requirements and principles of the organisation need to be understood, as that understanding will again feed into your cloud strategy considerations.
Cloud Strategy Deliverables
These obviously vary based upon the organisational requirements, however the following represents some thoughts for consideration.
Availability; The cloud services are capable of supporting 24 hour/seven day a week operations. Adoption of cloud services should be planned to take advantage of this and to eliminate downtime. Services and applications utilising either cloud services should be able to point toward zero unplanned downtime. many clouds include services that would be expensive or impractical for smaller organisations to implement.
Portable; cloud strategy should consider the portability of services and data. Can the services be moved between the on-premises and public cloud? Between public clouds? portability between clouds potentially provides organisations with strategic advantages as prices fluctuate and new services come online.
Scalable; cloud services are capable of being fully scalable, to not only meet demand but to shrink when the demand is not there. cloud strategy can highlight the operational advantages of scalability.
Compliant and secure; securing and ensuring compliance within a legacy infrastructure, is challenging. the cloud services are being designed with compliance and security built in. Many clouds hold high levels of compliance for services and include security features inaccessible or expensive for smaller organisations to implement.
Agility; another buzzword, however through features such as automation, continuous integration, collaboration and desired state configurations the cloud can provide a level of agility that the on-premises environment will struggle to replicate.
Cloud Strategy Considerations Summary
The above represents some thoughts that can form part of you cloud strategy considerations. I’ve not mentioned at great length TOGAF in the above post. However, if you are coming at this from a technology perspective, I’m sorry to say you need to refocus toward the business requirements.
Any public cloud variant is hugely powerful, the potential is there to configure environments for any and all eventualities, to replicate data to all corners of the globe and to ensure a service is never offline. This is why it is so important to ask if the business needs those features. Remember from a TOGAF perspective; technology exists to support the data and application requirements which in turn support the business requirements.
Try not to get lost in a technology rabbit hole or be scared of asking the business what they need!
When creating a cloud strategy, keep the identified requirements and any organisationally agreed architectural principles foremost in mind and you’ll arrive at a robust strategy.