Serverless Architectures – Scalability Without Infrastructure
Today brings a long overdue blog post from Cloudy Towers on a topic which can legitimately be described as “hot” in the world of technology (and AWS especially): serverless infrastructures.
Only a few years ago this term was coined to refer to the use of IaaS, i.e. “not owning any servers”. This is no longer the case….
Alright, what is it then?
Quite simply, it means that developers no longer need to worry about creating and scaling the servers required to execute their code. The cloud provider, which for the purpose of this blog is AWS, handles this for you. Leaving developers free to focus on writing the code for great microservices. Awesome, huh?
Teach me some Greek
Ok. Lambda is the eleventh letter of the Greek alphabet. Perhaps more interestingly, it’s also an AWS service that executes code in response to certain events happening. Definitely more interestingly, AWS Lambda can create, manage and destroy the compute instances needed to execute that code.
No need to monitor your EC2 instances. No need to worry about autoscaling. No need to set up instances to poll queues.
Think about that again: Near limitless scalability of the cloud, with no infrastructure work.
Don’t care, I’m not a developer
Ok, but perhaps you pay the bill? For the financially conscious (everyone?), the even better news is that there is no need to pay by the hour for your compute power anymore – use what you need for seconds. Lambda will run your code when needed only, i.e. when events that you specify are triggered, such as an inbound API request. This triggering can be done in milliseconds. Yes, milliseconds. Remind me, how long does it take you to order hardware from Dell?
Early adopters are seeing savings of an order of magnitude – as their EC2 costs are dramatically lowered.
Anyone using this?
Yep. Some of our clients are already embracing Lambda while building new applications (or re-architecting existing ones).
I asked one of our cloud architects, the ever awesome Yvonne Beumer, why Lambda had been chosen for a current project she’s working on. Her answer?
“To keep deployment and operations efforts to a minimum and focus resources on developing the actual application code, we decided to go with a serverless approach.”
Skip this next quote if you’re not a techie at heart. Be impressed if you are.
“The backend infrastructure we’ve created comprises stateless microservices. Every microservice is represented by a Lambda function written in node.js. Public-facing services that are called from the frontend use an Amazon API gateway to provide a secure and scalable HTTP interface for the Lambda functions. In addition to calling the Lambda functions in this simple request-response fashion via HTTP, other Lambda functions are triggered by events, such as by putting objects in S3 buckets. Also, the recently announced scheduled invocation of Lambda is used for polling services and daily maintenance tasks.
Every microservice has its own git repository. As soon as code is pushed to the repository, our jenkins server is triggered to package the function and deploy it to Lambda. Each Lambda function has its own IAM role with only the permissions need for the service to function. Some microservices shell out to external programs such as openssl and 7z. These are packaged as static binaries with the zip file of the Lambda function.”
If that blast of tech hasn’t convinced you, take a look at slide 42 onwards here where disruptive pioneers at Gousto show that they’ve also used Lambda to re-architect their stack as they look to aggressively scale their business.
Tell me more
Credit to AWS again they were early leaders in this space – releasing Lambda way back in 2014 amidst the gambling and chaos of Las Vegas at Re:Invent. Since then, those loveable folks in Seattle have been integrating furiously with other services, the most useful probably being API Gateway – which you can use for exposing Lambda functions as REST APIs. But an event could be anything. We’ve seen ‘changes to S3 buckets’ as noted above or ‘updates to database tables’ for instance. One can then trigger activity in a simple manner, perhaps using SES for email delivery, or more intriguing possibilities by integrating with Machine Learning or IoT.
AWS posted an interesting article on Serverless Testing which is worth a read for anyone wanting to get hands on with this.
Well, it will of course tie you in further to the services of AWS. Anyone who has read my posts before will know that I’m broadly an advocate of the “back your horse and get on with it” policy of IT selection, so I don’t personally see this as an issue. If you want to get the most from your cloud investment, go deep with your provider(s).
It’s also worth noting that microservices in general are still relatively new conceptually to many development teams in more traditional organisations. Those that have been struggling to work out how to implement Docker for instance, will probably struggle with this new pattern of serverless microservices where there aren’t that many public reference cases.
As a final note, you’re not going to be running your production SAP system on this – it’s suitable only for the “right” type of application architectures, i.e. microservice based.
Sounds great, I’m in
You really should be. This is an awesome way to create solutions swiftly without mucking about with AMIs, containers or infrastructure. We’re expecting to see significant adoption in our client base during 2016.
P.S. Did I mention it’s comedically cheap?