> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/general-paradigms/architecture/serverless.md). # Serverless ## What? * an approach to software design that allows developers to build and run services without having to manage the underlying infrastructure. * Developers can write and deploy code, while a cloud provider provisions servers to run their applications, databases, and storage systems at any scale. * A service that is only run when it is called * Gained popularity from AWS lambdas * Need app that can start up quickly to process a request ## How ## For * No server management. * Serverless computing runs on servers, but those servers are managed by cloud service providers * Save cost * With traditional server architecture, you would have to predict and purchase server capacity, usually more than you need, to ensure your application does not face any performance bottlenecks or downtime * With serverless, cloud service providers only charge you for what you use since your code will only run once triggered by an event when a backend service is needed * serverless saves a fortune in human resource costs as well. As maintance of servers are already handled in the price * Scalability. * Applications built on serverless architecture can be scaled endlessly and automatically. * Quicker time to market * Development environments are easier to set up and not having to manage servers leads to accelerated delivery and rapid deployment. * Reduced latency. * Thanks to Content Delivery Networks (CDN) and Edge Networks, serverless functions can be run on servers that are closer to end users all over the globe ## Against * Vendor lock-in * the easiest way to go will be to use a single cloud services provider * Each provider will have their own way of doing things, so big changes if want to migrate * If there is an infrastructure problem of any kind, you have to wait for them to fix it. * Or you will need to have a back up server that turns on to serve traffic (ie kubernetes cluster) * Security * Cloud providers will often run code from several customers on the same server at any given time * via Multitenancy. customers are tenants that only have access to their share of the server * data could be exposed due to misconfiguration of that server. * Performance impact * When a function is called for the first time, it requires a “cold start” which is to say that a container needs to spin up before the function can be run. * container will continue to run for a period of time after the API call is complete in case it is needed again soon after at which point we get a “warm start” without the added latency. * This can reduce the number of technologies that you can use in serverless due to SLA requirements or make this a non option due to a non negotiable requirement for specific tech * Debugging and testing. * a serverless environment can be difficult to replicate in order to perform integration tests. ### Links * ## Links * * * * * *