Stackery Adds Provisioned Currency to Hasten Serverless Cold Starts – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Stackery Adds Provisioned Currency to Hasten Serverless Cold Starts – InApps in today’s post !
Read more about Stackery Adds Provisioned Currency to Hasten Serverless Cold Starts – InApps at Wikipedia
You can find content about Stackery Adds Provisioned Currency to Hasten Serverless Cold Starts – InApps from the Wikipedia website
After some months of beta testing, serverless abstraction provider Stackery has fully integrated AWS Provisioned Concurrency into its platform, making configuring the feature as easy as checking a box and filling out a single field.
Debuted last year at AWS re:Invent, Provisioned Concurrency tackles one of the primary obstacles cited when talking about serverless: cold start times. While serverless functions save you money by not running when they’re not needed, you can pay in the form of startup time when a function hasn’t been running. While the cold start time for a Node.js function may be just 100ms, the start time for a Java or .NET function can run can last for several seconds, impacting the user experience. Provisioned concurrency solves this by keeping certain functions initialized and ready to respond faster — in the span of “double-digit milliseconds,” according to Amazon.
In the blog post describing the new feature, Stackery Chief Technology Officer Chase Douglas calls the issue of the cold start a “previously intractable” issue that “only pragmatic workarounds that require a certain amount of system ‘brain surgery’” were able to address. With Stackery’s integration of AWS Provisioned Concurrency, however, the problem is handled with a “simple checkbox” in the Stackery visual editor, explained Douglas in an email, and the result goes beyond the feature itself, offering an infrastructure-as-code style interaction.
“Without Stackery there are two routes for managing Provisioned Concurrency. One is to configure Provisioned Concurrency within the AWS Management Console, which is simple, but it doesn’t help with maintaining reproducibility through infrastructure-as-code. This leaves you open to manual, time-consuming and error-prone steps. The other is on AWS SAM/CloudFormation, in which you have to modify all references to the functions that will use provisioned concurrency. For example, if you set up the function to receive events from an API route, you not only have to add the setting to the function, but you have to update the reference to the function from the API route,” wrote Douglas. “Stackery makes provisioned concurrency a simple checkbox in our visual editor and saves it to a SAM/CloudFormation template so anyone on your team can re-use your configuration without having to configure settings in the AWS console.”
In addition to Stackery’s visual editor, the functionality is also available in the Stackery Visual Studio Code plugin. And while Douglas highlights the ease-of-use, he also offers a couple of caveats for potential users. First, the number of Lambda instances you can have running in a region will be affected by those you configure to be kept warm. Second, the feature “isn’t without cost,” he writes, noting that “the costs of Lambda functions are rarely significant for production-level traffic, but may not be for you if your team is only experimenting with settings.”
For Stackery CEO Tim Zonca, the integration of AWS Provisioned Concurrency speaks to the most basic issue addressed by Stackery, that of taking care of the details of how infrastructure runs and letting the company focus on delivering business value. Zonca said that many companies he speaks with say they simply don’t have the time to deal with those things.
“One of the things that Stackery does really well is we allow people to build and deliver applications that span more than 20 different AWS serverless resources. We give people the context to ultimately worry about kind of how your infrastructure behaves, not how it actually runs under the covers,” Zonca told InApps. “You’re not going into AWS and just using one set of capabilities and then jumping to a different interface with a different set of capabilities. You have one way to interact across a pretty broad swath of AWS services.”
And as to whether or not the cost of keeping function instances warm could end up costing customers so much that it would cancel out the benefits of serverless, Zonca said it didn’t seem likely.
“In general, it’s really common across our customer base that we end up saving them a bunch of money as it relates to how they can leverage the serverless resources that they’re using from AWS. We’ll keep an eye on it, but my gut says it’s not an issue,” said Zonca.
Amazon Web Services is a sponsor of InApps.
Feature image by Nattanan Kanchanaprat from Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.