2014 marked a personal "serverless" architecture revolution, the introductory paradigm: Docker. Containerization expanded the toolkit and, unlike functions as a service (faas) drawbacks were few and the advantages were many. Containers are an excellent abstraction and have worked consistently, for the most part, until 2019 when faas was catching some momentum in the architectural community. The transformation to publicly hosted "cloud" architecture became inevitable and in the pursuit of cost savings, and an effort to transition entirely into AWS began. It was decided Docker's shiny new little brother was going to be the solution. Excitedly, and with the prospect of being bleeding edge within our own community we dove into research, well a proof of concept.
As the organization's software architecture stewards we are tasked with the entry and exit timing of tools, technologies, frameworks, and methodologies to name a few. Hold on too long and you're navigating a monolith with licensing and legacy knowledge implications. Adopt too early and you might have to throw away a body of work. The latter is more personally painful as admitting mistakes as a so-called expert can humbling not to mention the career risk.
1) "Serverless" faas is just an abstraction of containerization
Under the hood, lambdas are functions or a collection of functions triggered by events (event-driven), that execute in an AWS managed container. So if you aren't managing your container environment evaluate your use cases carefully and see if the benefits supersede the challenges. An important note: using Lambda shifts some security burden to AWS. If you use ECS to deploy EC2 instances you will have more security responsibility.
2) Use existing application data (if you have any) to estimate before you start.
You may be starting from scratch in these cases look to examples or competitors' for data. Those migrating, understand your application's usage patterns and have visual data to understand and communicate current trends. For example, round trip execution times, concurrency needs, usage hours, geographical location access, idle hours, request volumes. More isn't always better but have a basis to build against, if you can't improve don't iterate.
3) Understand your application to understand your cost
Cost varies significantly per organization and application. However, if your developer cost is high the development costs might outweigh the cost savings derived by using on-demand faas. There is a steep learning curve for a small development team as resources have to attain the knowledge and skills to build, ship, and maintain infrastructure. Using frameworks such as AWS SAM or Serverless. If you have Cloudformation competencies this will help greatly.
4) Hoist, hoist, and hoist again
In most executions, any code hoisted outside of the lambda handler function is maintained in the global scope. This may persist for at most 5 minutes between calls (this is also difficult to verify as it is constantly changing). This pattern allows you to keep secrets and constants in container state between executions which will improve latency, however, there are limits.
5) Low Traffic creates latency
If you require high availability and low latency, moderate traffic will be required in order to keep lambdas "warm". You should base this on the task lambdas are performing. For example, if they interact with a relational database and require low latency responses, you should possibly reevaluate. If your task's result is persisted and/or does not require an immediate response then faas could the right solution. Otherwise, if your lambda experiences consistent traffic the application's use should maintain the latency itself.
6) Serverless Management frameworks are imperfect and always shifting
After working with AWS SAM they do a really great job to get applications architectures deployed. However, as our application grows the gaps in SAM are apparent. Serverless offerings are constantly changing and these teams have their own resource constraints that might not be moving as fast as you. The functionality may not exist yet or be in development.
7) External dependencies create internal challenges
The AWS environment is able to communicate to services across accounts with relative ease. Throw in some external relational databases and you're going to encounter challenges. Consider the position of your business unit in the organization's structure and its ability to make autonomous decisions. If you rely on other teams for services
there may be inertial or control issues.
In summary, lambda is an architecture for the right use cases. However, it is still growing and latency poses a challenge. Before implementing ensure you understand your application and use real data to evaluate, where you can. Lambda is growing and moving constantly and they are providing ways like provisioned concurrency to reduce pain points.
Retrospection is better served after an appropriate period of introspection. Organizational culture and team dynamics are often underappreciated when projects face adversity or fail to meet deliverables. We need to be honest with ourselves and our teams early in the process and correct course in the face of adversity.
Top comments (0)