As a relatively new approach, there are multiple definitions of the term serverless technology. Blogs and forums are full of discussions about if serverless technology takes care of security, if it’s easy to scale or not, and if it’s the new ‘ultimate answer’ to not having to manage server infrastructure.
Traditionally, functions are bundled into one application and run as a whole on server infrastructure required to be managed by you. Servers need to run all the time just to listen to events, incurring charges for the full run time. To achieve scale, infrastructure needs to be provisioned.
So what is serverless technology? Serverless technology is a different way of thinking about how to write code. It is a design pattern to run your applications as independent functions, that respond to events, charged only when they run, and can scale automatically. This is because each function has to be developed to run stateless.
Serverless does not mean removing servers. It means removing the need for you to manage the servers because it is done by 3rd parties like AWS.
Serverless is not NoOps. You still need to manage your code, your deployments without impacting users, disasters, testing and monitoring. You will always need to act when something goes wrong. What you do remove is the need to actually manage the infrastructure.
Serverless does not take care of your security. The third party provider takes care of the underlying server security, but you are responsible for application security. Don’t open things up to the entire world if it is not required. If it is, make sure you build good authorising code. Pass tokens for authorisation and limit your execution points where possible.
Serverless is simplicity but not simpler. You really need to think about the one thing your function is doing. That is why coding to be stateless can be really hard to get your head around. Having already built a few serverless applications internally and with our customers, we found that the time it has taken to build the applications was just as long as building in a more traditional way. This was mostly because we had to really think about the functions and the purpose of the functions.
Serverless does not mean stateless. State can lie outside the function. So we have to think more like Integration Developers. When working in serverless design patterns, information is only ever passed into the function or is ‘pulled’ from a datasource within the function.
It is important to remember that there is not ‘one’ way of doing serverless. Ultimately, you can go completely serverless, be partly serverless, or simply use it as it makes sense to you. The only thing to consider when going serverless is to follow the design patterns.
If you are interested in discussing ways of building serverless technology, please contact us. base2Services supports our clients to transition to serverless technology or introduce serverless technology into parts of existing applications.