Serverless. Let’s make it clear!
Failed VM? Call 1–800-SHIT-HAPPENS
I like to see how cloud technology evolves into mature, robust and solid state. When i was hired by Mirantis i commit myself to OpenStack, at that point we had “cloud computing”. That sounds so cool, less hardware to maintain, but more devops. So, in cloud we had servers (compute instances), but still servers, nothing really changed, except we gain more pain somewhere a bit lower our hips because absence of control capabilities, if someone attempts to deploy a server with an error he can just give another shot or make a phone call: 1–800-SHIT-HAPPENS.
App developers were still far away from cloud computing because market was full of simpler hosting solutions like DigitalOcean and Heroku. Reason stays pretty clear — app hostings are simpler, predictable, cheap, isn’t this what developers look for? So, cloud computing somehow failed on attempt to find it’s own target audience.
Containers. Simple. Reliable. Still not what we’ve been looking for!
Market starved. App developers were begging for something simpler, faster, granular, technology that provides better resource isolation (less affected by “noisy neighbors” problem), better UX in terms of reproducible environment as well as better infra packaging and distribution. What about containers, are they cure-all? Despite its downsides, they are better than VMs, more lightweight, fast-provisioned, predictable, reproducible, etc. Containers helped developers to invent almost generic rolling upgrades process (just remind blue/green canary) — do not replace binary, replace whole instance, because it’s faster and cheaper. Also containers were fitting at its best into microservices by letting them be more stable and horizontally-scalable.
Container is a game-changer? Unfortunately, no. Here’s why, someone still needs to monitor them, do failover, etc. Whole application remain almost the same — bunch environment, networking configuration, etc. So, it’s still not easy-peasy thing. Okay, if containers are still not good enough, what’s next?
Serverless. Let’s make it clear!
Next buzzword in our list — serverless. So, what’s that? While writing this article i went through a lot description of what is it, got only something really academical and less alive. Here’s how i see serverless — it’s a concept of an ad-hoc scalable distributed event-driven computing.
Why ad-hoc and scalable? Ad-hoc because processing units will live as long as they need to process data, scalable because it’s possible to define how many distributed processing units to be involved in computing process based on certain ranging rule (think of distributed map-reduce).
How serverless is different from microservices? Let’s start from the very beginning — both microservice and serverless app have an entry point, i.e. API gateway, facade, etc. Despite that, microservice should be hosted somewhere, serverless is different it does not require environment for hosting. So, if they are so similar would that mean that microservice can be turned into serverless app? Indeed, consider microservice as set of functions with task dispatcher. So, each task handled by dedicated function, but in case of serverless each function is an event-driven distributed short-lived task processing unit. That means microservice that turned into serverless app becomes nothing but “thin” task dispatcher.
Events. Notifications. Polling. Serverless — cure-all?
Most of the time we develop application that somehow depend on 3rd-party services, no matter what they are, sometimes we want our app to perform any reaction to any kinds of events. Biggest problem here is event polling. As you might have seen there are a lot example of apps that are awaiting for storage events (cloud, local — no matter), entity events, etc. All those apps have similar architecture — poll then react. Polling itself is very fragile thing, because an API you’re trying to hit might be supported by rate limiting. So it becomes necessary to identify how many requests you can send per second within one day to keep your app working fine without hitting HTTP 429 Rate limit (in case of HTTP API) or something similar.
There suppose to be good alternative to event polling. Okay, this might be very obvious — if you not poll event then you need to be called on event. This means 3rd-party services should emit event notifications to anyone who listens/await for them, for instance, in GCP, AWS you have events emitted when their resources are modified. Clouds are pretty good examples of how should other services treat their internal events and propagate them to the ones who work with 3rd-party service resources.
Event notifications are good, they let people understand what really goes on, what’s been changed/modified, etc. But are all kinds of events are good, or they should be somehow unified to be useful in terms of serverless? My answer is straight here — YES! Serverless is an evolution of event-driven world and microservices. We don’t want to build event-polling microservices, we want events trig functions!
Key things to us, as serverless app developers, is to make 3rd-party service call our functions on events. So, the strict requirement to event emitter— they should be capable to call functions, basically — do HTTP Post to a webhook URL. We’d get valuable benefit: no need to run code, serverless function would be called only when it is required (function becomes event handler).
Serverless becomes something that hard to call a buzzword, or something that can be ignored. Serverless development is no longer future rathern than present. Road from hardware to VMs to containers to serverless was long and hard, but we’re still not at its end. VMs almost dead to app developers and event being useful, containers are trending and would still be popular among developers for a long time, serverless is still evolves and might appear a bit raw/immature but it brought another level of abstraction above infrastructure, it’s a huge step forward in our event-driven world.