Serverless means extendibility
I wrote an article about a GitHub Action I recently created to deploy my code to kubernetes. Very nice. Writing the action and the post, I realized what serverless is all about. I wrote it in the incipit of the article, but I think this topic deserves its dedicated post. Serverless is not yet for web applications. I know some of you will probably disagree but this is my blog, and that’s why I have one, to write whatever I like!
I used Lambda and API Gateway to distribute two pdf I wrote about “how to scale Docker”, it looks to me way more complicated than a go daemon. So I wrote them because I got the free tier and because I like to try new things. There are excellent applications written in that way for example acloud.guru but I am probably not ready for that! My bad
Anyway, I know what I am ready for: We should use serverless to offer extendibility for our as a service platform.
Good for us distributed system and hispters applications are all based on events, Kafka and so on. Plus now we have runC, buildkit and a lot of the building blocks useful to implement a solid serverless implementation.
It is not easy, at scale this is a complicated problem but we are in a better situation now, and it is a massive improvement from a product perspective:
- Using containers, we can offer total isolation, and we can take a very carefully and self defensive approach.
- An API already provides extendibility but, you still need to have your server and to run your application by yourself to enjoy them. With a serverless approach, it will be much easy for the customer to implement their workflow.
- You can ask your customer to share their implementation creating a vibrant and virtuous ecosystem.
You can use a subset of the event that you write in Kafka as a trigger for the function, VaultDB to store secrets that will be injected inside the service and so on.
There is a lot more, but I am excited! Is somebody doing something like that? If so, let me know @gianarb, I would like to chat!