Here is an example of a full Chat Application that demonstrates how you can provision and extend this Serverless Realtime Application Component programmatically, very much like a React Component.
But there are CloudFormation Linters.
And there is also the CF editor for Visual Studio.
They are in the process of releasing a kit to define your infrastructure programmatically, and let them deal with the mess of CloudFormation as a compiled IR they send to their backend when you deploy.
You’re still defining your resources declaratively - just with type checking - at least if you’re using a statically typed language. If not, you’re still just getting runtime errors when you run your program. It might catch some things before you run your template - but so will a linter.
Neither will catch issues like using a subnet that doesn’t exist or using an AMI that doesn’t exist.
The CDK does: you’re either explicitly bypassing the safety checks, are explicitly importing a value (which necessarily is validated at runtime), or have to provide a subnet definition to instantiate the relevant object.
You then use these programming language constructs to implement higher level ideas like applications, fully in a programming language.
So if you change the configuration, the component will be able to figure things out.
As of today, those are the available components:
1) Serverless Framework
The Serverless Framework enables you to provision serverless applications in a Function + Events pattern. Using this, you can accomplish the patterns you're describing, and hundreds of thousands of people are doing this already with the Framework.
2) Serverless Framework Enterprise
SFE works with the Serverless Framework to give you more than development and deployment convenience. SFE focuses on other phases of the serverless application lifecycle, like monitoring, alerting, security, collaboration, secrets and much more. It's a powerful solution for teams and orgs investing more in serverless application development.
3) Serverless Components
This is a new take on serverless application development. We've learned the serverless community and teams are looking for ways to deploy and share composable architectural pieces (features, use-cases), more than infra. So we're building a new type of provisioning system to enable this. The Realtime Application Component is an example of this.
Is Serverless just for API use cases or does it support other event triggers like SNS and SQS or one of the patterns we use is
S3 Event -> SNS -> SQS -> lambda and all of the related permissions and subscriptions.
But then again, isn’t the whole purpose of using Serverless instead of SAM to be cloud vendor neutral? Once you add AWS specific resources doesn’t that go against the whole ideal of using Serverless?
You can deploy this example. It contains a Create React App front-end and it uses DynamoDB on the back-end to keep track of who is connected to the Chat Application.
In the interim, check out this Component (which is used by this project) which provides a simple webockets backend and can be used for that use-case - https://github.com/serverless-components/Socket
- Why does it take ~4 seconds to load (blank) the page? Is it a PWA with no pre-loading / static initializers?
- The scroll-jacking in the 1-2-3 section is broken on Safari
Kinda disappointing because the Serverless project is very useful, and while the engineering behind the framework is great, the site has way too much going on for how simple it should be.
That being said, how hard is it to move the data off this platform and migrate it to another once you've reached scale?
When it comes to migration, it depends on your use-case. A few suggestions which may be helpful:
* Consider your data strategy (much lock-in happens at this level). Most serverless architectures leverage DynamoDB because its design pairs well with stateless compute like AWS Lambda. You can use DynamoDB within all types of architectures.
* Don't use AWS API Gateway specific URLs in your application. Use custom domains. This will enable you to easily swap out your websockets endpoint. Fortunately, there is only 1 endpoint in this architecture, so there is little surface area to refactor.
* Make sure you understand the cost of these serverless technologies at scale before building with them. But don't forget to factor in the reduced labor costs of using serverless technologies.
The difficulty really depends how deeply integrated your application becomes with the underlying cloud provider and its services. It may be a simple application consisting of few a JS Lambdas and DynamoDB tables, or it may utilize half of AWS' offerings. In the case of the latter, may god help you.
My question is what is the ceiling? At what point do you need to move off the platform and how easy is the migration?
I find people are pretty gun shy to park their data into a platform that doesn't make it easy to migrate off (Parse comes to mind).
I've included some performance info in a comment below.
One of the child Components powering this project is the Socket Component, which allows anyone to provision a serverless websockets backend simply. You can use it here: https://github.com/serverless-components/Socket
This project's pattern uses a single AWS Lambda function for all of those events, for the sake of simplicity as well as performance because by receiving more events, the function is kept warmer than average.
Further, when the user loads a page, if you establish the connection at that time, you warm up the function in the background by sending the connection event.
Here is full Chat Application example you can deploy to test performance: https://github.com/serverless-components/RealtimeApp/tree/ma...
When deployed to us-east-1 and using it in San Francisco, when the Chat App loads, it establishes the websockets connection immediately via React's componentWillMount(), which will warm the AWS Lambda Function. By the time I send the first chat message, the function is already warm, and it takes ~100ms on average to send and receive messages.
Given this experience, our hypothesis is if we can greatly increase the speed of deployment, developers will be less interested in local emulation.
With Serverless Components, we're now achieving incredible results. First deployment always takes a bit longer due to initial creation of resources, some of which are global (e.g. AWS IAM), but all Serverless Components are designed to deploy as fast as possible and we're aiming for ~5s max in deployment time as our key metric. We'll go into detail later about how we've been able to optimize this.
It seems non-trivial to set up at this point
EDIT: Still reading into it... https://serverless.com/framework/docs/providers/aws/guide/te...
Would love to here a best practice case study from someone who has deployed something like this