Serverless Development with Serverless Framework | Hacker News Reader

Serverless Development with Serverless Framework

thecloud.christmas

137 pointshenriwi105 comments

"With just a small yaml file, two functions and some shell commands, you suddenly have an API which autoscales automatically and you only pay when the API is in use. I think that's pretty cool!"

I am always puzzled about this "autoscale" thing on a cloud.

If your task can be represented as something like calculate sum of some ginormous array then sure. Split array in parts and launch thousand instances each working on it's own slice and then combine.

In way more common situation you have a service hitting database and doing something with it. Sure you can spin a thousand instances of said service. But they will all be hitting the same database. So in reality I think the only really scalable part here is the database. And scalability in databases has no universal solution and the ones that exists come with the load of caveats.

I think unless you operate on FB/etc scale the simplest and cheapest solution would be to buy/rent nice piece of hardware yourself and place database on said hardware. That should give you a nice run for your money and free you from bazillion layers of abstractions, dependencies, etc. that often tend to fall apart.

RE scalability of databases, it is a problem which happens when some of the autoscaling instances are paused in the background and the DB runs out of connections. Amazon's solution is just spend more money on databases

Well, if you really need the autoscale feature to handle sudden and ludicrous spikes of traffic, you will most likely also use a database that autoscales too. i.e. DynamoDB.

For most applications, it's really not needed though.

But like they said, it comes with a ton of caveats. DynamoDB is one of the most confusing technologies I have ever used.

Absolutely agree, I tried it out for a short personal project and was disappointed with the bad documentation and even worse libraries that I found. I'm assuming large companies have their own internal libraries/ORMs for this, and that's how it is intended to be used.

In terms of the actual technology itself, it's very interestingly built, and as the poster above me mentioned, with a ton of caveats to the promises it makes.

It’s because it is just really expensive (both in time and money) to do basic things like a table scan.

That's actually one of the caveats that comes with unlimited scalability: You must design your application to not require full table scans.

It is one of very few technologies that I need to get a pen and paper and some quiet time to decide on a table schema. Most of the time I need to redo it after coming up with new query requirements.

I hate and love it at the same time.

"DynamoDB uses synchronous replication across multiple data centers for high durability and availability"

This does not seem scalable for OLTP type load on some busy store. Again I think you'll be way better of money wise hosting your own database on real hardware either on prem or colocated

DynamoDB is used by Amazon.com.

"Across the 48 hours of Prime Day, these sources made 7.11 trillion calls to the DynamoDB API, peaking at 45.4 million requests per second." [1]

[1] https://aws.amazon.com/blogs/aws/amazon-prime-day-2019-power...

You're forgetting specifics here and the amount of hardware resources thrown into it. I've already told that I am not discussing here FB/Google/Amazon scale stuff. It is their problem and not shared by more regular deployments

TIL: A day has 48 hours at Amazon.

The same day across multiple time zones could take 48 hours

Of course Amazon would call that an Elastic Sundial.

is there any transnational storage solution that actually handles well a traffic spike?

my understanding is that most storage solution scales well when planned, but scaling during a spike only causes more stress onto the current replicas/partitions for all the time needed to boot and shift data toward new replica/partitions, and the new instances don't contribute in moving the load until the process is complete.

so they work if you can predict a spike, but they can't handle a sudden spike, especially if the data to replicate/partition is sizeable.

Part of the design consideration here should be limiting SPOFs like this and creating bounded isolated components which interact with their own persistence layer.

If you're in a traditional three tier architecture you might run into your database being overloaded by the autoscaling behavior but this is fundamentally a provisioning problem. These problems are better served in models that are scalable.

Your suggestion to by a (necessarily overprovisioned) on prem database server is cost inefficient, degrades in value over time, and is effectively a lock in.

Embracing eventual consistency is not that scary!

Even eventually consistent databases have severe scalability limitations compared to how far out stateless functions can scale.

And nobody said anything about on-prem databases. You can hit these issues just as easily with e.g. Aurora or Dynamo.

Autoscaling is a very particular solution to a very particular problem. Being a startup is like trying to make a hit record: everyone wants to become an overnight success. Nobody wants to be an overnight success and then have to turn customers away, or give out a bad impression because their site can't cope.

So a lot of effort goes into producing a site that could be "Facebook scale" if it became necessary. Although since this is difficult (and expensive!) to test, it's likely that some panicked manual intervention will be required if it does take off.

It's really worth asking "what is the cost of scaling" next to "what is the cost of NOT scaling, and what are the chances of it happening?". Is your organisation even able to benefit from rapid scaling - would it be profitable? Or are you going to end up like that luggage company screaming at its customer service reps to work dozens of hours a day?

If your cloud hosting cost goes from free-tier to $100,000/month in one month, and it's real traffic, is your business actually going to be able to pay that invoice?

Is the static overhead of scalability better for your use case than what a normal PC is capable of, which these days can be quite a lot: https://adamdrake.com/command-line-tools-can-be-235x-faster-...

(Been thinking about this since I mentioned the SRCF earlier, which was a single-server host for years: https://news.ycombinator.com/item?id=21741789 )

Cost is a very important factor... But you focused on the high cost end..

The cost of running a production server is something small startup businesses need to budget for... And you don't want to run your production website on a 5-10/month shared server. If you design for the cloud/serverless, you can get your costs down to near-$0 for light usage... But yes, using things like lambda mean a possible bill shock if your traffic grows faster than your income can recover it.. but if you have an advertisement on the page, it probably will cover the execution cost if it's lean enough.

In another example, I inherited a CICD pipeline that cost $300/month and could run 2 of our larger test suites simultaneously.

I converted this to AWS Spot instances and now support thousands in parallel and I pay under $170/month ( https://ldoughty.com/2018/01/gitlab-multi-runner-w/docker-ma... )... But to your point about "what if" costs of this, yes, there's a limit on place for this setup so it can't go over 20 or so... And it is important to consider the impact of auto scaling with regards to the bill... For a small business, AWS effectively doesn't have a way for you to really stop "Bill attacks" or legitimate high traffic on API Gateway/Lambda short of you taking down your site.

My recommendation is: ideally, don't expose something that costs you much too run unless you can recoup the cost from that action (paying customer, advertising).. your homepage should be static or cached in a CDN until you're ready for that large bill.

Dedicated servers are actually quite cheap. I pay $60/month to run one of my products that services thousands of paying customers across North America (High performance native TCP and UDP based game like servers) and the performance is quite predictable

Indeed the servers can be cheap! The inherited configuration used a redhat image with support that added a premium cost on top of being a slightly beefier server to run a few dozen containers simultaneously for testing. With the configuration change we optimized the choices and dropped support.

That said, it really wasn't much work to drop the 6pm-6am costs to effectively 0 unless a developer decided to work late (it automatically scales up)

Please research opportunity cost. The total time you spent to optimize the service was probably in tens of hours.

Multiply that by the amount of money you cost your employer per hour and you'll realize that your "optimization" actually resulted in a net loss.

I'm fully aware of opportunity costs, the investment was made because an investment needed to be made regardless to stand up 2-3 more servers. Doing so would have raised costs to perhaps $400/month if we simply copied existing setups (plus 2-3 days of work, probably, since we had not revisited CICD in over a year)

So by that, I've saved $5,000 in pure server costs. It probably cost me 10 extra man hours to do this way... But I also resolved a bug that was not terribly worth fixing before but took up 30 minutes of time every few months.. and improved the security by taking the servers off the public web.. however you want to quantify security improvements.

I always look at opportunity costs and the automation cost/benefit! The article was researched and written on my own time for my own enjoyment (so this was actually "free" from a business perspective, but my responses factored it in as if I did it as paid work. Just clarifying in case someone wants to claim I'm publishing "work"

For me a huge benefit of serverless is the ease of development speed.

Google's Firebase Functions are ideal for REST endpoints, they bill by the millisecond instead of AWS's 100ms (I think?) pricing.

If you buy into Google's ecosystem entirely they provide you a lot of functionality to get off the ground running. E.g. their (free!) auth service integrates with security around functions. In less time than it takes to look up the YAML for Nginx config you can have a proper authenticated set of REST endpoints up.

Now that said all I have my CPU intensive stuff running on a fixed price VM.

Exactly!! I still think that people do not think enough about the cost of NOT scaling nowadays. And especially, what is it going to cost when I can't scale and I have to change course. I recently heard a podcast where they said: "choosing a distributed databases is probably premature optimization right?", I was pretty surprised. A startup often sells a better user experience. Although less important for US startups since US is a big market, international start-ups won't get many clients further away from their country if the latencies increase signficantly so distributed databases is something you might desire anyway. Secondly they might indeed end up losing clients if they break down due to scaling issues. And at that point, if they want to keep their clients, the options are limited, 1. they'll have to go through a risky deploy to change the database, 2. try to scale it yourself by creating multiple replicas with all problems and technical depth that might bring, finally maybe still losing your clients if you fail and maybe ending up to pay more due to overprovisioning. 3. Accept that clients complain or leave. I would choose FaunaDB or Spanner for my startup personally.

Cloud auto-scaling has made quite a few things in the public sector cheaper to operate. There are the obvious use cases like tax-returns or student-registration, which are annual loads where you could technically scale without the auto part. As more and more things become web-based applications, however, auto-scaling proves it’s worth on things like student/teacher/parent work tools that see a high load during the hours from 08:00-15:00 and again from 18:00-21:00 and almost no loads outside of those times as well as during holidays or weekends.

I've worked places that had racks of servers that were only really used for a few hours a month to support massive financial consolidation runs - that would have been a great workload for a cloud service.

Can't argue about this particular use case. For this cloud is good. You can rent super-duper hardware for few hours and be done with it.

Let's not forget about AWS Aurora Serverless! I keep ranting about this to anyone who will listen, but hands down one of the biggest innovations in cloud infra for exactly the reasons you describe. As the API layer is generally a stateless shim around the database, serverless has limited upside if you can't scale your database sufficiently. But, Aurora Serverless unbottlenecks that concern and makes some very simple and powerful architectures possible. I wonder if there's any open source equivalent to it?

My very obvious question for this is... what's the latency of "spinning up" the DB? It's not discussed on the Amazon page. Their example is someone running a news site, so I imagine the wait time is something under 1 second of overhead to spin-up the DB, but what does it feel like in practice? Are we talking 50ms of wait time for the DB spin-up, or 500ms?

A news site seems like a weird example for an auto-scaling database use case, since, asked to design a news site from scratch, I would aim for 0% of public requests to touch the DB.

You can run a minimum number of vCPUs and add the condition to scale from there. That way you have a minimum threshold for requests.

Ah, so there is always one vCPU running. This makes more sense and was not clear on the product page, thanks.

The company I work at is considering this as part of a pretty big shift in our infrastructure. Beyond the obvious upsides, what cost do they come at?

There's a few. My company has been using serverless aurora pretty much since preview and will keep doing so for some parts of infra, but are moving some services back to provisioned.

- Data is replicated cross region, but your compute all lives in the same AZ, so if (when) an AZ goes down you have to wait for a new instance to be created elsewhere. AWS says the time for this is undefined, IIRC we've seen it be around 15-20 minutes before the DB is back online.

- If you have lots of long running transactions or queries, serverless can have trouble finding a scaling point and won't scale up/down. You can set it to force scaling after 5 attempts, but this results in dropped connections and 1-2 minutes of downtime every time.

- Scaling up actually takes 45s-1:30 for new capacity to be available. If your load is spiky enough that that's too slow, you're stuck with overprovisioning anyways.

- Tools like VividCortex don't work for serverless if you rely on those. Teams here that use serverless have shifted to DataDog APM for this purpose.

- Loading data from S3 doesn't work. This wasn't really a usecase we had but it's something to be aware of.

That said, for gradual load or DB downtime tolerant services it's great! Also very nice for dev environments as the scaling down to 0 can result in some very real cost savings.

Just to make sure: You're talking about the same Aurora Serverless which consists of a single database server instance in a single availability zone without any guarantees regarding availability in case the availability zone goes down? To quote the AWS documentation [1]:

> The Aurora Serverless failover time is currently undefined […]

Don't get me wrong: I really like the idea of Aurora Serverless, but with the current feature set it isn't very compelling.

[1]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

How many small companies would have any failover if their colocated database server went down? Not only would they not have a warm or hot standby, they probably wouldn’t have up to date data.

Because Aurora separates computation capacity and storage, the storage volume for the cluster is spread across multiple AZs. Your data remains available even if outages affect the DB instance or the associated AZ.

I think one of the key benefits of autoscaling isn't the ability to scale out when necessary, but to scale in.

Say you have an idea for a web app that needs a server-side component, but you only ever expect to have a few users. A VPS will cost you at least $5 a month. If you can make your backend serverless, you'll probably only pay a tiny sliver of that, if you even end up exceeding your provider's free tier.

It's not $5 per service unless you only have one service. The scaling is the fact that you run more than one thing on it.

I run a bunch of stuff on a $5 VPS and more still on small machines like raspberry pi's and so on behind it.

On my distro at least, spinning up a real paravirt container (not docker, a full OS with systemd, SSH, etc) within a VPS is a matter of unzipping a bootstrap to /var/lib/machines and running 'machinectl start whatever-you-called-it'.

It's just a different set of abstractions to learn, and at least IMO one that's more valuable.

What you are describing is a very typical "business application" something that is a step above a spreadsheet and a word doc on how to use it.

In those scenarios, the _real_ cost isn't the $5/mo VPS but the managing upgrades, security patches, etc - which would be mostly handled for you in this scenario.

So, if you really are this price sensitive, here's a flip-side.

I built a simple email verification service for A company I used to work for. Used API gateway, lambda, s3, and sqs. Few thousand users a month. I don't need to maintain it, check for security updates etc.

The monthly bill for all that was ~$2 NZD.

I reckon the "Embarrassingly Parallel" vs "Inherently Serial" problem, I think what you are describing is just this all over again

Not unless you also make sure all downstream services are similarly auto-scaling using something like DyanmoDB etc so that capacity can be managed further down. This is the idea of Serverless. Not just taking one aspect of your stack and abstracting it out to a managed service but using managed services across teh baord to help maintain that same "autoscaling" feature.

Sure, but if you have relational data you probably don't want to be giving up your RDBMS for Dynamo. Pain (and inconsistent and hard-to-reason-about data) lies in that direction.

>and scalability in databases has no universal solution and the ones that exists come with the load of caveats.

How is this true? Cassandra/MongoDB/Scylla are all very very popular NoSQL DBs that scale very well and work for a good number of common use cases. Sure you have to be a little more clever when writing certain types of applications with them, but seems like an appropriate trade off. If you don't like that trade off, you can spend a bit more money and get Spanner/FaunaDB and you don't have really any tradeoffs (other than $$$).

> I think the only really scalable part here is the database

That sums it up pretty well.

The great irony here is that those thin, stateless web servers that are the only things to easily autoscale are pretty much guaranteed to never be your performance bottleneck, unless you're doing something really strange.

>unless you're doing something really strange.

all you have to do is run Wordpress with Woocommerce, multiple additional plugins and an overloaded theme with visual builder/editor that needs 512 megs of RAM and 500ms to display a contact form[0]. Some themes can be amazingly CPU intensive.

[0]and 900+ queries, but since most of them are simple selects any cache like redis or memcached removes their performance impact.

> So in reality I think the only really scalable part here is the database. And scalability in databases has no universal solution and the ones that exists come with the load of caveats.

I do wonder what limitations and caveats you are talking about. That is true for many databases who are only consistent on one row/collection/region/snapshot, have strange limitations such as no joins, require your data to be preformatted in a certain way etc. DynamoDB also has a few limitations in those aspects. I have both love and hate memories from my experience with DynamoDB. But nowadays you get to choose between databases like FaunaDb, Spanner, FoundationDB, CockroachDB... So what are the Caveats you still worry about?

If you would combine such distributed databases with edge serverless frameworks like Cloudflare workers I could see amazing possibilities tbh. It's strange how front-end programmers seem to be picking up distributed databases at great speeds due to the benefits of low latency for their users, zero configuration and autoscaling. But it seems that we backenders are reluctant and still prefer our hardware for some reason :). Is it pure pricing?

Everything doesn’t have to be a “FB scale” to need autoscaling. We are a small company, we process messages that come from a queue. During the day, messages trickle in to the point where one small instance can handle the load at a decent speed. At night, to get the same throughput, we scale up to 10 instances. Scaling is based on the length of the queue. It’s a Windows service so we can’t use Lambda, so we have the smallest instance size that we can for it. Some of our newer processes do run on Lambda. The database is not a constraint.

We have another process that is read intensive. The database is a constraint. We autoscale read replicas. With AWS, all of your read replicas read from the same storage arrays (grossly simplifying)

I tend to agree with you, but I don't have the data to back it up. Do you have any success stories to share of modern products that operate at scale on simple, dedicated hardware configurations?

It seems to me, like most things in software these days, we sacrifice performance for convenience at every turn; and in the cloud case specifically we also pick up a good portion of complexity which rarely pays dividends.

I'd wager that for most non-global scale products you can spend a few thousand dollars at the local PC shop and assemble some hardware that will more than support your needs. Although, I'd still advocate backing up necessary data in the cloud for resiliency.

If your software is super resource intensive then you could have people install and run it locally gasp.

If anyone wants to hear about how the Serverless Framework is being used to power a RESTful API for a project, I just put out a podcast episode today where I talked with someone running it in production on AWS.

We went into the details on how a bunch of different Serverless tools and services come together on AWS to serve a RESTful API. The episode covers the development process, the deployment process, pros and cons of Serverless, prices and many other topics around running a Serverless stack with Golang.

That's at: https://runninginproduction.com/podcast/6-qvault-is-an-open-...

There's also descriptive clickable time stamps every 30-60 seconds out of the 55 minute show so if you want to skim around, go for it!

Thanks for sharing Nick, I will check it out.

I really like your podcast features, especially the summary notes with bookmarks to the specific timelines.. saves tons of time to get an idea of the podcast in advance and see if it's interesting to me. Please add a sign-up page, or at least a newsletter sign-up so that I can be alerted to the new podcasts.

Thanks. Those show notes take a long time to make (I do them manually).

As of right now there's no newsletter but if you have an RSS reader there's a feed at: https://runninginproduction.com/podcast/feed.xml

That RSS button is up top next to all of the podcast buttons.

I will add a newsletter at some point. The podcast is very new still, so I wanted to gauge interest a bit before setting up the infrastructure for supporting an email list. It completely tanked when I posted a Show HN about it the other week, so I don't have a ton of guests lined up but it's something I for sure want to pursue.

Nice proof that serverless might be great for projects with a couple of endpoints.

In real life projects, you get a ton of YAML spaggetti boilerplate code and when you hit the endpoint limit on your deployment you will need to start splitting your code over multiple deployments. Compare this with other frameworks where you can actually program your URL router (Django, Rails & co) and it's definitely a step backward.

When you've past the PoC stage, DynamoDB is the first thing you want to replace with PostgreSQL because you need data integrity and migrations. But that's not your only problem ....

When endpoints depend on each other, then it becomes pretty tricky to deploy, cause you'll need to wait until your first endpoint is deployed before you can deploy your second endpoint. So, you're out of the nice "immutable image deployment" paradigm, which means that your frontend code will have to support both old and new versions of each endpoint, just like your backend code will have to support both old and new data structure versions in DynamoDB, as the deployment of a chain of endpoint will take a while and will not be done atomically. This will slow down development velocity for sure.

If you intend to make a real life project live over many fast iterations, then isolating yourself in a proprietary framework like serverless is the last thing you want to do in my experience.

So yeah, for a two-endpoints "Hello World" project where autoscaling is valued over iteration speed, then serverless and dynamodb might be a solution to consider, as long as you're willing to isolate yourself in proprietary frameworks.

That said, you can have autoscaling with iteration speed using open source frameworks anyway (ie. with GKE) so why bother with serverless at all ? Anything you can do with serverless can be done better with k8s and any actually powerful framework such as Django, Rails, Dancer, perhaps even Laravel, CakePHP or Symfony if PHP is your thing.

But let's face it, 99.999% of projects don't need more than 99.9% of uptime which is extremely easy to achieve with a single dedicated server, which gives you a lot of hardware for cheap (unlike AWS). Once you've outscaled a RAM128GB dedicated server then it's time to consider extracting parts of your app into something like serverless.

Regarding programmatic endpoint handlers, these solve completely different problems. Different to the point that there's no reason that you can't employ one on top of the other.

When you start hitting endpoint limits there's a very strong sign that you've had responsibility creep for a microservice, or even worse you're treating your serverless deployment as a monolith.

Your insistence on integrity issues with DynamoDB is also strange. Religious adherence to ACID is not going to be your silver bullet for application design. Learning how to reason about distributed systems and their eventual consistency is necessary to begin with in most cloud setups.

Anything you can do with serverless can be done better with k8s? Cool, have it provision my underlying infrastructure

The thing is that a lot of times serverless is mentioned as "the future", most people I've seen understand "silver bullet": https://aws.amazon.com/fr/blogs/apn/serverless-containers-ar...

As for provisioning, I mentioned GKE already, but I can throw in some more:

https://www.scaleway.com/en/docs/get-started-with-scaleway-k... https://www.ovh.com/world/public-cloud/kubernetes/ https://github.com/bbelky/hkube https://github.com/kubernetes-sigs/kubespray

"Religious adherence to ACID is not going to be your silver bullet for application design. Learning how to reason about distributed systems and their eventual consistency is necessary to begin with in most cloud setups." So you just X10 the development costs for no good reason. Also as a user of many FANG services that are using eventually consistent stores color me unimpressed by the user experience. Considering that a startup or even a F500 company has a pretty low chance of hiring people of the same caliber as those systems were designed by this is nog a good solution for 99% of the projects.

> https://github.com/bbelky/hkube/blob/master/hkube.go

I cannot fathom the process through which one arrived at that file. It started out looking like someone who did not know that shell scripting was a thing, only to morph into a golang program writing out a shell script and exec-s it: https://github.com/bbelky/hkube/blob/master/hkube.go#L193

The icing on the cake is committing a compiled binary for some unknown platform into git

Came into the same issues. I hate example projects like these because they are misleading and read like silver bullets.

The split stack resources thing is extremely difficult to manage due to serverless not supporting CF params. so you have to use CF cross stack references which are horrible or hack in support like we did.

I’ve seen issues where you can’t put the value of a variable as an arn in an event due to the poor abstraction across the top of it as they’ve tried to make it cross provider, completely pointless. Just breaks.

Stick with cf/terraform if you’re starting a big project.

> and when you hit the endpoint limit on your deployment you will need to start splitting your code over multiple deployments.

Firebase allows for 1000 functions per project, all of which can be deployed at once.

If I have more than a 1000 endpoints sitting in a single folder I'll consider that I've gone a bit too micro on the idea of micro-services!

> Anything you can do with serverless can be done better with k8s

The cloud vendors work hard to make ecosystem buy-in convenient. E.g. reduced/no egress charges between their services hosting on the same cloud, and smooth integration between services.

As an example, with Google Firebase I am using their auth, database, and serverless solutions. When I needed to start storing user assets somewhere it was less than half an hour to get everything working end to end including proper security and permissions in place.

Could I have setup a VM and built out some sort of service to manage/serve assets? Sure. There is probably some open source project out there that if I spend a day or two reading up on it I could get it configured, and then get it integrated with my existing auth system.

And then I'd have one more VM to manage security updates on, and worry about deploying.

With Firebase I get test and production environments all setup for me automatically[1], with separate credentials and the works.

It isn't necessarily about scaling speed, it is also about not having to worry about infra.

I think you're confused between FaaS and Serverless. Serverless is an Amazon service, Firebase is not serverless, however both are FaaS. I'm talking specifically about AWS Serverless.

Firebase also offers DBs, storage, and even hosting. I'm confused as to why you say it isn't serverless,

AWS's "Serverless" (wow that name...) looks like a suite of existing products advertised under one label. From their splash page it looks mostly equivalent to what Firebase, although it seems Amazon has some functionality that Firebase itself doesn't have (necessitating using the full Google Cloud).

> I think you're confused between FaaS and Serverless.

I think you are confused about those.

> Serverless is an Amazon service,

No, it's not.

1. The “Serverless Application Model” is an AWS functionality (a transform for CloudFormation templates for serverless [see #3] compute.)

2. “Serverless Framework” is an open-source product that is independent of Amazon (though it originally targeted only AWS) which supports multiple cloud provider.

3. “serverless” is a broad concept for cloud computing without managing server instances, encompassing, among other things, FaaS—AWS popularized the term, but it's used generally across the industry.

> Firebase is not serverless

Someone tell Google: https://cloud.google.com/blog/products/application-developme...

Nice, thank you for the heads up. Nonetheless, they had about 8 tables in their database when they started getting blocked by the endpoint limit on AWS Serverless, I'm guessing they were far from a thousand endpoints.

Since I got to know CDK[0], I prefer it over serverless. It's supported by AWS, too. It can deploy your lambda, or it an just generate a Cloudformation template - these 2 covers the most important features of serverless that our team uses.

[0]https://github.com/aws/aws-cdk/tree/v1.18.0/packages/%40aws-...

Can you elaborate on why you prefer it?

I like CDK because: 1. it's type-checked (using your choice of language/compiler) 2. modularity is done using in-app code, rather than extending serverless with plugins in javascript 3. i think cdk scales better to projects composed of multiple stacks 4. it's somewhat testable

As the fellow commenter said: I mainly like the power of a programming language (loops, variables, organizing file and directory structure).

I like Architect serverless - https://arc.codes. A .arc file is way less boilerplate than a serverless.yaml and it outputs full CloudFormation. Also has awesome async middleware (heads up I wrote the awesome async middleware).

And now we have azure arc...

I've used Up [1] before but this looks even better. Thank you for the recommendation!

[1] https://apex.sh/up

Cool fact: this was created by the creator of Express and Koa! https://github.com/tj

As long as it outputs cloudformation I want nothing to do with it.

You need to store state somehow - either Terraform or Cloudformation, you don’t have that many options. And CDK hides the Cloudformation layer from you.

I found CDK to be exactly what I was looking for. I found myself using either CDK or Amplify (or both) for new serverless projects. It’s now really infrastructure as code, not infrastructure as yaml files.

I've used Serverless framework a bunch. I'd never deploy to Lambda without it. It's far better than eg. Zappa which only supports Python. Would highly recommend it to anyone writing for serverless services :)

Serveless is the reason why I learnt js. It's that good.

That's pretty positive to serverless, as most of them time people learn js because they are into web development.

Nice to see somebody's finally trying to add a layer of abstraction on top of the many proprietary serverless function SDKs <3

It’s not a layer of abstraction any more than Terraform. You can’t just take your functions and port them without changes.

Besides, you can easily do all of your configuration in the web console and export a SAM CloudFormation template for your CI/CD pipeline.

As someone else mentioned, there is also the CDK.

Here is my take on serverless in general:

Ups: Low cost of development. / Only billed for function executions. / Minimal DevOps. / Automatic scaling. / Private functions.

Downs: Vendor lock-in. / No persistent connections. / Expensive. / Limited programming language availability. / No local state. / Shared runtime. / Local debugging is harder. / Cold starts.

I still recommend Heroku if you can live with the costs, but I like where Firebase Functions is going.

If you are interested, here is the full writeup:

* https://github.com/soygul/QuanticDev/blob/master/articles/se...

* Video narrative & examples: https://www.youtube.com/watch?v=Kqk013ioclA&t=12

> No persistent connections

As far as I know, at least AWS has two WebSockets based services.

> Expensive

I think there are use-cases that are rather expensive to solve with serverless technology, like realtime games and such, but overall? I don't know... many companies I've seen using serverless aren't even getting out of free-tier.

> Limited programming language availability

At least AWS has allows to bring your own runtime, it just has to be compiled for Amazon Linux 2.

> No local state

I don't think this is a good thing, but I think Azure does something like that with Durable Functions.

> Cold starts.

Only a problem if you use FaaS and that isn't a requirement for serverless. At least AWS allows to build some types of serverless applications without Lambda. For example APIs can be build with API-Gateway alone or AppSync.

> As far as I know, at least AWS has two WebSockets based services.

True. WebSocket APIs in Amazon API Gateway looks good and is accessible from Lambda functions. Didn't try myself though: https://aws.amazon.com/blogs/compute/announcing-websocket-ap...

> At least AWS has allows to bring your own runtime, it just has to be compiled for Amazon Linux 2.

I did not know this. I will check it out.

> Azure does something like that with Durable Functions

Also didn't know this. Yes local state destroys scalability but it is such a convenience sometimes. Will also check this out.

Lists like this make me feel like I have a fundamental disconnect with serverless. I've yet to experience this low cost of development. Granted, I have a fair bit of sysadmin experience. But, with serverless it feels like I'm trading general system knowledge for arcane provider knowledge.

I tried for weeks on nights and weekends to get anything beyond a simple todo app running with AWS Amplify. I kept running into issues with DynamoDB or AppSync or Cognito. Every time I tried to do something even remotely off the beaten path (e.g., sorting todos by creation date rather than by DynamoDB's non-deterministic sort), I had to tear the whole thing down and start over.

I tried to use the serverless tool, but couldn't even really tell how to get started. They usher you along a sign-up flow before you can even try anything. And a lot of the documentation is just a weird mix of sample projects in various languages.

I eventually gave up and just went back to using Heroku for now and will probably land on a DigitalOcean droplet. I really wanted to like serverless, but it wasn't saving me any time and scaling isn't a concern for a side project :-/

Having used both AWS Lamda + DynamoDB and Firebase Functions + Firestore, I would say Firebase is much much simpler than AWS anything and documentation is just excellent. However Firestore has major restrictions and is ridiculously expensive.

I guess great open-source starter kits still didn't catch up to serverless stuff so it makes jumping in a bit harder. And yes, the restrictions all need workarounds for now. But every year I check serverless stuff, it gets better. I guess it is just not there yet at the moment.

Did you try FaunaDB by any chance? I'm interested in how people who have worked with DynamoDB and Firestore would perceive FaunaDB once they get started. Imho it's is the most serverless database on the market at this point due to features such as: pay as you go, distributed, strongly consistent, security model and their API. When I started using it a while back it didn't feel limited to me at all. (Disclaimer, I have started to work there in the mean time)

I didn't. I briefly checked it out while researching new scalable databases but Fauna looked so young so I didn't dig deeper so I cannot make a comparison.

Modern web development really makes me miss "copy some files to /var/www/html" as a deployment system. Or maybe a cute little `ln` shuffle if you wanna get fancy.

I'm at the tail-end of developing a fairly substantial serverless application and I'm not impressed. We encountered lots of little undocumented caveats, and had to rebuild the thing 2 - 3 times before getting it right. My opinion - aws serverless isn't ready for serious projects. I might offload very tiny microservices as serverless applications.

> I've yet to experience this low cost of development

In my very limited experience, the yaml configuration was a pain, and the testing environment was different enough from production that it felt cumbersome to keep up with both of them.

So now instead of using Serverless, I use expressjs for my API controllers, and I build a Docker image that works exactly the same for testing and production.

I thought serverless was great until i wanted more than a handful of lambdas and an API.

Terraform or cloudformation are not difficult to learn. I sunk way more hours trying to bend my architecture to serverless, while with CF i still use the 8 templates i wrote 2 years ago with minimal changes

Just write your own node project and deploy it on heroku if you want autoscaling

One routes file is infinitely easier than dealing with an abstraction over API gateway across multiple environments

Scripted “cloud formation” for your MVP? Just skip it

As someone migrating from Heroku to AWS right now, I LOVE Heroku, but the cost is killing me.

I know Heroku is built on top of EC2 instances so there's a limit to how low their prices can go, but as EC2 prices go down, it doesn't seem like Heroku has changed their prices at all.

Heroku's lowest priced professional tier (Standard) is $25/mo for a $3.50/mo EC2 instance. I know they do a lot of value-add which is worth paying for but yeah, it's still crazy expensive. Elastic Beanstalk gives a comparable function for just the price of the EC2 instance itself.

Even without the recent major price cuts to api gateway, isn't herokue drastically more expensive?

Unfortunately for those times where you have little to 0 traffic you can't stop paying for your infrastructure like API Gateway can do for you.

.christmas ? What's that?

A tld

I was curious about that too--apparently there's a '.christmas' TLD, and a company named "Bekk" is making programming-blog-advent-calendars for Christmas.

From the bottom of https://thecloud.christmas :

> Bekk is all about craftmanship and the people crafting it. This year, we're creating 12 calendars, each with daily content, articles and podcasts.

It made me think that we were being hit with a bunch of blogspam, but the content appears to be original and decent quality.

We are genuinely not trying to spam anyone, just in the mood of sharing knowledge through small daily blog posts in 12 different areas throughout December :) You can see the 12 advent calendars at https://bekk.christmas and a blog post introducing the concept here https://blogg.bekk.no/introducing-bekk-christmas-ad01660ccad...

PSA: Unless you're working with peer-to-peer networking technology, please don't use the term "serverless". There's still a server there and you know it, and the term is just misleading and confusing.

You're about 3 years too late, that train has left the station.

Serverless doesn’t confuse anyone in this space now anymore than the terms “bugs” and “viruses”. Language evolves.

There is already a name for that. It's called peer-to-peer. I get where you are coming from but you are not accomplishing anything by asking people to not use a particular name. What else are they supposed to say? If you have a more evocative name, try establishing that, and maybe it catches on.

Reply on news.ycombinator.com