Serverless - A game changer
2017, I was introduced to AWS Lambdas when it launched recently in UK and it was tough to comprehend it since I was already learning Dockers at that time. Containers and Dockers were game changers, no doubt, everyone was talking about it by 2017. In 2018, most of the companies and Individuals have experimented with them. I have seen few game changing technologies in past decade like J2EE, SOA, and LAMP, seen them getting commercialized, and seen them getting replaced. Though only difference between old and new architectural pattern is some times TIME when they came, which happened in case of SOA and REST as both emerged when they were needed. Now, best architects know the best of both and software architecture will keep on evolving based on learning from both. Dockers have won the battle (fought over last few years) because we all know how magnificent microservices are and dockers help achieve state of art in microservices.
The mistake many (and I) did was when they compare SOA and REST and same is probably repeating when I compare Dockers and Lambdas. My initial research says I am going to use both but in different situations. I also found Dockers have a learning curve and my preferred choice is Serverless. How I got involved in it when I had to choose for greenfield project. I was think of building backend for new social media site for a business (Intranet based - promote networking within colleagues). My Java background compels me to use stack: Java8 + Spring boot + AWS (and dockers). I started with domain driven design and also thinking of Authentication and Authorization also. At the same time I came across tweet from Simon Wardley "Whenever you build a system, 99.9% of it has already been written" and an amazing video from AWS re:Invent 2017 on Cognito. Two IT companies writing code for same functionality, even though for different clients, is code duplication. Authentication, Authorization, User Management, Registration, and so on - One should not write code for them (in most most cases). It is time to trade CAPEX for OPEX once for all. All those principles (event sourcing, CQRS, and so on) I have studying about microservices is available as Implemented Framework As A Service, watch this on Lambdas + DynamoDB. I finally chose AWS Cognito + Lambdas + DynamoDB.
My latest experience was how a music streaming platform can be build in hours on AWS using Lambdas.
- Media files are uploaded in the S3 bucket
- A lambda function is invoked to make entry of media file in DynamoDB
- Lambda function invokes Transcoder to convert media
- Transcoder convert media file in format which can be played on mobile
- Converted media file is uploaded to another S3 bucket from which it is delivered globally via CloudFront
Its all there Infrastructure, Servers, CD/CI, code - so next time when I write a code I doubt myself - Isn't it already there available as service. What ever I am writing is my business function, my company's unique value proposition. Days are not far when billion dollar finance engineering company can be build by writing just one function because rest all is already there as a service.
Another area of debate right now is Cloud computing vs Open Source. Spring boot is open source and Lambdas is cloud but deploying and running spring boot would require PaaS, that is, CAPEX model. It is challenging to imagine a future in which most of the software (architecture, development, operations, running, etc.) is controlled by few cloud computing companies (Google, Amazon, Microsoft, and so on).
Final words (stolen from Simon Wardley):
Containers — they are important but ultimately invisible subsystems and this is not where you should be focused.
DevOps — a lot of what people are trying to build in this space will itself become invisible and if you’re building internally then possibly legacy. It’s below the line of where you need to be
Serverless is the turning point or game changer at the moment and any team or organization is not using it then probably they are putting unnecessary extra efforts.