I still remember the night in 1998. A colleague of mine and I sat with a bunch floppies to install Novell Netware Server on hardware that physically measured about the same as a home refrigerator. By morning on the next day we had the server ready, all this to give us the ability to share files among a bunch of PCs and some user management. The word “server” would mean a real big thing in those days. It would only be a slight exaggeration to call it “stone age” in digital terms. Lot of things have changed since those stone age days, and today we are talking about Serverless architecture.
Serverless architecture really seems promising to me. It is a new paradigm, and once the developer toolset and frameworks mature around it, we would be witnessing an exciting new world! Obviously serverless architecture does not literally mean that there wouldn’t be any server, from that perspective the name is misleading. What it means in a nutshell is that the engineering team does not need to bother about provisioning hardware and software. That will be taken care by hosting platform. Not only that, the hosting platform will also take care of adding new hardware when needed and trimming it down when it is not needed depending upon load. Businesses need not worry about over-provisioning and ending up paying extra subscription cost, and also need not worry about under-provisioning and facing a performance issue. The entire scalability question starting from running on ‘No server’ to ‘N servers’ will depend upon the load at a point of time.
Serverless took first got prominence through AWS, once more proving themselves to be the pioneer in the area of cloud innovation, by introducing AWS Lambda in their offerings back in end of 2014. And recently Microsoft also published similar service in their Azure offering, called Azure Functions. Google’s GCP is also following the lead and has offering with name Cloud Function.
Serverless architecture is Microservices and Scalability on steroids!
Here are couple of situations that I think will benefit from serverless facilities:
- Startups can benefit the most with serverless architecture. At the initial release stage, there is usually low demand on scale, going serverless can help stretch the dollars most optimally for just the right amount of infrastructure as required. When usage grows, the solution would react and scale to increased load automatically. All of this without doing any code change, if architected right in the beginning.
- Another scenario could be that of IoT web service endpoints to which devices connect to push or pull the data. Number of connected devices would drive the infrastructure cost dynamically.
- Content Management sites, including blogs. That are not receiving enough number of request everyday, and hence does not justify the fixed cost of hardware on which it is hosted.
While all looks bright around Serverless architecture, here are few suggestions from my exploration:
- Use coding framework that is light weight on it’s boot-up time. This will avoid having long request processing time for the first request, I’m using node.js.
- While better toolsets for developers are becoming ready and available for general community, consider using tools like Serverless package available on npm registry provided by Serverless.com. It works very well while working with AWS Lambda. It not only takes care of deployment of the code on AWS Labda but also sets up the HTTP endpoint in API gateway in case when event for is configured to be the HTTP endpoint. And everything works very seamlessly. Serverless package can be used even if your solution is not built in node.js
- Never do a lot of things together in one Lambda/Function. Break down time consuming work into multiple chunk of work-items and utilize AWS Simple Queue Service (SQS), or Azure Queues.
- Add enough trace logs, as that would greatly assist in troubleshooting in case of issues.
Here is quick simple example. Let’s first go through requirements. One line requirement is: Application should allow user to create, view, edit and archive notes.
- User can add notes. Application records the note along with date-time when it was posted.
- While adding or editing notes, user can use text formatting. Supported format options are bold, italic, and underline.
- User can view list of notes ordered reverse chronologically.
- User can archive note. On archival, the note would be filtered out from the list of notes.
- User can review list of notes that are archived.
Here is how it is structured:
I’m in the process of enhancing this example application with more features and in the process will end up using more of AWS services.
- Authentication and Authorization,
- Storing more structure along with note, like author, tagging the note, sharing the note with other subscribers.
- Notifications on changes in share
And to support these features I will use DynamoDB, Simple Email Service (SES), Simple Notification Service (SNS) and Simple Queue Service (SQS), and more.
Also plan to port this application to using Azure Functions, more blog posts to come.