Serverless is, for the most parts, the promised land of software engineering.
It reduces shipping time and significantly lowers costs for implementation and use of the system. It virtually eliminates all operational tasks and offers unbeatable availability, security, scalability, and scaleability.
Gartner predicts that more than 20% of global businesses will have adopted serverless computing technologies by 2020. This is a train you don’t want to miss. Serverless is about creating an IT system using cloud-provided service and, if needed, linking them together with Lambda functions. We get a solution that is easy to use and manage, and only pay for what we use.
Register now to be the first to hear about the jobs that interest you. Register now to receive AWS jobs directly to your inbox.
Sign me up
Serverless is not always a place of bliss. To avoid failure on your journey, you need to be familiar with the pain points of serverless. Many times, the best practices we use for years to build our systems end up being antipatterns.
This is not a problem as long as you are aware of the conceptual differences. Serverless is still subject to technical limitations, but they are being gradually removed as tech improves.
Let’s take a closer view at the challenges you might face while building a serverless platform; I have put this in context because the positive parts far outweigh the negative.
The antipattern of yesterday’s best practice was today’s best practice. For decades, these principles were the cornerstone of development.
Strong data consistency
Data normalization
Transactions
Fast immediate responses
High-performance infrastructure that never fails
These principles can be used today, but they are not ideal for serverless. SQL databases are not scalable because they lack strong data consistency, data normalization and transactions. You need a NoSQL SQL database if you want an extremely scalable solution. However, this is not only for the database level. These principles don’t apply to the entire infrastructure.
Data flows through the system often as responses to specific events in a serverless world. Data is consistent in this scenario (eventually!) In this situation, transactions are not the best. Databases must be designed for speed reading in order to achieve maximum performance. This is why data is often duplicated or denormalized.
Containers house functions, which are the heart and glue of the serverless platform. You can set the power of your hardware by setting a memory setting. It can store 128 MB up to 3 GB of memory. This is not a lot, but it’s enough to run one function. You can get a new container that has more capabilities if you need to run multiple functions at once.
New guidelinesHow do we create a new system by using the core principles that have allowed us to build reliable systems over decades? New practices are the key to building reliable, scalable systems.
StatelessA Lambda container can be reused but you cannot hold state at the container. It can be stopped at any moment and you never know which container will be processing the next request.
Favor asynchronous operations This gives you the ability to queue requests, retry and scale to optimize capacity. If the user is involved, inform him/her that the request has been received. Also, notify them of any results if needed.
Nanoservices and microservicesBreak down the system into smaller, autonomous pieces. It is easy to manage, monitor, scale, and scale small, independent microservices.
Design for failure and make functions impotent. For example, most services that trigger Lambda will retry the call in the event of failure. Although the cloud environment is reliable, you should anticipate failures in a distributed system like serverless. Functio
