Please enable JavaScript.
Coggle requires JavaScript to display documents.
Serverless - Coggle Diagram
Serverless
Cold Starts
Google
Azure
AWS
Cloudflare/wrangler
Cloudflare Workers
Deploy serverless code instantly across the globe to give it exceptional performance, reliability, and scale.
Pros and Cons
Cons of Serverless Architecture
UNSUITABLE FOR LONG-TERM TASKS
Serverless is great for short-term or real-time processes like sending out emails. However, for longer duration tasks, where functions are running constantly, you may end up paying more for compute time than when paying for a reserved instance. A task such as uploading large video files would require additional functions to be called on.
COMPLEXITY
Units of integration with serverless are a lot smaller than with other architectures.
AWS functions are time-restricted, allowing you a maximum of five minutes
if you want to migrate your application over to serverless you need to tackle the complicated task of splitting your monolithic application to microservices.
You may need to deploy a separate piece of code for every function in your entire logical application.
Testing and debugging become more challenging
Serverless computing introduces new security concerns
Serverless architectures are not built for long-running processes
cold start
Vendor lock-in is a risk
you may need to re-engineer your application if you wish to do so
Pros of Serverless Architecture
Quick deployments and updates are possible
You are relieved from worrying about if the latest security has been applied. Because your servers are now in the hands of a third-party service provider, you no longer need to be concerned with keeping up with patches and bug fixes.
pay-as-you-go
With serverless, you only pay for what you use—there are no hardware costs and no costs when your services are not in use. Reduced cost is one of the main advantages of going serverless. If your services aren’t heavily used all of the time, then the ‘pay-as-you-go’ model gives you optimal resource utilization without paying for idle server time.
inherently scalable
its ability to automatically scale with traffic volumes. Scaling also depends on the location of users and their network connection. Serverless providers have points of presence around all users, which diminishes delays and allows apps to perform as they should, regardless of your geographic location.
Code can run closer to the end user, decreasing latency
MORE FOCUS ON USER EXPERIENCE
With server maintenance out of mind, companies can dedicate more time and effort to improving the customer-facing elements.
Who should use a serverless architecture?
Developers who want to decrease their go-to-market time and build lightweight,
flexible applications that can be expanded or updated quickly may benefit greatly from serverless computing.
Serverless architectures will reduce costs for applications that see inconsistent usage, with peak periods alternating with times of little to no traffic.
developers who want to push some or all of their application functions close to end users for reduced latency will require at least a partially serverless architecture, since doing so necessitates moving some processes out of the origin server.
When should developers avoid using a serverless architecture?
cost perspective and from a system architecture perspective, to use dedicated servers that are either self-managed or offered as a service
large applications with a fairly constant, predictable workload