When you ask people in industry what serverless means, you’ll probably receive one of these definitions as an answer:
I’ve already defined what DevOps engineering is but serverless seems to need clarification. I feel there is a lot of confusion around serverless and the confusion is led by cloud providers making serverless sound like something magical, but the way they use the word is simply a buzzword that means nothing
Here is a more meaningful definition of serverless: the word “serverless” is used to describe the idea that the servers processing the application logic are not always present
The first definition of serverless I described above is a more accurate definition of serverless and there are multiple strategies of implementing a dynamically provisioned code execution environment. These strategies are internal serverless and external serverless. Both of these strategies ship with positive attributes
Look at this from the point of view of a non-cloud provider (i.e.: you are not Google or Amazon)
Internal serverless may be appealing to you if you already have your own servers (on-premises, at a colocation data centre, under the desk near the secretary etc) and you would like to use the resources more effectively
External serverless is serverless in the cloud. If the company decides to go with external serverless, this decision may result in a paradigm shift for DevOps engineering
External serverless does not deprecate DevOps engineering in any way. It simply shifts where some of the DevOps engineering (including hiring) occurs. Cloud providers have a big requirement for hiring DevOps engineers and cultivating the DevOps engineering principals
This also does not mean that DevOps engineering in its entirety is subjected to this paradigm shift. Large enterprises and well as SME’s can still very much have a requirement for DevOps engineering, particularly considering everything DevOps engineering is involved in and what DevOps engineering brings to the company
There is still plenty work to do in terms of process efficiency, building productivity tooling, automating routine tasks, designing service architecture, adopting multi or hybrid-cloud–I could keep going but I think you get the point
A good way to understand serverless is to think in terms of abstraction. Serverless is just another layer in the abstraction model. Both of the following abstraction models involve servers and people/software managing them and like I explained above, it just depends where the people and software that manage the servers are placed
Everyone should be aware of the appeal of operating system virtualization and the reasons why you’d want to do this but just keep in this concept in mind and and place app virtualization on top of this
Physical hardware —> OS virtualization —> App virtualization
You’d abstract physical hardware management to Infrastructure-as-a-Service (IaaS) offered by a cloud provider. IaaS will typically still require operating system management so the next layer up is serverless
Physical hardware and OS management —> IaaS OS management —-> Serverless
The appeal with external serverless, from the point of view of a company that wants to shift this responsibility away, is very much “no operations” and this is a really good idea all round
How many engineers work on serverless at AWS or how many servers power serverless in GCP?
How many engineers built the software that manages the serverless servers in AWS and GCP?
These are just two of the questions you should ask people that feel serverless deprecates DevOps engineering or if they feel code genuinely runs on water vapour. You aren’t looking for a exact numerical answer but rather observe the thought process in the person's answer
Some people in industry really believe that there are no servers involved with serverless or they understand that servers do exist in serverless but somehow they are managed themselves
These beliefs are completely false. Servers do power serverless and applying the DevOps engineering principals resulted in tooling and automation that manages the serverless servers (you are playing a semantic game if you feel another type of software developer built the DevOps engineering tooling/automation, we are all software developers)
The appeal of external serverless is really good but there are some considerations that you should be aware of
It stands to reason that serverless is not designed for long running processing. Technically it can, but just be careful of a surprise bill. I think it’s billed in milliseconds for a reason
I have been running a WebSocket server (persistent, long running HTTP connections that send the WS upgrade headers) in Google Cloud Run and it has worked out but I do set a maximum execution time though
Reserving a minimum amount of instances will—at least in my case this has been true, dramatically increase the bill so scaling to zero is the only real option
When the app has scaled to zero and an incoming request or event has been triggered, the execution environment will need to be initially prepared and this can slow down the processing
If you don’t cater for this in app logic (it’s as easy as simply trying again), you may have some failed requests/events
There are some things you can do that can improve cold starts:
If your app uses a distributed application architecture, the cost involved with reserving a minimum amount of instances will increase even more (it makes no sense to still cold start of some of the serverless instances if they have a dependency relationship)
If anyone ever says that it’s possible to accurately predict what the bill will be when using serverless— or the cloud for that matter, is lying
You are billed per millisecond execution time over how much memory is used during this time and network ingress/egress is billed per byte that varies to specific regions in the world. The network billing alone will make the predictions near impossible because how do you know how many users will sign up and where will they mostly use the app from?