The Buddhist Who Went Serverless
One of Buddhism’s key principles is letting go of attachments. There’s a long chain of logical reasoning behind it, but essentially it means life would be simpler and happier if we become independent of the stuff we’re used to think of as necessary. That includes physical property — such as a car or a house — and extends to abstract concepts like fortune, nationality, etc.
However, in software development, dependencies are part of our everyday life. Literally every piece of code relies on another compiler, framework or library; and while using these is allegedly a professional matter, the experience is often coupled with feelings (hate, love and pride are some common examples).
The Stuff We Can Touch
Up until 20 years ago, servers were purely physical machines (with lights, fans, dust and the whole shebang). Although outdated, this approach ensured maximal security and control.
As technology progressed, cloud computing services were introduced. Nowadays maintenance of physical servers (and their rooms) sounds like ancient history. The flexibility that cloud services offer made them the mainstream technology in modern research and development.
The transition from owning a physical object into subscription-based service isn’t unique to the development industry: even the idea of owning a DVD and a bunch of disks makes millennials shift in their seats, as YouTube, Netflix and other streaming services have become our main sources of video content.
Generation X and their parents needed to own property. In the post-WW2 reality they had to be certain some things will remain theirs, no matter what catastrophes the future holds. Unfortunately, the remaining of this approach still dictates the way we invest money and manage our code.
Letting Go
Alongside “classic” cloud server services (i.e. Platform as a Service, PaaS), which allow running containers of code, there’s another model that supports scalable applications out of the box: serverless computing (i.e. Functions as a Service, FaaS).
In a nutshell, according to this pattern, the server’s logic is split to independent, stateless functions that are hosted by a third-party service. The provider guarantees the availability of the functions’ endpoints and allocates resources dynamically for each run. Hence, scale-related issues and virtual machines’ configurations become transparent to developers.
In other words, after we stopped tracking where our code runs, we now also give up knowing how it runs. Just like a Buddhist monk who gave up his property, we’re now free of this burden and can focus on the essence: our business logic.
In both worlds letting go requires a certain degree of confidence, and indeed there are some drawbacks to using serverless architecture in your application. Nevertheless, it sounds like a choice we need to carefully study and consider. Even if we don’t migrate our whole backend services, it’s still a strong tool to have in our system design arsenal.
