What we do
Is moving to the cloud a good choice for cost, resilience and application availability? Unless planned correctly, a cloud migration can turn into a money-gobbling clunky nightmare. When an application is architected correctly for the cloud, your concerns and worries will simply disappear - into those clouds! But how exactly do you reduce risk, gain a higher SLA whilst increasing application resilience and performance whilst saving money at the same time? Let's get into the details!
It is a common misconception that moving to the cloud can instantly save you money. For some cases, this may be true but for most the cost of "lifting and shifting" a solution that was designed for an on-premises hypervisor or physical platform can lead to increased running costs in the public cloud.
The first consideration would be the equipment you are migrating from. It would not be a fruitful move to migrate to the cloud from new hardware due to the capital expenditure cost - unless there was another business use for the existing hardware.
If a solution is not correctly designed for the cloud, then spiralling costs can cripple dreams and bank balances!
It is very easy to forget how much power is costing you in your on-premises server room. Over 90% of a typical cloud platform solutions billing cost is exactly that. Power!
So how do I make the solution cheaper in the cloud, increase uptime and resilience? Keep calm, and re-architect!
Imagine the line of responsibility in relation to a service level agreement (SLA); you have a clear-cut set of responsibilities versus the cloud providers SLA against the service in question.
Platform as a Service (PaaS) gives you a platform on which to place a solution. This may be a Server OS and upwards. Your responsibilities are the applications that sit on that server, AV and patching, security, access management and so on.
If you hop up a level on the 'X'aaS ladder, then things change quite drastically. Take Software as a Service (SaaS) for example. By consuming this service, you will get an SLA against the availability of the software itself. Responsibilities, in the case of SQLaaS (as an example), would be anything to do with the data, and the permissions to access it along with any queries sent - not the SQL platform itself.
You are also gaining an SLA associated with the service itself as opposed to the platform it is sat on. This will improve the server that is provided to your application consumers, and reduce your own risk at the same time. Win-win!
The cloud platform is all about offloading risk and gaining an SLA. This all sounds great, but what does it mean?
Do you remember that time on a Friday night when the business systems went down, and someone was on-call to fix the issue? Most of us have been there. We must identify and diagnose the problem, find a solution, and bring the systems back online. Before we know it, we are into the small hours of Saturday.
With an SLA applied to a cloud service, any issues causing downtime or an outage are fixed for us and a full root cause analysis is provided leaving us to get on with other things!
In traditional solutions, there are some limiting factors to an applications longevity. Hardware typically spans a 3 to 5 years' lifecycle, so an application that sits on hardware has a limited timeline. Microsoft Server OS is limited in terms of support and updates over time. Applications are open to support variables set by the software vendor. This could mean a long healthy application life, or a short one.
So, let's imagine moving this workload to the cloud. The first thing to do is remove the hardware lifespan limitation as this is managed for you. Limiting factor are now the Server OS and application. If the application would run on Microsoft Server 2016, then this is another limitation removed due to the nature of perpetual updates in Server 2016. The only limiting time factor now is the lifespan of the application set by the vendor.
If the application can run on multiple nodes, then it can be placed into a scale set which will allow server scaling, both outwards (quantity), and upwards (size). This provides resilience and an even higher SLA. This also means any unused compute nodes will shut down when idling, saving you huge amounts of money!
Simply put, if the cost of re-architecting an application to utilise SaaS or scale sets, is less than the cost of running the application for its remaining life-cycle "as is", then it's a task well worth undertaking.
Saving money, gaining a higher SLA and offloading risk are all beneficial factors!
Softcat has teams that specialise in re-architecting infrastructure for migration to public or private cloud, and hybrid deployments. We can work with you considering budgets, application risk and help you to determine the best solution for your requirements. Contact your Softcat account manager for more information or get in touch using the button below.
We would love to hear any comments you have about this article!