Introduction to Cloud-Native— Serverless and FaaS
Introduction
New software technologies and architectures are emerging almost day by day with the exponential demands by technology consumers. I have been keen on exploring the ne wrising hot stuff in the market, which brings us to these topics of Serverless and FaaS.
As my usual approach, I’ll be defining what those topics are, and expectations. Lastly, I’d like to solidify the topic with a hands-on example, so that we can basically see how these emerging technologies may emerge our requirements in the industry.
Overview of Serverless
The overall idea of the Serverless model is that developers are fully focused on developing the software solution, and being restraint in dealing with all the infrastructure work that allows the application to run.
As we know preparing the application is one thing. The credit goes to the development team, engineers write the code and prepare. After all, the infrastructure gives the leverage to run those applications using servers and networks.
The infrastructure work can constitute of cumbersome, trivial and expensive tasks. The development team will have to deal with all the configurations, patches, configuration etc. The Serverless approach lifts this heavy burden off of the teams.
Furthermore, Serverless architecture can be automatically scaled up and down by the provider. In addition, the providers usually bill the customers by the usage, it means that you don’t pay when your application is in idle state.
Overview of Function-as-a-Service
“Function-as-a-Service” a.k.a. “FaaS” as the abbreviation known as is an event-driven execution model in which engineers write functions with the business logic in languages that are supported by the cloud providers.
Functions that are deployed in a Serverless environment are invoked by Gateway API managed by the cloud provider. The applications are stateless and run only when they are invoked by the Gateway API.
Advantages and Disadvantages of Serverless and FaaS
Let’s observe short details on those technologies which can help us decide while making technical decisions.
Advantages
- Serverless architecture dramatically reduces efforts of infrastructure and operations. Those tasks can be easily offloaded onto the Cloud providers,
- Finance-wise, customers only pay for when the applications are invoked, idle times are not billed,
- Highly loosely coupled applications can make the software development easier,
- More secure development when using products provided by the Cloud platforms. Engineers don’t have to deal with providing passwords, but use Cloud Provider provided tools like Amazon’s AWS Identity and Access Management (IAM),
- Polyglot programing languages can give freedom to Engineers to write business applications in the languages they wish for
Disadvantages
- Customers are fully locked in proprietary products and platforms, migration of business applications may be tricky,
- Lack of programming languages support by the cloud providers can be an issue, if engineering team is bounded to unsupported languages,
Naming a few of FaaS offering Cloud Providers
Here is a list of popular cloud providers that offer FaaS services:
Hands-on Example
In order to solidify the whole concept, I’ll create a very simple project that gives the current price of any cryptocurrency by given ticker using Amazon Lambda functions. If you want to run the same example, you’ll need to have a verified Amazon AWS account. Let’s start with the steps of preparing the Serverless Environment and the AWS Lambda Function.
Lambda Function Creation
In this step we will be preparing the ground for our FaaS — Lambda function. Head to the AWS Lambda Console and create a new function
The function creation will allow us to create a new function with some specifics, like the language, architecture and Resource Access Management Roles etc. Here is the details to define our simple function
- Function Name: CryptoPriceTickerLambdaFunction
- Runtime: Node.js 16.x
- Permissions -> Change default execution role ->Role name: CryptoPriceTickerBasicExecutionRole
then hit the “Create Function” button.
By now, we have successfully created the new lambda function. The following page will allow us to insert the source code that will be invoked by the Gateway API. Now we need to paste the below source code into the code editor and git the “Deploy” button
Gateway API Creation
In this step, we will perform some actions to allow public internet requests to invoke our Lambda Function and return the calculated result by the Business Application that we have coded earlier.
Now, browse to the AWS API Gateway Console and follow the steps to fulfill the completion of API binding.
We will be creating a simple REST API, and in the Gateway API page we will choose the REST API
In the REST API Creation page, we will enter the following inputs in order to successfully Create our REST API:
- Choose the protocol: REST
- Create new API: New API
- Settings — API Name: LambdaSimpleProxy
Then hit the “Create API” button to finalize this step.
By now, we have created an abstract REST API creation, the following steps will define the details for REST HTTP method bindings for public access into our host and Integration Points bind the requests internally to any products like Lambda etc, which is called “Integration” in Amazon terms.
To head start with initial Resource creation on the Gateway page
- Click on the Root resource which is “/”,
- Then click on Actions,
- In the actions pop-up menu, click on “Create Resource”
After achieving the steps in the pop-up, now we will be faced with the API Resource definition page, in which we will simply define some name and path with the following inputs:
- Configure as proxy resource: Leave unchecked
- Resource Name: cryptoticker
- Enable API Gateway CORS: Leave unchecked
after all, hit the “Create Resource” button
Now we can move towards defining the HTTP Methods on the resource we have created above. In order to create a method on the “cryptoticker” follow those steps:
- In the resource list on the navigation page and click on the “/cryptoticker” resource,
- After resource selection, from the top menu, click on Actions,
- On the Actions pop-up, click on “Create Method”
Once we finish the definition, we will prompted with have a tiny combo box, in which choose “ANY” and press on Check Mark Button.
After the method definition, now we will be able to proceed to the last step know as “Integration Point” which will allow the Any HTTP Method Request into our Lambda function. Follow the below inputs to complete the Integration Point.
- Integration type: Lambda Function,
- Use Lambda Proxy integration: Leave Checked,
- Lambda Function: CryptoPriceTickerLambdaFunction
- Use Default Timeout: Leave Checked
After entering these inputs, hit the “Save” button.
To confirm the Permission, we’ll click on “OK” when prompted with the pop-up dialog box.
Deployment of the API
We are now in the final step which is to deploy our API, so that the changes will be affected and visible to the public. In the same page choose the resource and from the Action Button choose “Deploy API”
Once we choose API Deployment, we will be prompted with the pop-up that will ask for some deployment details.
Deployment Stage: test
Once entered this input, you can hit the “Deploy” button
After the deployment is carried out, in the following page AWS will display the public URL to our API that is reachable by the public. This URL will be different for your tests
Testing the Function
Well, we have succeeded to finish the configuration steps. Now, let’s invoke the URL using a client. For the sake of the simplicity, I’ll use the CURL tool to view some of the details:
