SaaS vs IaaS vs on-premise: What if moving to the cloud is not the answer?
In this guest post, Richard Blanford, managing director of G-cloud-listed IT services provider Fordway, advises companies to weigh up the pros and cons of using SaaS and IaaS before going all-in on the cloud.
For many organisations, moving to the cloud makes complete business sense. If I set up a business now, I would run all my IT in the cloud.
But that doesn’t mean a ‘cloud for everything’ policy will work for every company. Most of us are not starting from scratch or working with a small number of relatively straightforward applications. Therefore, we need to consider carefully whether all our applications can be transferred efficiently and cost-effectively to the cloud.
The first step should always be to look for an appropriate SaaS service. This should provide:
- A suitable application that can be configured (where and if necessary) and data imported to provide comparable or better functionality to existing applications at a suitable price, paid on a metered basis, ideally per user/per month. It will ideally offer tools and communities so you can benefit from the experiences of those who’ve already implemented it.
- A supporting infrastructure which is no longer your responsibility with an appropriate, fit for purpose SLA that meets your business and operational requirements.
- The ability to easily and cost-effectively access, import and export data to other applications for analysis and business reporting.
Once you’ve identified such a service, and confirmed it offers the right resilience at the right cost, you can simply consume it, whilst monitoring to ensure you receive what you’ve signed up for.
The best analogy for SaaS billing models is that it is like turning on a tap to obtain water, rather than going to a well to collect it, before readying it for consumption through purification, for example. Good SaaS provides what you need when you need it, and you’re billed for what you use.
Assessing the cloud-use cases
Cloud is also cost-effective for non-live environments where you pay as you use. This includes disaster recovery (DR), where all servers can be held in a suspended state without incurring charges until needed, and test and development environments, where you only pay when your code runs.
All you need to provide is management. Just be aware that different cloud providers’ Platform as a Service (PaaS) offerings have different APIs, so there’s some element of provider lock-in that may come into play.
It’s more difficult to find appropriate SaaS offerings for niche applications and those that need to be customised to align with business processes. Many application providers are developing their own SaaS strategy, but these typically only support the latest version of the software, and many cannot accept customised applications or third-party add-ons.
This can be a particular problem for local authorities and the NHS, who use highly customised applications for services such as parking management, waste collection and medication prescription and management.
We’ve investigated many ‘SaaS’ offers for our customers, and all too often the vendor will simply park and maintain a dedicated version of the user’s software on a public cloud service while charging a premium price.
SaaS vs. IaaS
If SaaS is not an option, there is also IaaS to consider. You simply move your application (as-is or with minor enhancements) to operate from a cloud provider’s infrastructure. This frees you from the need to own, operate and manage the infrastructure hosting it, although you need to retain licences and support from the application provider.
There are two provisos with IaaS. First, each provider has different design rules, and you need to work through their menu of choices to find the right solution for your organisation. This requires a thorough understanding of your environment, such as how many fixed and mobile IP addresses are needed, whose DNS service will be used, how much data will go in and out of the cloud etc.
Think of it as choosing a separate hub, spokes and rim for a bicycle wheel rather than simply buying a complete wheel.
The devil’s in the detail
Many organisations don’t specify their IT to this level of detail, as once they’ve bought their infrastructure they use all the capacity available. In a cloud environment, however, everything is metered, and – unless the service can be specified extremely tightly – it may not work out cheaper than in-house provision. For example, you can reduce costs by reserving instances, but you are then locked in for one or three years, with a significant cancellation charge. A similar issue arises when buying spot instances, and these can be shut down with no notice, so aren’t suitable for business critical services.
Secondly, the cloud provider only provides hosting, including host and hypervisor patching and proactive infrastructure security monitoring. Any other patching (plus resilience, back-up, security and application support and maintenance inside the instance) need to be provided in-house or by contracting third parties. Any scaling up or down has to be done using the cloud provider’s tools, and this quickly becomes complex when most organisations have on average 40 applications. In short, managing IaaS is effectively a full-time job.
Much of this complexity can be hidden by using a managed IaaS service, where a provider handles everything from operating system provision and authentication to patching and back-up, and charges for an agreed number of instances per month. Managed IaaS services effectively offer your legacy application back to you as SaaS.
This complexity should not deter you if you are determined to transfer your applications to cloud. However, it is important to go in with your eyes open, or to find an expert to go in with you. Alternatively, if SaaS is not available and IaaS sounds like too much work at present, there is a solution: configure your IT as a private cloud. You can then continue to run it in-house with everything in place to move it to SaaS when a suitable solution becomes available.