Getting Started with Serverless Architecture on AWS

Recently, I met a friend who works for a big tech firm for a coffee and was telling him about a super-cool in-house startup that I am currently working in with serverless architecture. Being a traditional dev, he had dozens of questions about it, like “What do you mean no servers?” and “How does your API work?”. So after this long discussion, I thought to myself that I should write a blog post about serverless architecture.

What is Serverless Architecture?

Think about a traditional web application for a moment. Assume you made this awesome web app to book flights to Mars. You host your app on a server you bought and pass the app onto a few of your friends. Now your friends (i.e. clients) send requests to the server. The server does its magic and sends a response back to the clients and the app works like a charm.

Suddenly, on the very next day, your app goes viral and everyone wants to go to Mars. Now, your server can’t handle the excessive amount of traffic your app is getting and therefore, it’s about to fail. You either have to buy a bigger server or buy a few servers and a load balancer to handle all the traffic you’re getting. Both of them will cost you a serious amount of money. Additionally, you need to maintain your servers, patch security related issues, hire server maintenance stuff, etc.

It goes without saying that they all cost you extra. You also have to bear the risk of server or LB failure. Even though on some days, you only get little traffic, you have to pay for all the servers you aren’t actually using. Now, that’s not a very good solution to any business. What if we can put all our code in a box and it takes care of this entire burden for us? So that we can really focus on the app and not worry about the underlying bits and pieces? That would be awesome, right? That is exactly what serverless architecture is about.

So… no servers?

Serverless, unlike the name suggests, isn’t about getting rid of all your servers. Even though your app is built on top of serverless architecture it still runs on a servers somewhere managed by someone else. But you wouldn’t have to take care of the expenses and burden of managing them yourself like in traditional architecture. Giant tech companies like Amazon will take care of them for you and you will only pay for the computing power and the memory your app needs in order to run smoothly.

When a serverless app gets a client request, it will spin up a compute instance (pretty similar to a virtual machine inside a big server) which then handles the request and dies after sending the response. If your app is getting many requests it will spin up many compute instances to handle the traffic behind the scenes. If I didn’t make myself clear, Serverless architecture is super scalable. And more importantly you pay nothing if your app does not get any requests someday. Cool! Isn’t it?

Why use it?

Like any other startup, cutting down costs is important to us. Even though we are still in the early stages, we want our startup to be the next big thing (well… isn’t that the plan of all startups?). So why not equip your product with cutting edge technology right from the start so that you can conquer the world one day! After all, didn’t you assume you’d be sending people to Mars?

But seriously, we are using it because it works. Of Course you need to consider the way serverless applications work and write the code accordingly. But when you get used to, it isn’t that hard (What’s hard is configuring AWS API gateway and AWS IAM. More on this later). We implemented our serverless app on top of the services provided by Amazon. For our RESTful API, We are using AWS Lambda, AWS API Gateway and DynomoDB. We also use a neat framework also called Serverless (Confusing? I know) to manage all this in one place.

AWS Lambda

AWS Lambda is a computing platform that doesn’t need to be administrated or monitored. It runs chunks of JavaScript or Python code as responses to various events on top of respective environments. Those chunks of code are known as lambda functions. DB querying, running node modules and pretty much anything you do on NodeJS or Python can be done inside these functions. At the time of implementation, developers can define timeout and memory needed for a function to execute. The computing power a function receives is proportional to the memory allocated to the function.

When a lambda function is triggered by an event, it will create a computing instance with the defined memory and computing power to execute the lambda function, passing event details as a parameter. If an event happen to trigger a lambda function a 1,000 times lambda will create 1,000 computing instances and execute them all in parallel. This means everyone can use your app to book flights to Mars without any hassle after which, those computing instances will be terminated or reused. Read this article by Tim Wagner if you’re interested about lambda life cycle.

Cool. Now you know lambda functions and they are triggered on events. But that is not exactly a web app. You need to have a public exposed web API and a way to trigger these lambdas on request to API endpoints. That’s when AWS API gateway joins the party.

AWS API gateway

Amazon API gateway is an incredibly simple way to create scalable RESTful APIs. With API gateway you can create resources and http methods literally in minutes. It’s a matter of typing the resource URL and selecting a method name. What’s really nice about API gateway is you can map a certain lambda function to be executed upon a request to the API endpoint.

Assume you have an endpoint called api.flytomars.com/v1/flights?date=today. On GET request to the resource, you need to return details of flights that travel to mars today. After making the resource architecture with API gateway, you can write a lambda function to query a database and return the flight details. Get parameters will be passed to the lambda function attached to an object called context.

API gateway has a caching mechanism that you can enable to improve the latency of the requests to your API. It caches the responses of cache-enabled endpoints for a time-to-live (TTL) period. API gateway also allows you to download an API SDK in 3 different languages (javascript, android and ios) that you can directly use with the application you are developing to call API endpoints.

Building a RESTful APIs on Amazon’s serverless infrastructure is simple as that. In a real scenario, you have to take care of authentication, authorization, database connection and few other things but Amazon have services to take care of all that. (Will talk about them in future posts)

Serverless framework (previously known as JAWS)

Being able to write lambda functions and map them to APIs is nice. But writing lambdas one by one separately and configuring API gateway will quickly become painful to maintain once your API start to grow. Lack of structure and unable to do continues integration will bite you in back in the long run.

Serverless framework introduces a base structure that you can use to organize the serverless code and AWS configuration. Developers can take advantage of the best practices built into the framework out of the box. It allows optimizing the code better and having the code and the configuration in a one place removes what was lacking to do continuous integration.

Few other advantages of framework are

• Individual function deployment
• Test your code locally (check this plugin by my colleagues at 99X technology to locally test APIs with dynamodb)
• Inbuilt versioning
• Allows staging
• Awesome community to help you

Conclusion

Serverless is one of the buzz words you hear in the tech community these days. Although it’s a relatively new concept, it’s getting lots of traction and most of the tech firms are looking into it. Undoubtedly, It’s a great way to cut the costs of traditional web applications. At the same time serverless architecture allows companies to focus more on the applications they develop rather than the infrastructure. Its easier for companies to scale as well.

What’s next?

Now you know the bare-bones of serverless architecture and the services, frameworks needed to build an API or microservices on top of Amazon web services. Awesome! Pat yourself on the back. On the next blog will look into actually implementing an API with serverless framework using the things we discussed today. Feel free to share your thoughts in the comments. Until the next time, Cheers!