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.
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.
"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…
Or better yet, forward the errors to https://sentry.io/ and let them deal with error grouping.
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…
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.
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.
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…
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 bec…
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 c…
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.
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…
> Bandwidth at AWS costs about 50 times as much as with Hetzner for example. 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/
Hetzner traffic isn't even that cheap compared to some unmetered offers, for example online.net.
I had to migrate away from Hetzner because I was actually paying 300 dollars on traffic alone.
"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…
yeah but to each stage of a project its solution. If that works at that scale why not?
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."
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.
I just run a server on scaleway for 3€ a month and do everything there. That gives me total control over my things.
I can modify the price in the checkout by changing the URL parameter. Really?
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.
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.
I just run a server on scaleway for 3€ a month and do everything there. That gives me total control over my things.
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.