Beyond the cloud, David Tebbutt explains how innovation leaders can utilise serverless technology to increase the agility of an organisation
Every now and then someone cooks up a buzzword that catches on. For a while anyway. Think of ‘mashup’ or ‘container’ or ‘AI’, for example. They all offer a useful shorthand for those in the know at the time. The buzzword du jour at the moment is probably ‘Serverless’. What it really means is ‘not on your server’, but that’s only the beginning.
You could argue that all cloud activity and third party hosting is serverless by that definition. What separates this Serverless from other hosted activity is that it generally means small, stateless, event-driven chunks of code that complete their execution in seconds, or less. A fresh instance is fired up by each event, meaning that it readily scales to huge volumes of parallel activity. The triggering event might be a change in a database, a button click by a website user, a request from a computer application or a message from an IoT device, for example.
It’s still early days for Serverless, which means developer tool vendors, software vendors and users are still working out the best way forward. Having said that, some organisations are already using the technique for large asynchronous data processing tasks and international marketing campaigns, with millions of people hitting their websites. The attraction is that simple functions can be created and deployed more or less at the drop of a hat, leaving most of the operational headaches to the hosting company. Not only this, but functions can be replaced equally easily, which is all right when they’re few in number. Get too many in an ‘always-on’ application and you’ll need to be very careful about how you orchestrate this to avoid service disruption.
You also have to think about how and where to implement the client side of the equation. The last thing you need is to have to write different code to run in each client from mobile phones to, say, Ubuntu desktops. At the smartphone end, especially, you’d need to keep a weather eye on battery life. While a lot of the operational pain is removed, a serverless approach to responding to user requests does require some deep thought about what processing actually needs to take place and where. You might want to keep some in-house, some with third party back-end services (like database or authorisation), some in the serverless functions and some in the end-user devices.
The value equation
Some speak of onions and others of stacks, the point being that all the value is created at the extremes while the rest of it is non-differentiating infrastructure stuff (network, firewall, management, etc.). Serverless allows you to focus your efforts on the two percent of the stack/onion that delivers unique value to your organisation. The cost of running functions on AWS Lambda, for example, is pennies – each function request is rounded up to the next 100ms and with a generous Free Tier allowance (up to 1M requests and 3.2M GB-seconds of compute time per month) which could mean that small operations never pay for anything. We watched CIO Stuart Harris at developer Red Badger create a small function, upload it and run it. Total cost $0.000000208. However, real life is never that simple and you have to be careful with structuring your deal. It would be better to try and split your development and production work across separate accounts to stop your tests and trials stealing cycles from your live services.
“With Serverless anyone can set up a service for almost no run costs and total cost of ownership. The great thing is total cost of ownership; you don’t need 24×7 support for infrastructure,” Harris at Red Badger says.
Serverless should bring considerable benefits. For example, your application development and deployment will speed up, your costs will fall and IT will become more responsive to urgent needs. If you traditionally have ‘bursty’ workloads then, over time, you can reduce server capacity, which is currently configured to handle peak demand. Depending on the other microservice partners you choose, your hosted code and data is also likely to be more secure.
None of the promises of Serverless will come true without significant forethought, not least in trying to properly understand the needs of your business. Some applications are simply unsuited to this new approach. They might be too complicated or, let’s be honest, too boring. They take the same amount of server time, month after month, without peaks or troughs. Why bother?
You will also need to explain to the leadership team why yet another new approach is needed. They ought to come round quickly enough when you explain what applications you’re targeting and how this is going to improve revenues, cut costs and deliver more profits – another good reason to think through the business needs first.
You may also need to harmonise the work of people in different teams. Hopefully, this is nothing new, but it’s likely that more fresh opportunities and insights can be gleaned from working together than in silos.
Serverless functions are perfect for companies like CarTrawler which connects transport vendors to travel businesses through a single intelligent booking engine. It creates demand for car rental, private transfer and rail services from over 2000 travel businesses. It provides access to exclusive sales channels, including 95 airlines. By consolidating multiple services, CarTrawler delivers the maximum return with minimum website real estate usage. Customers get a seamless and personalised shopping experience and a single point of purchase for all of their ground transportation needs. Harris of Red Badger was involved closely with the CarTrawler development.
“Serverless is really easy to deploy at the developer end,” Harris adds.
Resizing images doesn’t sound like a very big deal but, with different client screen sizes, it’s important that the user sees the most appropriate size and gobbles the least amount of bandwidth. The Seattle Times uses serverless functions for exactly this. In a different context you could imagine a web service getting all manner of user-uploaded mugshots and header images to display. It’s a bursty requirement which could be quickly and easily satisfied by a fairly straightforward serverless function.
Netflix is planning to use AWS Lambda to replace inefficient procedural systems in its applications with event-based triggers. By using AWS Lambda, the company will offer its developers a new layer of abstraction between their applications and managing the hardware to run them.
American fashion retailer Nordstrom used AWS Lambda to build a new recommendations engine that processes requests in seconds instead of minutes, and has experienced two orders of magnitude of cost savings.
As with every new development, a few leading lights start the ball rolling and before you know it there are more participants than you can shake a stick at. Just to show the variety and commitment of today’s community, here is a short selection of participants.
Lambda – is a compute service (runs Node.js, Java, and Python) on AWS which provides server and operating system maintenance, capacity provisioning and automatic scaling, code monitoring and logging.
Cognito – Amazon Cognito is a service that enables you to create unique identities for your users and authenticate them using either your own user pools or by using federated identity providers.
DynamoDB – is a fully-managed proprietary NoSQL database.
AWS API – Gateway is an http request handler.
AWS Kinesis – is a message bus.
App Engine Cloud – is a platform for building scalable web applications and mobile backends. It has built-in services and APIs such as NoSQL datastores, memcache, and a user authentication API. Like AWS Lambda, it takes care of provisioning and scales applications automatically so you pay only for the resources you use.
Microsoft Azure Functions – is an event-driven, compute-on-demand experience that extends the existing Azure application platform with capabilities to implement code triggered by events occurring in Azure or third party service as well as on-premises systems. Azure Functions allows developers to take action by connecting to data sources, messaging solutions or act as http-based API endpoints. Like the Google and Amazon offerings, Microsoft’s is scale-based and on-demand, so you pay only for the resources you consume.
IBM ‘OpenWhisk’ – is an open source on-premise or workstation implementation of Function-as-a-Service (FaaS)/API Gateway platform. It lets developers quickly and easily build feature-rich apps that automatically trigger responses to events.
Apex – lets you build, deploy, test and manage AWS Lambda functions and use languages that are not natively supported by AWS Lambda, such as Golang.
Auth0 – (pronounced auth-zero) – provides single sign-on services, abstracting various login and identity services into a single API, including public APIs like Facebook Connect and public or private instances of Active Directory and LDAP. Webtask, from the same company, is a FaaS platform that allows you to build serverless applications.
You’re in the hands of your vendor when it comes to system reliability, preset limits, cost changes and, for example, forced upgrades and API changes. Fundamentally, the provider is always going to be driven by the greater good, which might not suit your specific needs.
Again, depending on the professionalism of your provider, you could be exposed to general multi-tenancy problems (such as seeing another client’s data), interference between customers’ software and the workload of another client making your own software slow-down.
In the absence of universally agreed standards, you can be sure that the serverless features offered by your vendor will differ from their competitors. This could complicate a switch to a new vendor. Not insurmountable, but it will involve work on your operational tools, your code and, possibly, your architecture. And then you have to migrate your data. You can bet it’s not going to be straightforward. All these calculations would need to be made before even considering a move.
The more Serverless vendors you use, the bigger the surface area you create for attack. This needs to be taken into account when planning the best design and implementation of your code.
Multiple client platforms
We’ve mentioned this before. The less ‘standard’ your target client, the more custom logic you need for each separate client. This is repetitive work and changes need to be made on all client platforms before you can roll out a new iteration.
Lack of capacity
Vendors at the moment impose limitations on the number of concurrent executions that can take place and the maximum time each can run. As we mentioned earlier, trip over those boundaries and you could be in trouble. At best it means work gets queued and, at worst, the function is abandoned.
These are by no means all the issues you need to take into account. Integration testing could be a challenge because you need either to involve external services or rely on their effective stubbing of their functions. It is likely that all the vendors are aware of the issues and are trying to figure out ways to make your life easier. For now though, unless you know better, it’s best to take a pessimistic perspective.
Without question great benefits await you, providing you go into Serverless with your eyes open. If you think through the business case, the application architecture and find services you can trust, you can go a long way. If it suits your business model right now, you will dramatically cut your development and operational costs. And, just like medical research, new developments and discoveries will be made in hosting, developer tools and microservices to make your life even better.
To learn more about serverless and debate how to increase the speed to market of services and products with News UK CIO Christina Scott join Horizon on November 16 for an evening micro-summit in London. Register your place at: www.horizonbusinessinnovation.com/event/futureofthecloud