It’s stupidity. It’s worse than stupidity: it’s a marketing hype campaign.‐ Richard Stallman commenting on cloud computing, Sep 2008 And, after 10 years, you are beginning to think twice when someone mentions the word: is it that thing in the sky, or that other thing that is ? expected to host 83% of the world’s enterprise workloads by 2020 Another revolution is underway, whether you like it or not. AWS is on the lead, with MS Azure and GCP following closely behind, all cherishing a common goal: Untethering software from infra. . Serverless FaaS. Death of DevOps. You name it. Regardless of the name (for the sake of convenience, we shall call the beast “serverless”), this new paradigm is already doing its part in reshaping the software landscape. We already see adopting serverless components into their production stacks, and frameworks like gaining funding . Nevertheless, we should keep in mind that serverless is not for everyone, everywhere, every time — at least not so far. giants like Coca-Cola Serverless in the millions Take a wild guess: where would you fit In? Server(less) = State(less) As a conventional programmer, the biggest “barrier” I see when it comes to serverless, is the “statelessness”. Whereas earlier I could be fairly certain that the complex calculation result that I stored in memory; or the fairly large metadata file I extracted into ; or the helper subprocess that I just spawned; would be still there once my program is back in control, serverless shatters pretty much all of those assumptions. Although implementations like lambda , the general contract is that your application should be able to abandon all hope and gracefully start from zero in case it was invoked with a clean slate. No longer are there in-memory states: if you wanna save, you save. You don't, you lose. /tmp tend to retain state for a while Thinking from another angle, this might also be considered one of the (unintended) great strengths of serverless; because transient state (whose mere existence is made possible by ) is the root of most — if not all — evil. Now you have, by design, less room for making mistakes — which could be a fair trade-off, especially for notorious programmers like myself, seeking (often premature) optimization via in-memory state management. “serverful” architecture Nevertheless, we should not forget the performance impairments caused by the diminishing of in-memory state management and caching capacity; your state manager (data store), which was formerly a few away, would now be several network hops away, leading to several milliseconds — perhaps even seconds — of latency, along with more room for failures as well. “circuit hops” Sub-second billing If you had been alive in the last decade, you would have seen it coming: everything gradually moving into the pay-as-you-go model. Now it has gone to such lengths that — and the quantization will continue. While this may not mean much advantage — and sometimes may even mean — for persistent loads, applications with high load variance could gain immense advantage from not having to provision and pay for their expected peak load all the time. Not to mention and systems with sparse load profiles which may enjoy savings at an order of magnitude, especially when they are small-scale and geographically localized. lambdas are charged at 0.1-second execution intervals disadvantage event-driven batch-processor Additionally, the new pay-per-resource-usage model (given that time — or execution time, to be specific — is also a highly-valued resource) encourages performance-oriented programming, which is a good sign indeed. FaaS providers usually use composite billing metrics, combining execution time with memory allocation etc., further strengthening the incentive for balanced optimization, ultimately yielding better resource utilization, less wastage and the resulting financial and environmental benefits. Invisible infra In the place of physical hardware, virtualized (later) or containerized (still later) OS environments, now you only get to see a single process: effectively a single function or unit of work. While this may sound great at first (no more infra/hardware/OS/support utility monitoring or maintenance — hoping the serverless provider would take care of them for us!), it also means a huge setback in terms of flexibility: even in the days of containers we at least had the flexibility to choose the base OS of our liking (despite still being bound to the underlying kernel), whereas all we now have is the choice of the programming language (and its version, sometimes). However, those who have experienced the headaches of devops would certainly agree that the latter is a very justifiable trade-off. Stronger isolation Since you no longer have access to the real world (you would generally be a short-lived process), there is less room for mistakes (inevitable, because there’s actually less that you can do!). Even if you are compromised, your short life and can prevent further contamination, unless the exploit is strong enough to . It follows that, unfortunately, if such a vulnerability is ever discovered, it could be exploited big-time because a lambda-based malware host would be more scalable than ever. containerized limited privileges affect the underlying orchestration framework Most providers deliberately restrict lambdas from attempting malicious activities, such as , which would be frowned upon by legitimate users but praised by the spam-haunted (imagine a monthly spike of millions of lambda runtimes — already offers — sending spam emails to a set of users; a dozen free AWS subscriptions would give an attacker a substantial edge!) sending spam email AWS one million free invocations and 3.2 million seconds of execution time Vendor locking: a side effect? This is an inherent concern with every cloud platform — or, if you think carefully — platform, utility or service. The moment you decide to leverage a “cool” or “advanced” feature of the platform, you are effectively coupled to it. This is true, more than ever, for serverless platforms: except for the language constructs, pretty much everything else is provider-specific, and attempting to write a “universal” function would end up in either an indecipherably complex pile of hacks and , or, most probably, nothing. any reinvented wheels In a sense, this is an essential and inevitable pay-off; if you have to be special, you have to be specific! Frameworks like are actively trying to resolve this, but as per the a versatile solution is still far-fetched. Serverless general opinion With great power comes great responsibility Given their simplicity, versatility and scalability, serverless applications can be a valuable asset for a company’s IT infra; however, if not designed, deployed, managed and monitored properly, things can get out of hand very easily, both in terms of architectural complexity and financial concerns. So, knowing how to tame the beast is way more important than simply learning what the beast can do. Best of luck with your ! serverless adventures Originally published at randomizd.blogspot.com on February 20, 2018.
