If you’re looking to move away from hybrid cloud and pack up your on-premises servers all together, but are worried about how your applications will run in the cloud, serverless computing could be the right strategy for you.
Serverless computing? Running everything on desktops?
Ah, no – serverless computing means building your server functions in the cloud, rather than on a local, physical machine. In this way, they can benefit from demand-driven management, spinning up as required then closing down again when, for example, the entire human race decides to stay at home for several months. Ideally, functions should be fully portable, eschewing platform-specific services and tricks, so they’ll run in any data centre.
So we can go serverless and retire our old servers?
It’s unlikely that you’d be able to do a straightforward lift-and-shift of your old, badly behaved suite of IT resources up into the cloud. Any function that depends on some older technology (say, for example, a Windows dialog box) will have to be rebuilt with modern tools that embrace scalability and movability. Indeed, even once you’ve moved, it might make sense to keep your older servers running in parallel for some time, as a fallback in case of unforeseen hiccups.
Could we at least streamline our local admin team?
If that’s your plan, make sure they’re ready to come back on a consultancy basis: you’re going to need their knowledge more than ever while the development is in progress, and likely for some time afterwards. Only the very simplest of businesses can make a consequence-free shift, and they’re still likely to need some techie oversight to ensure everything is scaling and behaving like it should.
Surely moving our everyday line-of-business functions off-site is going to slow things down?
If you have a big on-site compute load then it might, but for outward-facing services – that is, ones used by your customers rather than your employees – moving to a scalable architecture could speed things up. What’s more, a serverless approach easily allows for multiple instances so you can, for example, create different versions of your site for different users and markets.
Is it wise to put our critical functions in the hands of a third party?
Part of the beauty of the serverless model is that you’re not tied to any single provider. If there’s a problem with one host, you can just pop a serverless image onto a flash drive and fire it up somewhere else. Running instances here and there might not be cheap, but it’s a much more resilient position than one where yanking out a 13A lead will scuttle your whole operation.
Are there other benefits?
Most popular business apps are now very old: histories stretching back 20 years or more are not uncommon. That means you’re working with two decades of accumulated bug fixes, function changes and bloat. The process of moving to a serverless model gives you a chance to take stock, assess which parts of your code portfolio could work better in the cloud, and to re-engineer any broken or backward functions.
So when will our everyday apps go serverless?
Basic, network-shared apps aren’t going to magically transform into serverless versions: the cost of moving outweighs the advantages. However, it may be that service providers (like your card payment processor) migrate you to serverless because you’re only using one specific part of their offering, so it makes sense for them to only fire up the code you’re using. That move will probably be entirely invisible to you, though – which is just as it should be.
