Server-less is *kinda* cool

It's the same story all over again. When cloud was introduced, everybody was like "wheee, there is no hardware limitation". When containers were introduced, everybody was like "wheee, there is no operating system limitation". Now it repeats with server-less application development. Wheee!

I will try to make it simple. There is and always will be hardware running in background. Reason you go to public cloud provider is, that you don't have to care about hardware resources. You work with your virtual machines, but in reality, all computation is done, at the end of the day, on physical processor. Advantage is, that you can act, like there is no hardware. When you design your infrastructure, application, platform - you are allowed to do dirty tricks, which would be not possible with physical hardware - not at this price and speed of provisioning. Which is by the way a reason, why I think that building cloud environment in-house is counterproductive.

With containers, you are giving up on layer of operating system. You are deploying your application with complete server environment, packed in one nice container. That gives you outstanding flexibility. At the end, you don't have to care about hardware, you also can forget about OS, you can again act, like it is non existent. One simple pipeline can build your image and deploy container via Rancher or Kubernetes to one of many container hosts. It doesn't matter, if the host is physical machine in your data center, or in Amazon or Azure or Google Cloud.

However with server less application, there is one huge difference.

Examples I described above are requiring deep knowledge of hardware, virtualization, operating systems, servers and all around also knowledge of application build and deployment. Of course it's cool, that you can practice DevOps on full scale, anything-as-a-code, but you still need people with experience. You can leverage experience of operations towards automation. That already sounds like a dream to many companies. But what if you just don't have that experience? Does it mean, you have to first learn about hardware / OS / servers, so you can later learn, how to act you don't have them?

Services like Heroku or Empire are doing something like this. You don't have to care about anything, you will just point your Git repository to right API point and voila! After few seconds, you have your application up and running, scalable in container, redundant, you name it. Of course, you lose control and configuration - but that is always the case. It is simply great.

Nobody is claiming, that virtual machines are better than physical ones, that containers are better than virtual machines... there are always good reasons to use one or another. Building low latency trading system will always need to sit close to physical processor, while from global perspective this is rare requirement. Purely from conceptual perspective, server less is far most advanced abstraction we will probably ever see. Instead of writing full pledged applications, let's cut them into pieces, into separated functions and let's call those functions, only when needed. You got zero maintenance cost, you got extreme scalability, you need zero knowledge of operations.

I started with AWS Lambda already some time ago, when I needed a notification sender to our Slack channel. There was no integration with Slack back then, so I simply reused some function I found on internet. Then I forgot about it. Later I noticed, that AWS started a competition for those, which like to create server less bots. Because I love bots (see my last article, where I touched a topic of HuBot), I decided to pay more attention. And I discover a lot.

Abstraction concept now allows you, that only thing you provide is a source code of your function, application. That is all. When this application is called, something will take the source, something will deliver it, something do some computation and something will give you a result back. It's incredible, because you see literary nothing, from user perspective. Input, output, end of the story. It brings memories of BASIC on ZX Spectrum. (Well, Lambda itself is associated with Half-Life, which brings side question: where is third game, hm?)

So what I did was a only a sample of functionality, to learn, how this is implemented on AWS. Function itself returns any value, which is provided by user. No need for rocket science. I decided to use NodeJS, but Lambda already supports quite nice selection of languages. To create external call, I had to use AWS API Gateway, which surprised me little bit (I haven't used that until now), but after some hour spent on reading documentation, it made perfect sense. And lastly, I wanted to show this sample to my colleagues. Therefore I decided to integrate with Slack. I created new slash command and linked it with URL provided from API. I discovered some problems with JSON formatting, but there was actually simple solution (mapping) I find online. Total effort was around two days of focus.

Now any member of our Slack team can type in /echo blabla to see blabla in a chat. Of course it's not really productive function, but as a proof of concept it was worth it.

That brings me to the last point. Server less concept is the future, because now you can start coding your application without need to learn nor understand all that complicated stories about hardware and servers and containers. It opens a gate to new age of developers, to server less bots, integrated in your What's Apps and other instant messengers. With introduction of more descriptive languages, we will see boom of home made easy to be personalized bots, we were never prepared for. And really cheap on top of that, because you only pay for real processing time.

Looking forward!