Great work! I love reading stories like this. Lambda isn’t for every usecase but I’d say a large majority of CRUD apps can use this architecture and reduce costs.
For the large majority of CRUD apps the least cost you should be concerned about is hosting, but development time. This kind of architecture adds an extra layer of complexity that is trivially solved with most of the web frameworks out there. I love Serverless, which I chose to design and build a couple of applications, but for some use cases it might not be the best solution.
I’m starting to find a FaaS architecture can remove complexity for the developer.
The CRUD functions themselves are easy to write and test.
Then everything else is handled by the infrastructure layer. Auth, security policies, rate limiting, request timeouts, autoscaling, logs, tracing, etc.
With Rails the developer has to build a lot of this into the application layer. And the dev has to do more operations over time to maintain the app and database.
I am working on a boilerplate app that demonstrates all the functionality you get from “serverless” and documents all of the things we no longer have to worry about:
Rails is a great framework that prevents you from dealing with a lot of boilerplate when it comes to web applications and to focus only on the business logic. There are some great platforms out there (Heroku, for example) that deal with most of the stuff you mentioned (logs, tracing, autoscaling, etc.), and no one prevents you from using a third party service for auth in Rails as well (Auth0, for example). FaaS is awesome, but you've got to code a lot of stuff that Rails gives you for free. Besides, pushing some logic down to infrastructure locks you in the provider you chose. I'm not saying that's bad, because as I've mentioned before I run some apps fully Serverless in AWS, but there's some stuff you've got to take into consideration.
In my (limited) experience with Lambda, there's nothing inherently complex about it. Yes, there's a learning curve, as with anything, but that's a one-off cost. Once you know how, you write the function in a very similar environment you would in any non-serverless setup, and you call it like you would any API endpoint, serverless or not.
Once you have made this investment, you get scale (almost) for free (at least as concerns development/sys admin time). No need to worry about your $5 DO conking out in the middle of the night because you got Slashdotted or whatever the kids call it these days.
Yes, once you get used to the development environment, coding Serverless is pretty smooth. However, when you need something a bit more convoluted than executing a single function, but rather orchestrating a bunch of them across different services, you have to think about stuff like service discovery. Making the right decisions and designing an event driven architecture is going to take time, which is worth money that could pay a lot of servers. With Serverless you get scalability almost for free, but there are trade-offs, so the first you should ask yourself if you're really going to need that scalability or would rather getting to market quicker. In some cases it makes more sense going for Serverless straight away, in some others just using the web framework you're experienced with and in some others a combination of both.
> After the free-tier expires it will be less than $5, but the fact remains: it's crazy cheap.
I like the idea behind serverless development, but DO is $5/month and is easy to setup and maintain. From what I understand as your business grows AWS costs skyrocket and just starting out it's more complicated than a DO solution.
The idea is great, but looking forward to the day where serverless is the default solution because it's easier and cheaper. Not sure we're there yet.
The costs skyrocket if you’re not doing it right - otherwise it tends to be linear with request count. The nice thing, though, is that you don’t have to panic or do anything at any scale - it’ll just keep running along.
Once you hit high levels of traffic, instead of panicking and trying to add more servers and fixing DB structure, you do a cost benefit analysis and see what to do next. Either work on reducing your cost slope, or make it logarithmic by moving to regular servers.
The problem is the per request cost is going to be astronomical compared to what it needs to be once you e.g. get above the initial 1 GB/month tier. Bandwidth at AWS costs about 50 times as much as with Hetzner for example.
> Once you hit high levels of traffic, instead of panicking and trying to add more servers and fixing DB structure, you do a cost benefit analysis and see what to do next. Either work on reducing your cost slope, or make it logarithmic by moving to regular servers.
...and that's a good reason to try to avoid the lock-in of AWS specific services. Relatively entry level setups on alternative platforms will let you scale well past the system where AWS costs starts to get painful and people start panicking about how to cut costs. When you hit that point you really don't want to be facing a major re-engineering effort to be able to even use other options to bring the cost down just as the costs are soaring.
The problem with some of the unmetered offers is that it's hard to know how much you'll actually be able to use, and for how long (before they oversell), so there's some appeal in paying for actual capacity. But certainly, you will pay a premium for that.
Thanks for pulling the actual numbers - I was too lazy to verify, so figured it best to err on the conservative side (and also depending on how high you go, the AWS prices per TB drop quite a bit).
The big issue is reserved instances - in order to get that level of savings you need to lock in for a year. At that point you're basically running on-prem servers since you're committed.
Exactly this. You could host cheaper with a really low tier VPS, but as soon as you get posted to hacker news, game over. If traffic increases to such a degree that this architecture is no longer the best choice, we can move off without constantly fighting to keep our tiny server(s) alive.
Using Codenvy for development, Github for code, Netlify for deployment and hosting, and Firebase for a database, in total I spend exactly nothing on my side projects.
Try https://github.com/amark/gun , it is a popular (~7.5K stars) truly open source (MIT/ZLIB/Apache 2) database that has Firebase like features (realtime sync) plus a lot more, like graph/table/document/relational data and a P2P/decentralized architecture, by yours truly. :)
Yes, we just announced/released the alpha of our auth framework a while ago, called SEA (Security, Encryption, Authorization).
Because it is based on P2P/decentralized cryptography, it is actually pretty hard and cutting-edge to implement (you get end-to-end encryption automatically with it!), but we've made it ridiculously easy for developers to use:
It is alpha though, still has several more features that need to be added to make it usable for different types of app (so you might want to stick with Firebase till then). Please let me know if you have any questions or anything else I can help with!
We're in the middle of upgrading our docs/resources, maybe this is helpful? http://gun.js.org/docs (note: some pages are broken)
We have pretty in depth conversations on the chat room too, here https://gitter.im/amark/gun but I'm more than willing to answer any other questions you have that might not be covered!
well basically I would just know where it falls short of Neo4J's capabilities, and if it is possible to have more than one graph running at the same time.
- You can have more than 1 graph at the same time, yes.
- Storing data on edges can be done in GUN by having an "edge node", Neo4j has a special built-in edge node which makes things easier (including bidirectional edges, which can be done in GUN, but requires making an edge node).
- Neo4j's Cypher query language has a lot of built in edge search algorithms, we have not (but plan to) built these yet.
- Neo4j has a very nice dashboard, our community has built a couple similar tools, but nothing as comprehensive.
Summary: Neo4j, being over a decade old, has a lot of features that we haven't built yet.
Why use GUN instead? The biggest kicker is it being based on a P2P/decentralized (Master-Master) architecture, which makes ops/scaling much easier and a ton of other things. If you don't need this, probably stick with Neo4j for its feature set.
It's JSON storage so version control comes from the code rather than a schema or migrations. I'm happy with that.
Lock-in is a problem but it's true for any non-open service you integrate with. I've considered it and figured I'd rather have the features firebase offers than not. Plus I could actually swap to a CouchDB service like Cloudant really easily for my use case (sync'ing JSON structures between browser sessions).
Scaleway are horridly unreliable. I run a SaaS business, and hosted first with DigitalOcean which amounted to roughly one outage per month. I then tried hosting with Scaleway for a few months to cut costs.
On Scaleway, I averaged 53 outages every month. Average response times were slower. Longer outages meant I had to manually hard-restart the server, which corrupted all the database indexes. Scaleway also has a huge problem with machine availability. Last time I checked, everything was out of stock.
I'm hosting on AWS now, and it's about as reliable as DigitalOcean.
One outage per month in DO? Curious, we had a dozen machines running there and never experienced that. Unless they were very short-lived (we used Uptime Robot's free plan, which has a 5m interval). Or maybe it's the DC? We used AMS2.
Ditto for me. SFO2 has been extremely reliable. Every few months I'd get emails about planned router updates with the possibility of high packet loss for 10-15 mins but it never occurred.
For my side projects I don't need things to be easy. I need them to be interesting, and I want them to be challenging. Deciding to do things for zero cost is an interesting constraint. I could do everything for a few dollars but I'd rather spend my time working out how to do it for free and then buy beer.
"Getting a push alert any time there is an error helps us respond to issues as soon as they come up. "
Oh god no.
Maybe if this system is not expected to ever grow in complexity. Otherwise this will become a big source of frustration really soon. And even if it does not, it's very easy to get a flood of non-actionable alerts for a transient condition.
It would be better to collect error rates and alert on that. Also the other golden signals.
You know for people who live in an ever changing environment and are constantly editing our own reality - so much so that we need to track it in "source control" - developers are kind of funny how they get stuck on doing things "the right way."
Do they really get stuck on doing things "the right way",
or do they get stuck on making off-the-cuff remarks about doing things "the right way" for easy karma?
A valid concern. However even after reddit and hacker news has had their way with the site, my phone has been impressively quiet. These push notifications are only for cases where the lambda functions thrown an error that isn't handled anywhere else (i.e. something is very wrong).
Can also use a negative price! I wonder what would happen if you went ahead with that. Presumably the payment gateway wouldn't pay me $5. Seems a strange choice to be having those parameters in a GET.
Everything that can be modified by the user is not suitable.
The price must be stored on the server side, everything on the client side is subject to modification.
The price is checked server side. You have to pass the price somehow to the client in order to display it. This is no different than any other ecommerce site, except that you can see it in a GET param.
I can "change the price" of anything on Amazon with dev tools, but that won't help me when I go to buy it. I appreciate the concern because amazingly this has been a real vulnerability on sites before (recently on a crypto exchange I think).
Once upon a time, my fav food ordering place had the discount encoded in the URL. Couldn't stop myself from trying, reduced the price by a very small number and it actually worked irl!
Sure you can overpay if you want, and you can underpay and not get the tickets you are trying to obtain fraudulently. It's only a problem if the vendor actual sends you product that you didn't pay for. This isn't an instant digital download.
It is checked server-side. I understand why people are concerned that the price is passed in a way that they can see vs grabbed via javascript or another method like most other sites, but that doesn't change the responsibility to check the data server-side. I can edit my POST requests to Amazon but they better not sell me stuff for $0, and neither will this site.
Impressive but my side projects are even cheaper to run because 1/3 of the way through I lose excitement, never finish them and then don’t do anything with them. ;) Nice post!
Or do it like it was 1999. Host it yourself. I had a $20 DO, I've downgraded it to the $5/month plan. My next goal is to move that shut down the VM sometimes this year and host it on a raspberry pi myself.
I don't get it. Is hamiltix scalping tickets? I thought the ticket sellers control re-distribution. How can it accept payment for tickets someone else is holding?
> We also made the decision to not use a javascript framework for the front end, mostly because they are incredebly [sic] complex and some people suggest they are all terrible (or maybe great?).
Not to mention that for back-end developers, the learning curve is steep and ever-changing especially when one considers the "build" process. Is it grunt, or gulp these days, or webpack, or NPM, or some Frankenstein combination of all of them?
76 comments
[ 2.0 ms ] story [ 205 ms ] threadThe CRUD functions themselves are easy to write and test.
Then everything else is handled by the infrastructure layer. Auth, security policies, rate limiting, request timeouts, autoscaling, logs, tracing, etc.
With Rails the developer has to build a lot of this into the application layer. And the dev has to do more operations over time to maintain the app and database.
I am working on a boilerplate app that demonstrates all the functionality you get from “serverless” and documents all of the things we no longer have to worry about:
https://github.com/nzoschke/gofaas
Once you have made this investment, you get scale (almost) for free (at least as concerns development/sys admin time). No need to worry about your $5 DO conking out in the middle of the night because you got Slashdotted or whatever the kids call it these days.
https://github.com/nzoschke/gofaas
One difference is that I use SNS for cheap email or SMS error notifications.
I like the idea behind serverless development, but DO is $5/month and is easy to setup and maintain. From what I understand as your business grows AWS costs skyrocket and just starting out it's more complicated than a DO solution.
The idea is great, but looking forward to the day where serverless is the default solution because it's easier and cheaper. Not sure we're there yet.
Once you hit high levels of traffic, instead of panicking and trying to add more servers and fixing DB structure, you do a cost benefit analysis and see what to do next. Either work on reducing your cost slope, or make it logarithmic by moving to regular servers.
> Once you hit high levels of traffic, instead of panicking and trying to add more servers and fixing DB structure, you do a cost benefit analysis and see what to do next. Either work on reducing your cost slope, or make it logarithmic by moving to regular servers.
...and that's a good reason to try to avoid the lock-in of AWS specific services. Relatively entry level setups on alternative platforms will let you scale well past the system where AWS costs starts to get painful and people start panicking about how to cut costs. When you hit that point you really don't want to be facing a major re-engineering effort to be able to even use other options to bring the cost down just as the costs are soaring.
It's actually closer to 70x
Hetzner: 1.25 USD per TB (after 30 TB free per server) [1]
AWS: 90 USD per TB [2]
So, 100 TB at Hetzner will cost you 125 USD (not counting the 30 TB free). You would pay 9000 USD at AWS.
[1] https://wiki.hetzner.de/index.php/Traffic/en
[2] https://aws.amazon.com/ec2/pricing/on-demand/
I had to migrate away from Hetzner because I was actually paying 300 dollars on traffic alone.
Firebase still has a ton of features we don't have, what would you say are the most important things for us to work on?
Because it is based on P2P/decentralized cryptography, it is actually pretty hard and cutting-edge to implement (you get end-to-end encryption automatically with it!), but we've made it ridiculously easy for developers to use:
- Easy getting started guide: https://hackernoon.com/so-you-want-to-build-a-p2p-twitter-wi...
- 4 minute nad 40LOC interactive coding tutorial: https://scrimba.com/c/c2gBgt4
It is alpha though, still has several more features that need to be added to make it usable for different types of app (so you might want to stick with Firebase till then). Please let me know if you have any questions or anything else I can help with!
We have pretty in depth conversations on the chat room too, here https://gitter.im/amark/gun but I'm more than willing to answer any other questions you have that might not be covered!
- You can have more than 1 graph at the same time, yes.
- Storing data on edges can be done in GUN by having an "edge node", Neo4j has a special built-in edge node which makes things easier (including bidirectional edges, which can be done in GUN, but requires making an edge node).
- Neo4j's Cypher query language has a lot of built in edge search algorithms, we have not (but plan to) built these yet.
- Neo4j has a very nice dashboard, our community has built a couple similar tools, but nothing as comprehensive.
Summary: Neo4j, being over a decade old, has a lot of features that we haven't built yet.
Why use GUN instead? The biggest kicker is it being based on a P2P/decentralized (Master-Master) architecture, which makes ops/scaling much easier and a ton of other things. If you don't need this, probably stick with Neo4j for its feature set.
Lock-in is a problem but it's true for any non-open service you integrate with. I've considered it and figured I'd rather have the features firebase offers than not. Plus I could actually swap to a CouchDB service like Cloudant really easily for my use case (sync'ing JSON structures between browser sessions).
On Scaleway, I averaged 53 outages every month. Average response times were slower. Longer outages meant I had to manually hard-restart the server, which corrupted all the database indexes. Scaleway also has a huge problem with machine availability. Last time I checked, everything was out of stock.
I'm hosting on AWS now, and it's about as reliable as DigitalOcean.
Outages are all tracked by Pingdom.
Scaleway not so.
Oh god no.
Maybe if this system is not expected to ever grow in complexity. Otherwise this will become a big source of frustration really soon. And even if it does not, it's very easy to get a flood of non-actionable alerts for a transient condition.
It would be better to collect error rates and alert on that. Also the other golden signals.
Having dealt with payment gateways, I would not assume that.
I can "change the price" of anything on Amazon with dev tools, but that won't help me when I go to buy it. I appreciate the concern because amazingly this has been a real vulnerability on sites before (recently on a crypto exchange I think).
developer toolset : amazon lambda
business toolset: zapier
personal toolset: ifttt
correct here?
1. http://www.lowendstock.com/
Not to mention that for back-end developers, the learning curve is steep and ever-changing especially when one considers the "build" process. Is it grunt, or gulp these days, or webpack, or NPM, or some Frankenstein combination of all of them?