Once there was a debate about whether we should move to the cloud or not. Nowadays there is little doubt that the future is cloud as the economic savings and transformational value that it provides are compelling. The debate now is how to move to the cloud, how quickly to do so and which workloads to move first.
Recent outages on AWS and Azure have shown that even the biggest clouds can fail, however organisations are increasingly wary of putting all their eggs in one basket. Typically, such organisations realize that there is a trade-off between proprietary cloud platforms which offer short term convenience and open cloud platforms that offer longer term flexibility.
Proprietary Clouds and Lock-In:
When we talk about proprietary cloud platforms, we mean providers that use technology stacks that are exclusively their own.
You can move workloads between two OpenStack environments without too much trouble or from one VMware provider to another. The problem comes with providers that run a proprietary stack of their own. The moment that you start using their higher-level services and writing to their APIs or to their complex feature sets, you are locking yourself in. For example, if an AWS customer using DynamoDB, Kinesis or Lambda wants to move to another provider, equivalents to these services won’t necessarily exist. Even where they do the software doesn’t transparently allow users to know the key-value store equivalent between the two, which means someone has to rewrite the application for every environment it sits on.
While the proprietary clouds may offer short term convenience, what happens when they themselves become legacy, or when they fail to deliver acceptable value-for-money, appropriate service levels or compliance with data protection legislation.
“While the major public cloud vendors (Amazon, Microsoft, Google) currently drive a great deal of innovation, they might also be trapping themselves and their customers into legacy situations.” Bernd Harzog, Network World.
The UK public sector was only too recently dominated by an oligopoly of about eight major system integrators that dominated the sector, leading to an environment of limited value for money and frequent major project failures. The UK government’s digital by design and cloud first policies, along with its G-Cloud procurement framework, allowed it to break free from this situation. The risk is that having escaped from an oligopoly of eight SIs we may see a move to a duopoly of proprietary cloud providers.
Multi-cloud is the answer, but there are different types of multi-cloud. The dream of workload portability is just that – a dream. The risk is that it will lead to a set of compromises defined by the lowest common denominator. This is not a particularly attractive proposition, and neither are the associated technical and commercial impediments.
Instead in considering a multi-cloud approach, one needs to consider using different clouds for different workloads – with each workload on the optimum platform. The options in order of increasing flexibility are:
- Proprietary clouds: These have a role to play in the mix, but only where there is a compelling rationale for their use (e.g. for Office 365) and only where trade-off between the lock-in and flexibility is fully understood.
- For example: AWS and Azure
- Portable clouds: These clouds are built on technology stacks that are offered by numerous providers, ensuring a level of workload and data portability. For example:
- An Oracle powered cloud provides specific solutions for complex licensing and mission critical support
- A VMware powered cloud provides a familiar and proven virtualisation platform, compatible with virtualisation environments run on-premise (hybrid cloud)
- Open clouds: These clouds are built on technology stacks that are not only offered by numerous providers, but are also supported by large development communities. For example:
- An OpenStack powered cloud provides powerful APIs and features that are available from many cloud providers – unlike AWS/Azure where the feature sets and APIs are unique to those clouds
- Containerisation and PaaS: these provide a further layer of abstraction which can allow developers to use feature rich APIs that are convenient and powerful, while also independent on the underlying IaaS.
- For example: RedHat Redshift and Docker
You need to match the workloads to the most appropriate environments. There may be some new projects where applications can be developed specifically for the new digital environment as cloud native applications, however the reality is that the vast majority of workloads are on legacy platforms and in legacy applications, and moving these to the cloud can appear a daunting challenge.
Typically, this is done in a pragmatic phased approach:
- Assessment of legacy estate: Audit of the inflexible, out-dated infrastructure that is restricting digital transformation.
- Transition: Relocation of existing architectures onto modern, agile and trusted IaaS.
- Transformation: Adoption of cloud native architectures to provide scalable, flexible platforms.
- Digitisation: Optimisation of business processes and transactions to exploit the agility of the cloud.
|Example: Oracle Workloads:Back in 2012 the Cabinet Office signed a three-year deal with Oracle and many public sector organisations still retain a significant number of Oracle workloads along with other legacy applications.
Oracle has a reputation for ruthlessness when dealing with its customers. It locks customers into opaque licensing agreements, and subsequently uses technicalities to issue ‘breach notices’, and force clients to raise their retainer to Oracle without any increase in the quantity or quality of their services. A Freedom of Information request in 2015 looked at how much London’s borough councils were spending on Oracle licenses. Over a third (37%) reported that their spending on Oracle had increased by over 20% in the previous two years, while four councils (15% of the sample) had experienced an audit conducted against them in the previous year alone. This demonstrated the willingness of Oracle to strong-arm British government bodies.
Indeed, DEFRA with around 10,000 staff, found that it was paying for 2m Oracle licenses at £155 per employee, for an annual cost of £1.3m per year (at 200 licences per civil servant). This is way above the Cabinet Office guidelines of £93 on licenses, with a view to reducing that down further to £52.
The most straight-forward solution is to transition (see phase 2 above) to an Oracle cloud hosted by an independent cloud provider. With a software stack powered by OVM hypervisor, it can be optimised for the performance and availability of Oracle workloads. This provides full compatibility with support for Oracle-based solutions such as Oracle Database (including features such as encryption and Data Guard), Oracle WebLogic Server, Oracle Fusion Applications, Oracle Enterprise Manager and Oracle E-Business Suite. It also enables you to comply with Oracle’s licensing requirements, while reducing your licencing costs as you only need to license only the processor cores used.
- Avoiding Lock-in: Lock-in is one of the main concerns of the UK public sector and it can come in many forms. There is not only technological lock-in (as mentioned earlier) but there is also contractual lock-in. G-Cloud may specify 2-year maximum contracts, but it doesn’t specify exit costs or protect you from some of the other methods that some providers use to lock you into their service. You need to select a provider that is committed to being easy to adopt, easy to use and easy to leave.
- Sovereignty: Recent concerns with the outlook for the Privacy Shield arrangement for transatlantic data sharing, as well as intrusive extra-territorial US laws, mean that it is no longer enough simply to ensure that your data is hosted and processed in the UK. You now also need to ensure that you use a UK cloud provider rather than a US-based one in order to avoid legal intrusion.
- Specialist vs Generalist: Speak to any public sector organisation and they will describe their needs as unique. The global generalist public cloud providers simply aren’t as well placed to meet these needs, as a provider that specialises in services for the UK public sector.
- Certification and accreditation: Only a handful of providers have platforms that meet all government’s requirements in this respect.
- Data Gravity: In considering your multi-cloud strategy, you may want to find a single provider that can offer as many of the options mentioned above as possible and that already hosts a number of other key government workloads. This would give you the advantages of data gravity where all your workloads, along with workloads from other departments, share direct access to the same core data sources in immediate proximity.
With less than 10% of central government workloads currently in the cloud, and an even lower ratio elsewhere in public sector, there is still a great deal of work yet to be done. The Government Transformation Strategy is clear on the size of the challenge and the direction of travel. Hopefully a multi-cloud strategy as outlined above will help you on this path.
This blog first appeared on Advice Cloud