Server vs Serverless in Cloud Computing

If you’ve been hanging out with software developers in the last few years (or perhaps just strayed into one of the nerdier parts of town) you might have heard them talking animatedly about “serverless”. It might be obvious that it’s something that doesn’t involve servers, but serverless what exactly? Serverless restaurants? Serverless banks? You might be forgiven for thinking the latter but obviously they’re talking about serverless application development, and what some people might call a revolution in software production.

Redhat describe serverless computing as “a cloud-native development model that allows developers to build and run applications without having to manage servers”. Straight away you’ll notice the inherent contradiction of the term: serverless doesn’t mean that there are no servers. Instead, it’s just that they’re no longer the concern of the developers and clients, and everything is taken care of by the cloud provider instead.

A Very, Very Brief Summary of Server-based Development

Traditional software production often involves an actual room full of computers and cables where your software files live and perhaps where your website is hosted. Users and developers are connected to these servers either by cables or by a wireless network, happy in the knowledge that what they’re working on lives next door within the safe confines of the local network.

The majority of cloud computing services seek to mimic this set-up by supplying storage and servers that work in a similar way for the end user, but the data itself actually lives somewhere else on the internet — and maybe even in many different places.

Operating in the cloud this way presents a range of new possibilities and challenges, but the concepts of drives and files and repositories are still pretty much the same. If you rent a virtual server, that’s what you get. You can potentially make it bigger or smaller, which requires you to stop the server, change it and then start it again, but a server is what you’ve got until you kill it.

Serverless, as the malapropism goes, is a different barrel of monkeys altogether.

Advantages of Serverless

A statement by the Cloud Native Computing Foundation’s Serverless Working Group sums up the situation perfectly:

“Serverless computing does not mean that we no longer use servers to host and run code; nor does it mean that operations engineers are no longer required. Rather, it refers to the idea that consumers of serverless computing no longer need to spend time and resources on server provisioning, maintenance, updates, scaling, and capacity planning. Instead, all of these tasks and capabilities are handled by a serverless platform and are completely abstracted away from the developers and IT/operations teams. As a result, developers focus on writing their applications’ business logic.”

As a developer, a serverless approach will allow you to minimize undifferentiated work around managing servers, infrastructure, and the parts of the application that add less value to your customers. Serverless can make it easier to deliver new features in applications, launch experiments, and improve your team delivery velocity, while also providing a pay-for-value cost model.

With regards to the business goals, our own article on the “5 Benefits of Building Serverless Applications”, summarizes the key benefits as following:

• Move from idea to market, faster
• Lower your costs
• Build better applications, easier
• Better scalability
• High availability

These all derive from the central principles of the streamlining and simplification of processes. As Jason Katzer explains in Learning Serverless (O’Reilly, 2020), “You don’t need a specific reason to use serverless, but here are some examples of the characteristics of the compute work you want to perform that will have the least friction and most benefit when utilizing serverless:

1. Tasks that can be broken up into small independent units of work
2. Tasks that either have infrequent or unpredictable usage patterns
3. Background work, or system to system communication that will not be impacted by cold starts”

Disadvantages of Serverless

The above reference to “cold starts” should serve as a hint to the fact that there are situations where the application of the serverless model might not be entirely suitable. Katzer further explains that “Serverless will not serve you best when:

1. Tasks are computationally intensive
2. Tasks have a long runtime that can’t be broken up into smaller workloads
3. You need additional functionality not currently supported by the cloud providers”

Technical Limits

Whilst it’s beyond the scope of this article to deal with all the technical limits in detail, the following examples can serve to give an impression of the issues and their potential resolutions.

1. Cold starts. A direct consequence of the fact that you only pay for what you use, and that service provision expands and contracts with demand, serverless applications can experience something like trying to start a car on a frosty morning. is that it might take time for a function to spin up the necessary resources on its first run. It’s not exactly that it takes a long time (more like extra milliseconds), but some operations might suffer if they need a super-quick response while others won’t care at all.
2. Compute Time limits. Serverless platforms typically apply a limit to how long compute operations can last but this is also changing with time. The best way to solve any issues here is to break things down into smaller chunks and to design with serverless in mind.
3. Network Issues. In some specific situations, you’ll have to make decisions around the operation of a Virtual Private Cloud, and it might be that serverless is not a good fit in these cases. It’s not common but it’s worth being aware of.
4. Debugging. Some developers are quite attached to the sophisticated forms of debugging that come with more traditional platforms and might be frustrated with error reproduction in a serverless environment. However, tools are fast evolving to make up for this shortfall and the greater emphasis on good architecture should also mean that it’s less of an issue in general.

Organizational Concerns

Not all the potential problems are strictly technical, and thus their resolution can be through changes in organization and approach as much as to the technology:

1. Vendor lock-in. If you embark on designing your production system around Amazon Web Services or Microsoft Azure, you might be concerned that you’re stuck with them. In the short term you might be right, but no more than with any other proprietary system that you might you use. In some ways, the increased importance of good architecture could also mean that you’re actually less restricted over the long term because you understand your applications better and that conceptual thinking can be transferred elsewhere — even to future service offerings that don’t exist yet!
2. Potential to be more expensive. Yes, it’s true that if you get things wrong you could end up paying more than with a server-based set-up and that’s going to really sting when one of the commonest for the transition is to cut down on costs. A badly written function could theoretically run up a big “go” for your pay-as-you-go account before you eventually find out. Fortunately, tools exist to make sure that this doesn’t happen, and AWS provide a number of ways to help keep within budget and prevent costly mistakes.
3. Availability of developers. One danger of the success of serverless is that demand might sometimes outstrip supply when it comes to hiring developers with the right skillset for the new way of working. We must agree with that one to a certain extent because we’ve hired a lot of them! Nevertheless, it’s certain that the increased popularity will also lead to a steady growth in the number of courses and graduates available and getting in early will put you in a better position to recruit effectively in the future.

Conclusions

Having had a look through some of the advantages and disadvantages of serverless computing, you should now have a better idea of what it can do for your business and when it might not be a good fit.

The next essential step in any transition is to do some further research and develop a good understanding of your own organizational and technical requirements. Having a clear architecture and a willingness to rethink your approach can solve many problems before they even happen.

By now the internet has a wealth of information and potential sources of help dedicated to serverless, from Reddit groups and YouTube tutorials to more proprietary resources like the serverless section at Amazon Web Services. It should also go without saying that one of our key areas of expertise at PCG is in assisting companies with their transition to serverless and ensuring that they get the best solution possible.

Do you want to find out what going serverless can mean for you?

Have your application running in no time, lowering your costs, and not having to worry about scalability or availability of your application. Contact us and find out!