AWS Serverless or: How I learned to stop worrying and love Claudia
Two years ago, I slowly started drifting into the mystical and mysterious world of Dockers, containers, swarms and K8s. It was kind of hard and painful to understand, but, at the same time, it seemed wonderful, almost magical.
After running my first 2 containers in clustered mode, I’ve felt like I’ve started ascending to another dimension. The future seemed bright and I continued to learn more and to improve. I had begun preaching the advantages of Docker and Swarm orchestration to everyone I knew. Even my grandparents knew something about it. My whole family had to listen to my stories about how wonderful it is to orchestrate 30 containers on 3 servers almost every day. It felt magical; it felt amazing.
Docker swarm just melts your heart, image obtained from rock-it.pl
A few months later, everybody in my project’s team wanted to learn about this, and everybody thought it was great. We decided that it was time to put our project (10+ linked applications) to this powerful solution even though we had no experts in this field and no DevOps people whatsoever. It took a few weeks of hard work to set up and sync everything, but we felt happy. We got rid of the old webLogic servers that we were using before and felt a sincere relief.
We had the opportunity to run any server in those containers, what an advance! In fact, we could have used any programming language or framework and it would have run smoothly in those small containers. We felt so proud!
Everything ran smoothly for a few months until we started asking ourselves about metrics and high availability mode. We figured that we should not worry much about it; it has to be an easy process, right? Wrong! I cannot stress enough how hard it was to solve the problem with high availability on databases. MySQL, PostgreSQL and Oracle DB each have their own techniques on how to achieve this mode. The docs are as confusing as trying to teach a dog how to use Instagram by just whistling to him. We had to understand the whole new concepts only to achieve this simple task.
After a few weeks, we had done it, we had made a small miracle and everything worked in high availability mode. Our next task was to put KeyCloak in the high availability mode. Once again, pain and suffering entered the office. For the next 2 weeks, we struggled so hard to understand why it was not working out of the box as it should have, and it took as another week to finally implement the solution. After that came the other things, like the metrics and continuous monitoring. To cut a long story short, it took us a long time to set it right, the way we wanted it.
How it feels…
At the end of our journey, we felt happy and proud. The setup was working and it performed well, but we had to invest so much time and energy to achieve it.
Later, I’ve compared it to driving a lovely looking Fiat or Alfa Romeo vehicle. It looks nice, it feels good to drive it and you enjoy it, but it requires so much time, effort and money to keep it running, so you start to ask yourself whether it is worth it.
The new era
Many months have passed and once again, I started discovering and learning about a new mysterious and interesting concept. This time, I started entering the world of Amazon web services.
At first glance, this was even harder to comprehend and get into. It felt so overwhelming. So many services, so many ways to connect them, what do they actually do?
This time, I decided that it was better to simply get a course from Udemy that explains this. So, I got a course and watched it. After just a few hours, everything felt so simple and easy to understand. Almost everything you ever need or you want to achieve is already there; implemented, and works out of the box.
Do you want the metrics and logs? Right ahead, CloudWatch and X-Ray are one click away. You want scalable databases and you want them to perform in high availability mode? Done, AWS takes care of that!
You want to push your data or frontend code to some space and even let it be hosted from there? AWS S3 can do that for you! Or, perhaps, you would like to host your entire application on AWS? You guessed it, EC2 and AWS Elastic Beanstalk are always there for you!
Some of the services that AWS provides
Obtained from begin4learn.gitbooks.io
Pretty much everything you desire is already there. There is no need for complicated and painful configuration. Everything runs in Amazon’s centers and everything works like a Swiss watch. If you somehow get stuck, well, just contact support and have it solved in no time.
You do not have to worry about earthquakes, power-outs, or any other disaster. Amazon has got you covered by its regions and availability zones. You can replicate, secure and scale your environments however you want, using AWS CloudFormation and AWS VPC.
The best thing of all, there is a Free tier. You can test everything and even use it for your solutions free of charge as long as you stick to the free tier limits.
If your application becomes successful and attracts a lot of people, worry not! Everything is either easily scalable or it can be scaled automatically and it will not cost you more than a cup of coffee!
Lambda ex machina
One of the most interesting features that AWS hands over to you if you ask me would be AWS Lambda. As they state, you can run the code without thinking about servers. You pay only for the compute time you use, and if you are using a free tier you get 1 000 000 free requests per month and 400,000 GB-seconds of compute time per month. That is quite a lot!
In my opinion, AWS Lambda sounds fantastic because you can easily write microservices without any stress about configuration or orchestration.
The process of triggering AWS lambda from the Amazon S3
Obtained from: aws.amazon.com/lambda
AWS Lambda functions are trigger-based! This means that they respond only to specific triggers that you set. The trigger can be almost anything, from the Rest API request, Amazon S3 upload or database change to the message that came into the queue.
Lambdas are light! They run in their own special little spaces and you do not need to worry about their configurations. They are quite fast and easily scalable.
Do you want to use AWS Lambda to query on a database? To respond to certain triggers? Resize images? Send emails? No problem! Lambdas cover so many things out of the box.
So, what exactly is AWS Lambda?
Well, to put it simply, Lambda is just a plain old lambda function that you can find in any popular programming language like python, java, javascript, etc. Nothing more, nothing less.
It can be as long or short as you’d like.
A basic lambda function body, written in javascript, would look as follows:
exports.handler = async (event) => {
// TODO implement
const response = {
statusCode: 200,
body: JSON.stringify('Hello from Lambda!'),
};
return response;
};
or, the older way:
exports.handler = async (event, context, callback) => {
// …
callback(null, someResult);
};
Lambda functions can include any dependencies you desire, from the AWS-provided to the language-specific ones. You can either type lambda functions in the AWS Online Code editor or any other code editor on your computer and have it uploaded directly to the lambda console.
Allow me to demonstrate to you a simple example that consists of the following:
Client => Api => Service => DB
In this example, your client would like to store some data to the database. And how would you do it?
Well, if using HTTP/s protocol is your wish, the client can send a request to the AWS API Gateway. Upon receiving the request, API Gateway will trigger the Lambda function that is specified for the specific path, method or resource type of request. That triggered lambda function will actually store the data to the database and return a response.
image of Serverless Microservices Architecture, obtained from DZone’s article
AWS API Gateway works closely with lambdas. With it, you can configure paths, methods, resources, mappings, authentication, authorization and a lot more. API Gateway even allows you to test everything directly from the web console!
Below, you can see a screenshot of what it actually looks like in the AWS API Gateway web console:
AWS API Gateway web console
The beautiful Claudia..
If writing a lot of lambda functions and rest mappings for your project seem odd or too complex, you can always use frameworks and tools such as Serverless or Claudia.js to ease your mind.
Here, atjsGuru.io, we like Claudia.js. That’s why we use it every day to develop, deploy and maintain our applications hosted on the AWS platform.
In the words of its makers, this is what Claudia.js does:
“Claudia makes it easy to deploy Node.js projects to AWS Lambda and AWS API Gateway. It automates all the error-prone deployment and configuration tasks, and sets everything up the way JavaScript developers expect out of the box”.
Claudia.js, in its core, is just a CLI tool with integrated AWS commands.
For instance, when you want to deploy your solution for the first time, you can call claudia create a command to build and deploy your solution to the AWS Lambda.
Example:
claudia create --region us-east-1 --api-module app
If you want to update your solution, it’s as simple as calling claudia update with an optional set of parameters, like for instance:
exports.handler = async (event) => {
// TODO implement
const response = {
statusCode: 200,
body: JSON.stringify('Hello from Lambda!'),
};
return response;
};
Claudia’s functionalities do not stop there. It actually provides two more neat tools:
Claudia API Builder is an extension library for Claudia.js that helps you get started with API Gateway easily, and greatly reduces the learning curve required to launch web APIs in AWS.
If you are used to Express.js for writing node.js web apps, this lib. will feel so familiar to you!
In their own words: “Claudia Bot Builder is an extension library for Claudia.js that helps you create bots for Facebook Messenger, Telegram, Skype, Slack slash commands, Twilio, Kik and GroupMe. The key idea behind the project is to remove all the boilerplate code and common infrastructure tasks, so you can focus on writing the really important part of the bot – your business workflows”.
One massive benefit of claudia.js is that its docs are well-written. It’s easy for junior developers to understand them and any previous express.js developer can hop right in very quickly.
I’m personally using AWS and Claudia.js on a regular basis now, and I feel more relaxed. There are fewer stressful situations and I can concentrate on my tasks instead of worrying about how everything will perform when the next stress test comes.
If you would like to learn more about Claudia.js, I’d recommend you to read this book: Serverless Applications with Node.js: Using AWS Lambda and Claudia.js, by Slobodan Stojanović and Aleksandar Simović
At last, I’d like to make this point:
If you do not have a dedicated DevOps team, special dedicated servers, a lot of time and knowledge about containers, container orchestration and maintenance, then, the AWS and Claudia.js might be an excellent thing for you and your team!
