Serverless Architecture (Part 1)
Serverless Architecture (Part 1)
Serverless: You know it, you love it, so learn more about it. Let's take a walk through how serverless breaks down units of work and configuring AWS Lambda.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Of course, “serverless” doesn’t actually mean that there are no servers required to run new features. It just means that we don’t have to deal with the infrastructure. That means we don’t have to worry about scaling, multi-server communication, and other problems related to distributed systems. Lambdas do everything for us!
Serverless can also mean applications where some amount of server-side logic is still written by the application developer, but unlike traditional architectures, it is run in stateless compute containers that are event-triggered, ephemeral, and fully managed by a third party. These type of services have been previously described as ‘BaaS’ or ‘Backend-as-a-Service’.
Why Use Serverless?
No more servers
Scalable and flexible
In the diagram below, the units of work get smaller and smaller. We’ve gone from Monolithic -> Microservices -> Functions
There are already companies who provides functions as a service. Here are some of these:
Amazon – AWS Lambda
Microsoft – Azure Functions
Auth0 – webtask
Iron.io – IronWorker
Planet Rational – webscript
There are many other services available, and all of these differ in their technical capabilities and implementations.
Serverless architecture allows us to build pieces of code that do something useful, and at the same time, run quickly without consuming a lot of server resources. But that doesn’t mean that those functions are usable only in small scenarios. Although a function is a small unit, it can be invoked many times per second.
Now that we've gotten the basics and benefits out of the way, let's dive into our example of this series.
AWS Lambda is a compute service that lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and scales automatically, from a few requests per day to thousands per second. You pay only for the compute time you consume – there is no charge when your code is not running. With AWS Lambda, you can run code for virtually any type of application or backend service – all with zero administration. AWS Lambda currently supports Node.js, Java, C#, and Python.
You can use AWS Lambda to run your code in response to events, such as changes to data in an Amazon S3 bucket, an Amazon DynamoDB table, etc.
Now we will build a mailer application in Scala and put that application in AWS Lambda with a AWS S3 PutObject trigger.
Step 1: Create a lambda blank function:
Step 2: Configure triggers:
Step 3: Configure the function, choose Java 8 as the language.
Step 4: Upload your executable JAR and set the environmental variables.
Note: You can find the sample project from here AWS-Lambda-Scala-Mailer
Steps to make an executable jar:
- git clone https://github.com/knoldus/AWS-Lambda-Scala-Mailer.git
- cd AWS-Lambda-Scala-Mailer
- sbt assembly
Step 5: Set the Lambda function handler and role.
Then click Next. Your Lambda-scala-mailer is ready! This function will get triggered by S3 actions.
If you find any challenge, let me know in the comments.
Stay tuned for the next blog on serverless. Until then, happy coding!
Opinions expressed by DZone contributors are their own.