To be honest, I’ve had a rough time understanding how FaaS fit into my vision of a microservice architecture. It made sense that they were microservices themselves, especially when they are event driven: put something in a bucket, then do something, maybe do something else and so on. But what I didn’t understand was why build a serverless function if you could build an API.
In the end I realize that it was how I had learned to develop microservices that was the crux of my issue. I have always been a very detail oriented person. I like to write the code, package it, provision my server, deploy my code to the server, add the routing, etc. All of this obviously takes time, overhead, and an understanding of the underlying systems.
The first thing to know about serverless is that it is not just functions. Sam Newman explains that serverless is the abstraction we get for products we would normally provision servers for. For example (in AWS) there is the SQS (simple queue service) and RDS (relational database service), both of which provide a service instead of the user needing to provision the system.
Simon Wardley further explains that by decreasing the overhead of provisioning systems and instead using existing services can help a business grow and save money. What’s important to realize here is the need to start to think about architecting your systems around hosted technologies instead of building them yourselves. Unless the need for you system is to be highly customized or doesn’t exist there is no reason to build it from scratch because it will only slow you down.
Taking this notion of not needing to provision systems to the function level one can realize the benefits of serverless functions as a service or FaaS. The role of development is to fulfill the needs of the business. Sometimes it is better for a business to release something fast without the need to worry about some of the underlying architecture. This way it can be iterated upon and improved. By doing this on a serverless function there is a significant reduction in overhead by not needing to maintain servers and creating an “on demand” system that may not cost very much money to run or maintain. Kelsey Hightower’s tweet sums this thought up perfectly:
I now understand what all the Serverless fuss is about. When you have a great idea the last thing you want to do is setup infrastructure.— Kelsey Hightower (@kelseyhightower) April 23, 2017
So for a business it can make a lot of sense to run things in a serverless way. What’s important though is to distinguish when serverless works and doesn’t work in your system. This is something time will tell as you watch your system grow and evolve. As stated before you may find that you need to do something custom or that the demands of your system are too expensive to use serverless in which case you may need to provision your own systems.
FaaS and containers are different layers of the stack. What you're really asking is whether it makes sense to move from a public FaaS (and associated services) to an on premise FaaS. If you're the scale of Netflix then … maybe, at a push but doubtful. If you're not then no.— Simon Wardley (@swardley) August 20, 2018
If structured properly this should not be a major rewrite and can evolve as your company evolves. People often forget that an original proof of concept should eventually be rewritten. This is again where it’s important to have a map to discover what direction an aspect of your system should go. You should continue to maintain an abstraction layer between the servers you run on and the code, this is where a distributed architecture using Kubernetes can be helpful.
My confusion arose from this feeling of needing to either run on Kubernetes or a FaaS platform but in reality a hybrid approach I think is acceptable. As time goes on you’ll find a sweet spot to help run and maintain code as it matures and develop a robust system.
A special thank you to Simon Wardley for responding to my questions. Been a big admirer of his work and try to understand it from a developers point of view. His clarification was what helped me finish this piece, and I hope I got everything right.