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 also tends to offer far more flexibility than you’d get with traditional deployments. It allows you to scale up or down resources to react to business demand, with the provider doing the bulk of the work, although admittedly this usually comes at a cost. This is compared to deployments of the past where capacity for business processes was limited by the size of a physical server, requiring the purchase of new equipment, some of which would be rarely used, in order to temporarily serve a surge in resource demand.
It’s not just infrastructure that stands to benefit. Talent and manpower can be managed far more effectively on a serverless setup, especially as you no longer need on-site technicians to look after hardware. Although the roles are effectively made redundant, this gives the business the opportunity to redeploy those employees to support new projects, rather than maintaining systems.
There’s also the business capability advantage that serverless can provide, as it’s possible to operate different types of back-end code in tandem, something that would have otherwise required in-house expertise. The idea of flexibility also comes into play here, as, for example, an application could be built using both serverless code and traditional code.
However, things can get a little complicated, particularly as serverless architecture and third-party services can be run on your existing physical in-house architecture.
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 back end as a service (MBaaS), but it's now evolved to include desktop applications too.
Three compelling reasons to consolidate on hyperconverged infrastructure
Learn why organisations across industries are consolidating on HCI
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.
