Stackery Support For NoSQL Tables
One piece of technology that goes hand-in-hand with serverless tech is NoSQL databases. They tend to be more granularly scalable, as their scaling mechanism is some form of “just throw more shards into it.” And with recent improvements, services like AWS DynamoDB even have auto-scaling support.
Today, I’m pleased to announce Stackery support for NoSQL databases. You can now drag Table nodes into your stacks to provision AWS DynamoDB tables in your account. Even better is the fact that we set up autoscaling for you!
Stackery Tables can also take commands from Function nodes. You can send insert, put, select, update, and delete messages with easy-to-use structures that allows for conditions, atomic operations, limits, and ordering. And as with all our resource nodes, if you’re a DynamoDB power user you can get a reference to the table as a value of an environment variable. Then you can use whatever library you prefer to interact with the table.
At Stackery we use a traditional SQL database for most of our data, but we’ve already found a great use for our Table node. When we recently launched support for easier custom domain provisioning for Rest Api nodes we needed a way to keep track of SSL certificate requests issued by AWS Certificate Manager. When a new cert is requested via a CloudFormation Custom Resource in our customers’ stacks, we inserted the record into a new Table. Once a minute, we run a checker Function that checks on the status of certificates while we wait for customers to approve them. That function selects all the records from the table and checks them all in parallel.
One last interesting feature of the Table node is the output port. Table nodes send messages to Function nodes every time a record is inserted, updated, or deleted. This can be an excellent way to trigger side effects like sending an email after a transaction is processed.
We’ve found a lot of good use cases for the Table node at Stackery. Give it a spin yourself to see how easy it can make building your next serverless app!
Nate Taggart | February 26, 2019
Cloud-Side Development For All with Stackery's Free Tier
#### Further Reading On Cloud-Side Development:
__The Anatomy of a Serverless App__ We call an application deployed into a cloud service provider an active stack. This stack has three primary components - the functions where the business logic resides, the managed cloud services that serve as the building blocks of the application and then the environmental elements that define the specific dependencies and credentials of for a particular instance of the first two components. This [anatomy of a serverless application](https://www.stackery.io/blog/anatomy-serverless-app/) post goes into the full detail of what serverless teams will build and manage. Our friends at Lumigo on [the need to test cloud-side](https://hackernoon.com/serverless-testing-from-the-trenches-790e77301c74) (and some slower and manual non-Stackery methods for doing so). Corey Quinn of Last Week in AWS (sign up for the snark, stay for the news, pay for the bill reduction) [sparked this conversation](https://twitter.com/QuinnyPig/status/1092794159415611392) on twitter.
While I appreciate AWS's support for the local development model, I can't shake the feeling that it's the wrong approach to Serverless development. Can we talk about that?— Corey Quinn (@QuinnyPig) February 5, 2019
Likewise, this “[localhost is dead to me](https://twitter.com/mweagle/status/1093590457278390272)” rant by Matt Weagle, organizer of the Seattle Serverless Days, won him a shiny new Stackery account. This thread also garnered some helpful nuance and commentary from Amazon engineers James Hood, Preston Tamkin, and iRobot's Ben Kehoe.
1/ Twead incoming...— Matt Weagle (@mweagle) February 7, 2019
I think we need to distinguish between local execution of user code & local emulation of managed services. I don't think anyone's against the ability to run a function locally. But if it calls a DynamoDB table, local code should call a real table, put there via a CFN deploy— Ben Kehoe (@ben11kehoe) February 8, 2019