Epsagon Plug-In Packages External Serverless Code for AWS Lambda – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Epsagon Plug-In Packages External Serverless Code for AWS Lambda – InApps in today’s post !
Read more about Epsagon Plug-In Packages External Serverless Code for AWS Lambda – InApps at Wikipedia
You can find content about Epsagon Plug-In Packages External Serverless Code for AWS Lambda – InApps from the Wikipedia website
Serverless monitoring tool provider Epsagon has released a new tool aimed at reducing duplication and increasing developer velocity when building their serverless functions.
“When you are deploying a new serverless function using the Serverless Framework, you wrap all of your code and push it in a package to the vendor’s platform,” explained Nitzan Shapira, Cofounder and CEO at Epsagon.
But, said Shapira, that might include some common code that a developer needs to use in each function they are writing. That code is probably written and saved locally on the developer’s machine, which makes it difficult to add it directly to the serverless platform using a package manager. In that case, a developer might end up duplicating the same processes in each package they are writing: copying the common code and making sure they include it in the package every time they deploy.
“So we created a plugin for this that developers can use,” added Ran Ribenzaft, Cofounder and Chief Technology Officer at Epsagon. The serverless-package-external plugin allows developers to add the external code to their AWS Lambda configuration files. “Depending on your number of deployments, this could save several hours every month,” said Ribenzaft.
The project offers similar capabilities to AWS’ own enhancement of its Lambda service, which provides a way for users to layer in additional libraries to the base code itself.
Common code that a developer would add to each function ends up acting like an external dependency that is added to the function package. That, in turn, means that it should be assessed to ensure that it is not introducing any security threats into a serverless workflow. But just like vetting external dependency libraries before introducing them, once it has been assessed, the common code can be used regularly without having to check it each time. This makes security oversight a first-class citizen when designing serverless systems without slowing down new function deployments.
Clearing Lambda Storage
This latest open source tool from Epsagon comes on the heels of other offerings Epsagon has made to the community in the past year. Alongside the external package plugin, Epsagon also released an open source tool — Clear Lambda Storage — specifically for use in AWS serverless environments.
AWS saves a copy of each version of each function to S3. That can add up: a function may be rewritten and redeployed regularly, meaning it is not uncommon to have many multiple versions of the same function stored in S3. This quickly becomes redundant. “You don’t want to jump back 45 versions made more than a month ago if you ever need to rollback,” said Ribenzaft.
For those who have been managing serverless workflows for some time, there is another issue: AWS has a function and storage layer limit of 75 Gigabytes.
For Ribenzaft and Shapira, clearing out their S3 storage layer in AWS became a necessity for themselves internally, which is how the open source tool came to be.
“I just need the latest version of each function, so with this open source tool, we remove all my old stuff, I keep the latest versions and the rest of them I can delete,” said Ribenzaft. “We have done it on ourselves several times. You still have everything in your source code so you can roll back to any time by just rebuilding the package and uploading it again, but this script deletes everything that isn’t the latest version of each function.”
Lambda Inventory Insight
One of Epsagon’s most popular open source tools to date has been List Lambdas.
In a serverless environment, it is easy to end up with one hundred, or one thousand, Lambda functions operating in different regions of a globally distributed application architecture, in a number of programming languages, some being used, some not.
“There is no dashboard where you can say, ‘these are all of my Lambda functions, how many invocations they have had, what the cost of each function is, what languages they are written in or what region of the world they are operating in,’” said Ribenzaft.
The full Epsagon monitoring tool provides deeper insight into each function, and more so, as Shapira says, as in serverless it is necessary to take a global perspective so that instead of monitoring each individual function as an atomized unit, users can take a look at all of their serverless resources: “Not just the Lambdas but the message queues, the storage, the APIs. Serverless is more than just the functions, it is about monitoring the whole application and not just the function.”
Shapira believes that is where the true value of the Epsagon product lies, so providing an open source tool that allows users to inventory their Lambdas at the function level does not give away the keys to the kingdom, but is a useful community tool to help some adopters start thinking about function resource use.
“This is really useful and gives you a nice glance of what is going on in your serverless functions,” said Ribenzaft. The tool can export a list in a command line interface or as a CSV file.
Users can gain insight into the region, function name, memory, code size, timeout, runtime language, and last invocation dates and can filter queries to just get the relevant functions listed if needed. Any further features — such as a small dashboard to convert the data to a visual display — would require either a pull request or a community contribution… or subscription to the Epsagon product.
Amongst serverless players, this approach to open source is gaining some ground. Instead of offering an open source version of their main product, with limited functionality, players like Epsagon are contributing stand-alone open source tools that do not require any ongoing relationship with the provider in order to use.
But as serverless is still a relatively new software development approach, there is a vast need to skill up users and populate the ecosystem with tools that reduce the complexity of learning a whole new approach to globally distributed application architecture. Tools like the List Lambda open source project help skill up serverless adopters by assisting them to understand the importance of monitoring. The hope is that as serverless architects become aware of the value of monitoring via using open source tools, they then become ready to look deeper at Epsagon’s full monitoring offering.
Epsagon is a sponsor of InApps.
Feature image: Photo by Mohit Kumar on Unsplash.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.