
Serverless Development with Serverless Framework - henriwi
https://thecloud.christmas/2019/9
======
FpUser
_" 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.

~~~
pjc50
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-...](https://adamdrake.com/command-line-tools-can-
be-235x-faster-than-your-hadoop-cluster.html)

(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](https://news.ycombinator.com/item?id=21741789)
)

~~~
ldoughty
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...](https://ldoughty.com/2018/01/gitlab-multi-
runner-w/docker-machine-and-spot-instances-for-much-cheaper-ci/cd/) )... 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.

~~~
user_50123890
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.

~~~
ldoughty
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"

------
nickjj
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-...](https://runninginproduction.com/podcast/6-qvault-is-an-open-source-
tool-to-manage-passwords-and-crypto-keys)

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!

~~~
guru4consulting
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.

~~~
nickjj
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](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.

------
1337shadow
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.

~~~
nostrebored
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

~~~
1337shadow
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...](https://aws.amazon.com/fr/blogs/apn/serverless-containers-are-the-
future-of-container-infrastructure/)

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.scaleway.com/en/docs/get-started-with-scaleway-
kubernetes-kapsule/) [https://www.ovh.com/world/public-
cloud/kubernetes/](https://www.ovh.com/world/public-cloud/kubernetes/)
[https://github.com/bbelky/hkube](https://github.com/bbelky/hkube)
[https://github.com/kubernetes-sigs/kubespray](https://github.com/kubernetes-
sigs/kubespray)

~~~
qaq
"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.

------
snypox
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-...](https://github.com/aws/aws-
cdk/tree/v1.18.0/packages/%40aws-cdk/aws-lambda)

~~~
nailer
I like Architect serverless - [https://arc.codes](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).

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

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

~~~
snypox
Cool fact: this was created by the creator of Express and Koa!
[https://github.com/tj](https://github.com/tj)

------
scrollaway
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 :)

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

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

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

~~~
scarface74
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.

------
soygul
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...](https://github.com/soygul/QuanticDev/blob/master/articles/serverless.md)

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

~~~
nirvdrum
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 :-/

~~~
soygul
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.

~~~
databrecht
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)

~~~
soygul
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.

------
celim307
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

------
rolltiide
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

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

~~~
freehunter
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.

------
avip
.christmas ? What's that?

~~~
robrtsql
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](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.

~~~
mikkelbd
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](https://bekk.christmas) and a blog post introducing
the concept here [https://blogg.bekk.no/introducing-bekk-christmas-
ad01660ccad...](https://blogg.bekk.no/introducing-bekk-christmas-ad01660ccadf)

------
peterkelly
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.

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

