What is serverless architecture?
We explain the basics of serverless architecture, including benefits and drawbacks
Serverless architecture is becoming an increasingly popular method of running IT infrastructure without having to take ownership of physical servers. The approach provides far greater flexibility for those organisations that want to have the confidence and privacy of operating their own servers, but may otherwise not have the resources to manage them.
Most modern cloud companies operate using serverless architecture, including the likes of AWS, Microsoft and Google. Businesses are able to hand over the management of infrastructure to these providers, who use software to automate the process - leading to a system that's far more efficient than anything possible using a physical server.
Besides the initial savings of no longer having to buy physical servers, the day to day running costs are also far lower. This is because most providers operate a pay-per-use model, rather than paying from the moment a server is switched on.
Serverless is also far more flexible than traditional deployments. Resources can typically be scaled up depending on business demand, with the provider allocating new server capacity on the fly - though this usually comes with added cost. In the past, business processes were tied to the capacity of the physical server, forcing them into either short term investments in new equipment that may or may not have been used again, or risking overloading their systems.
Businesses can also deploy talent and manpower far more effectively, given they do not require employees to manage on-site servers. Handing over this responsibility to providers can allow businesses to reassign IT staff to other tasks.
The increasingly popular method of process hosting can run different types of back-end code in tandem. Serverless code can operate alongside code written in the traditional server styles such as microservices. For example, one application could be written in part serverless, part traditional code and still operate fully.
In somewhat confusing fashion, serverless architecture and third-party services can still be run on your existing physical, on-premise architecture. Read on to realise the hype surrounding the trendy approach to hosting infrastructure.
Back-end-as-a-service (BaaS) and function-as-a-service (FaaS)
There are two types of serverless infrastructure that are most commonly referred to - backend-as-a-service (BaaS) and frontend-as-a-service (FaaS). The former of these began life as a primarily mobile technology (Mobile Backend-as-a-Service (MBaaS), but it's now evolved to include desktop applications too.
BaaS offers a complete online service, managing every part of the code. Usually, the code will run constantly after triggered and so a subscription is paid to the provider. It runs on shared infrastructure with various applications using the same backend service.
Examples of vendors offering BaaS infrastructure are Parse, Kinvey, Buddy, Appcelerator and StackMob.
FaaS differs from BaaS because it only provides the tools to execute code designed by the developer.
FaaS works by triggering code on demand, such as when a certain event happens. This means you don't have to worry about managing the actions, because they all happen automatically and it can be very cheap to run, only paying what is consumed at that trigger, in fractions of a second, measuring memory and CPU usage.
Examples of FaaS infrastructure are AWS Lambda, Azure Functions, IBM OpenWhisk and Google Cloud Functions. They all provide support for the majority of programming languages and runtimes including Node.js, Python, .NET Core and Java.
Examples of serverless architecture implementations
Serverless infrastructure isn't suitable for every single app or service and this is especially the case for FaaS set-ups.
Because it's designed for very quick queries, it's best suited to real-time applications, such as data analysis, those with push notifications (such as gaming apps, transport update apps and social networking or messaging programs) and other apps that don't run constantly, but at event-driven intervals, such as database cleanup.
Because serverless infrastructure can be used alongside microservices, there are other app possibilities to make use of this function, including API-led SaaS apps, or those that rely on data from third party sources. Apps that rely on drawing integrating data from a number of different applications is also a good example, with booking apps that need to check availability of, say a room or car, being one possible implementation.
Benefits of serverless architecture
Aside from lower upfront costs and, usually, a consumption-based payment model, serverless infrastructure can be easier to maintain, with a provider managing maintenance ensuring they're up and running on-demand. This means you don't have to employ engineers to manage the servers and developers can focus on writing the code and innovation.
It also means businesses can be more responsive to changing market conditions, tweaking the code without having to consider where it will reside.
FaaS specifically offers further benefits. For example, users don't have to wait for HTTP requests or API calls because the code is only executed when the need arises. The provider manages everything else including scaling, making it a much easier way to manage resources.
Once the task has been carried out, the container is taken out of service by the provider, so you won't be paying for a dormant container.
Drawbacks of serverless architecture
Because the management of the infrastructure is reliant on the provider rather than the developer, there are some drawbacks. One of the biggest issues is that the developer or programmer will not have the same visibility of their apps as they would if they managed the infrastructure. So if there's an outage or a problem with the code, they may not be able to address it instantaneously.
Vendor lock-in is also a big challenge. It's tricky to switch between providers if everything is set up on one service and sometimes, the complexity of implementation may mean it's not financially viable to up sticks and switch.
Other limitations with serverless architecture are that because it utilised shared infrastructure there may well be some levels of latency during initial server requests that can make applications seem sluggish.
There are some applications that are not suited to serverless architecture, such as long-running processes, as FaaS has been designed to destroy containers after the code has been initiated.