Are you thinking about moving your systems to the cloud? Or already made the leap?
Trowers & Hamlins guides clients through all aspects of IT contracts, service engagements, terminations, procurement and legal compliance, and emphasise the key considerations that impact these agreements to ensure they are watertight.
When drafting legal documentation and reviewing the proposed terms for the supply of services by IT service suppliers, they urge clients to identify what they require, how it should be provided, and who should provide it.
This approach clarifies two key questions:
- Will there be issues with how they move to the cloud?
- How can they manage their cloud environment to avoid unexpected costs?
Answering the 'how'
In working out the best way for how you should move to the cloud, have you identified and considered any issues due to the nature or activities of your organisation, or its current arrangements, that will or may cause problems in moving to the cloud?
There are different ways to move to the cloud.
- Lift and shift: Your organisation's applications and associated data are ‘lifted‘ from its existing environment and ’shifted’ to the cloud 'as-is' (i.e. with no or only minimal changes). On the plus side, this approach means your organisation can move to the cloud quickly and the moved applications and data will no longer be operated from your on-premise computers, which means that the burden of operating, maintaining, upgrading and backing up those machines ceases. The downside is that your organisation's applications remain the same, and it is still responsible for operating, patching and fixing them and that your post migration pricing might be higher than anticipated – as we explore further below with comments from Waterstons, a recognised IT services provider.
- Using SaaS: Using software-as-a-service (SaaS), applications to replace the use of their previous applications. On the plus side, the applications are already cloud native and should have clear pricing. The downside is that the 'out of the box' generic nature of such applications might be unappealing to your organisation's particular operational needs.
- Building your own cloud-native solutions: Using capabilities provided by platform-as-a-service (PaaS), such as AWS stack or Azure stack. Aside from your organisation building to its own requirements, the plus here is that it uses databases as a service, and gives access to huge [DF1] [JB2] storages of data for analytic purposes. On the downside is the unpredictable nature of the costs of this approach if this method is not managed properly.
We often see 'lift and shift' migrations conducted by the organisations typically with the assistance of IT consultancy advisors.
The issue with 'lift and shift' is that applications and data not already in the cloud or operating in the desired environment will require reconfiguration. In their 'as-is' state, they won't provide adequate, let alone optimised, operational service and cost efficiency in the cloud environment.
In which case, 'lift and shift' migration should only be considered if your organisation has either:
- a critical and unavoidable reason to do so (e.g. end of life of existing system, hardware failure, or having no confidence in your organisation's datacentre); or
- a plan by which it first moves the applications and data into the cloud on the basis that they will be reconfigured appropriately (from a service delivery and operating cost perspective) to SaaS, PaaS or microservices.
Unexpected and uncontrolled costs: the curse of choice with activity-based cloud fees
The pricing structure for the cloud platforms (into which you have 'lifted and shifted' your applications and data) is typically based on a mix of elements, some of which concern how you use the platform, rather than being a fixed 'cover all' fee.
Cloud platform pricing often isn’t a fixed fee but depends on how to use the platform. For example, imagine a landlord not charging tenants a fixed monthly rent, but instead separate fees for particular activities and usages of a property. For example, £10 each time a door is opened or closed, £5 each time you sit on the dining chair.
Organisations migrating to the cloud without fully understanding how their applications consume resources can quickly encounter unexpected and uncontrolled costs. This is especially true with a 'lift and shift' approach, where legacy systems are moved to the cloud without optimisation.
This is the principle of the issue that unprepared users of cloud platforms might face if they don't recognise the resulting charges that will accrue in a cloud platform 'activity based' pricing scheme and plan accordingly.
The cloud platform provider will argue that their 'activity based' pricing structure gives the customer the freedom to optimise its platform operating costs by exercising choice and control over its related activities.
However, in practice, it's all too easy for an organisation to lose sight of that with the effect that well-meaning activity by it to test or develop applications or data within its cloud platform might cause it to receive an unexpectedly large bill.
This can be the 'curse' of choice, however, there are steps that can be taken by your organisation to avoid such costs shocks.
Justin Whelan, our Lead Cloud Solutions Architect shared the following observations and guidance.
We've helped organisations to resolve issues after 'lift and shift' migrations where those organisations had not properly anticipated, or understood, the consequences of moving to the cloud, and then seek to scramble to make cost savings to counter unexpected costs after they had migrated.
Such unexpected costs can arise for many reasons, including due to:
- A misunderstanding data storage pricing models - where an organisation chooses Azure File standard tier storage for a frequently accessed repository, believing it to be the cheaper option - however, high transaction costs ultimately make it more expensive than premium storage.
- Idle resources – where development environments remain running on weekends, over-provisioned virtual machines stay active, and old testing data is left in storage indefinitely.
- Excess capacity/ resources - where an organisation provisions virtual machines with far more processing power and memory than their day-to-day workloads ever require, leading to wasted spend.
- A lack of cost visibility and governance - where the incidence of unexplained costs increases, or there is difficulty attributing costs to specific projects or teams, or regular cost optimisation processes are not exercised.
- Ignoring savings plans or reserved instances - when an organisation runs a production database 24/7 where peak demand is predictable, but pays on an on-demand basis, it misses out on substantial discounts that might be available with reserved instances the cost effectiveness of which can be increased by the length of time an organisation agrees to commit to.
- Overlooking the evolution of cloud services – where an organisation continues using an older, more expensive database service despite there being new options with better price-performance ratios available.
In Waterstons' experience, the best practice to mitigate the above includes:
- Analysing workload access patterns thoroughly before selecting a storage tier
- Using pricing calculators to accurately compare storage tiers, factoring in transaction costs
- Reviewing regularly storage choices as an organisation's application usage evolves
- Implementing automated shutdown/start-up schedules for non-production environments
- Regularly assessing resource utilisation and right-size resources (i.e. CPU, memory, storage)
- Leveraging auto-scaling to add or remove resources dynamically to reflect demand
- Using performance monitoring tools to identify over or under-provisioned resources
- Experimenting with different VM (virtual machine) sizes to find the optimal cost-performance balance
- Leveraging auto-scaling to automatically adjust resources based on workload demands
- Using cloud-native cost management tools for granular spending insights
- Implementing clear budgeting, monitoring and alert mechanisms
- Enforcing a strong tagging policy to track costs across teams, projects, and resources
- Establishing a process for regular cost reviews and optimisation actions
- Analysing workloads with predictable usage patterns to determine if they qualify for savings plans or reserved instances
- Using cost calculators to compare different commitment lengths and upfront versus on-demand costs
- Staying informed about new cloud service releases, features, and pricing updates
- Proactively assessing whether new offerings could better suit your workloads
- Incorporating experimentation and testing into your cloud usage strategy.
If any of the above makes you question whether you are adopting the best approach for your organisation's IT service demands and applications, we’re here to help.
Waterstons’ Justin Whelan can find the best solution for you, and support your migration – get in touch at justin.whelan@waterstons.com
Alternatively, if you’d like advice on IT systems and cyber security support services from a legal perspective, Riccardo Abbate – Trowers Partner, Corporate and Commercial – can be contacted at rabbate@trowers.com
