Introducing the CDN node
With Stackery, you could use the Object Store node to serve files to your users - it provides a simple way to host files for your users, from static websites to large video files and everything in between. Hosted on Amazon’s S3, you can be assured that the files in the Object Store node will have high reliability. However, users today demand instantaneous access and are more likely than not to leave if your site takes too long to load for them.
This is where a CDN (Content Delivery Network) comes into play. Providing a large number of geographically distributed servers, your user’s request is routed to the nearest CDN server for a quick turnaround rather than having to travel half the world to get to the server where your site is, adding seconds to the response time.
Today, we are happy to announce the CDN node, which makes setting up a CDN in front of your Object Store trivially easy. We take care of all the work needed to configure CloudFront, connect it to the S3 bucket along with all the permissions, and set up SSL for you.
Just put the CDN node in your stack and connect it to an Object Store node, tell us what domain to run on, and deploy your stack. Once you deploy your stack, your site admin will get an email to approve the SSL cert, then in 10-20 minutes, your CDN will be fully up and running. The only step remaining is for you to create a DNS record for the CDN.
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