Serverless At AWS — An Opinion on the Recent Backlash
--
Amazon Prime Video released a blog post indicating their decision to change certain aspects of their architecture, moving away from serverless and achieving a cost reduction of 90% in the process.
Their article, dating March 22, has received a lot of attention of late, with some using it as the poster boy to drive the idea the “age” of serverless — or cloud for that matter — is over. Some said that it was a good exercise that ultimately failed to deliver on the promises it had advertised for years.
Unfortunately this seems another case where we are eager to denounce or adopt a certain choice, be it a technology or an architectural pattern, in absolute terms based on someone else’s depiction. This repeats the same mistake which is to ignore the context of those sharing their experiences.
It is not a surprise that most good developers or architects I know start from the opposite stance: context is king!
In this case, what I took from Amazon Prime’s article is a confirmation of principles I have been preaching for a while:
Continuous Improvement
Hardly ever your reality will stay the same, and even if it changes very little, your knowledge of the system will evolve as you are faced with real challenges and traffic.
This means that decisions that were correct or the best at a given time may no longer be. Learn and adapt!
Avoid the Noun-Based Service
A common fact I encounter is when talking about functionalities in a distributed system to fall for the noun-based criteria to determine the need for a separate service.
While applicable in many situations it is far from the only or best criteria. Think about responsibilities and the cohesion that set functionalities has with others and if you find they actually always evolve together you may be better served with them being modules of a single service.
Non-functional Requirements Also Matter
When we develop our systems we are driven by the functional requirements while forgetting the other important aspects, namely performance, cost and security. Having them captured and assessed in architecture decision records (ADR) can give you the perspective and even a head’s up of potential problems that can be addressed in the early days of the design or development.
Focus on Principles, Not Procedures
Also known to me as being pragmatic, not dogmatic!
As we are exposed to many aspects we may not have the time to fully understand the “whys” we are doing something. This is a capital sin that can lead to distortions when we follow blindly a procedure to use X — in this case serverless — without asking ourselves at least if it is applicable to what we are trying to achieve.
The Show Must Go On
Ultimately I believe that many things simply exist, and that good or bad depends on how we use them and if they were valid choices for our reality to begin with.
Keep learning what are the benefits of the tools, languages, patterns and procedures you use, constantly challenge your beliefs, and don’t be afraid of admitting something was a mistake.
Remember that a wise Man is one capable of changing opinion when presented with new information/evidence.
Until next time!
