Although serverless is still a new branch of engineering, it has brought a technological shift that provides high availability, auto-scaling, and greater security to users straight out of the box.
Serverless offers huge savings and faster market access to those who adopt it.
However, there is no free lunch. When you build a serverless team, there will always be challenges.
Many things can be different in serverless. Learning new technology and new tools takes time. Architecture is different as it aims to use as many cloud-based services as possible. Because the solution is made up of many small services, it takes more energy to monitor and analyze how they interact.
Developers are focused on the cloud. This means programmers need to be able use the cloud as their development environment. Serverless allows developers to be involved in the entire infrastructure building process. They don’t just code code.
These are the most common mistakes when trying to get serverless under control.
#1 Don’t underestimate the learning curve. Serverless is just like any other technology. It’s easy to deploy one function but it takes time to design a complex system. Your team will need to learn how to use many services, as well as their quirks, design patterns, and tools.
What does it cost to be an AWS serverless professional? Download our AWS Salary Survey to get insight from the global AWS community about salaries, benefits, industry trends, and more.
Get your copy
There are many books, blogs, and courses that can help you learn the basics. However, there are not as many resources to help you with more advanced topics. AWS Hero Yan Cui’s online course Production-Ready Serverless is one of the best. There is a lot of knowledge that remains scattered among blogs and other online resources.
#2 Don’t embrace new architecture patternsServerless has new design patterns you will need to learn. The event-driven approach must be fully accepted. If possible, you use a variety of services provided by the cloud provider to create a solution. The system responds to events that transfer data/requests between services.
The problem with new technologies, however, is that we want them to be used in the same way we used old ones. However, serverless can lead to common design mistakes.
A serverless monolith is possible
Serverless design principles recommend that the system be broken down into smaller parts. It is important to not limit your system to one function. This will make it difficult to manage and increase cold starts.
Not designing for idempotency
Distributed systems are susceptible to errors. You should be prepared for them. It’s not that serverless cannot be trusted. Serverless’ core components are capable of anticipating errors.
AWS is one example. Most services that trigger Lambda will retry the call if it fails. Replaying the same code can have serious consequences. Functions must be idempotent. If you receive the same order twice, you should not ship two products. You must check if the order was processed at the beginning and before you finish.
Consistency
Anyone who has ever worked with SQL databases will be able to tell you that strong consistency is something you have been taught from the beginning. Serverless data flows from service to service, function to function, and often ends up in a large NoSQL SQL database. This is because serverless prefers eventual consistency by design. Each processing takes time so you can’t have the same consistency as before, but transactions are available to back it up. The data is consistent at the end.
Learn more about architecture errors in serverless here.
#3 Bum
