
Serverless Components - skellertor
https://github.com/serverless/components
======
skywhopper
Ugh, while I appreciate the work that goes into these tools and see the value,
I hate the needlessly critical language about “irrelevant” details and
“bloated” cloud infrastructure.

These components are lightweight and simple and trivially easy to use because
they are lightweight and simple and cover trivial use cases. But if you build
anything beyond the trivial you will eventually have to get into the weeds,
and the details are no longer irrelevant, and the “bloat” will happen to your
beautiful lightweight and simple Serverless configuration.

There’s no need to ridicule the inevitable complexity of complexity to sell
this stuff. It’s just pointless negativity.

~~~
ac360
"Complexity is inevitable" is a self-fulfilling prophecy.

~~~
skywhopper
I think you misread what I wrote.

~~~
ac360
Not all infrastructure configuration options are relevant to every use-case.
By focusing on specific use-cases, you can hide "irrelevant" config options.
This is a fact.

The full statement from the source material says bloated cloud infrastructure
"configurations", referring to verbose configuration files. Needlessly
critical? It depends on your experience with these.

These, serverless, cloud, and more are abstractions. Fortunately, if the
abstraction doesn't fit your needs, you aren't forced to use them.

------
davidjnelson
It’s interesting that lambda still requires a nosql db for good perf. The
example they link to from this article uses dynamodb. Not a great choice for a
general purpose web app, where sql would be a better choice for many use
cases.

[https://github.com/serverless/components/tree/master/templat...](https://github.com/serverless/components/tree/master/templates/8-fullstack-
application)

It’s cool that aws has the data api for lambda to connect to aurora
serverless. But then you’re stuck with MySQL instead of postgres, and also
stuck with ~100ms db access times.

[https://www.jeremydaly.com/aurora-serverless-data-api-a-
firs...](https://www.jeremydaly.com/aurora-serverless-data-api-a-first-look/)

~~~
jwilliams
What makes DynamoDB a bad choice for a web app? Seems to be where it excels.

~~~
davidjnelson
It’s difficult to model relationships. You have to design a hashing strategy
manually to avoid hotspots. Most web frameworks are based on sql. The api is
extremely verbose and there isn’t the same level of maturity for abstractions
which simplify it. Indexes are much more complicated
[https://docs.aws.amazon.com/amazondynamodb/latest/developerg...](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.Indexes.html)
In general, the tooling is less mature. You can run a fake dynamodb locally,
but not the exact same engine.

There are certainly use cases where nosql is very helpful - heavy writes, as a
denormalized cache, simpler non relational data models etc
[http://highscalability.com/blog/2010/12/6/what-the-heck-
are-...](http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-
actually-using-nosql-for.html)

~~~
jwilliams
I feel like we might be diverging on what "a general purpose web app"
represents.

I've never really seen those issues unless there is a more extreme
circumstance.

In my read of "web app", in most cases you want to push/data in and out of the
database. And modelling 1:1 and 1:n relationships is pretty natural in my
experience. Deeply nested relationships are a pain, but they're usually a pain
in SQL too. Document-orientation helps here a bit, but with some drawbacks.
Where I think it does fall over completely is analytics, and OLAP-like work.

I guess hotspots can be an issue. However, that implies considerable related
transaction volume, which I'd argue DynamoDB _can_ excel at.

If you're using a framework like Rails - then sure, DynamoDB is out. But so is
Lambda. The pattern of SPA (React/etc), Lambda, and DynamoDB is what's
emerging instead of those frameworks. Definitely agree it can't cover many
cases, but covers a lot of ground for me

~~~
davidjnelson
Right, I'm talking about many to many relationships. Those are a pain to deal
with in non relational databases. It's possible, just not the simplest tool
for the task. This is a great strength of sql, especially when coupled with a
good orm used wisely. Also, don't underestimate the power of frameworks like
rails, django et al for productivity.

Most apps I write for my own business, or see in production at companies I
work for use a mix of sql and nosql depending on what they are doing. Mongo
seems quite popular for heavy write loads, while still supporting some
indexing and querying. It's great for fan out also.

------
Fredej
As someone who's always late to the party on these things (I just picked up
Docker this year! Yay!) this seems like exactly what I've been missing when
trying to pick up serverless.

Granted I haven't really tried building anything yet, but part of that is that
I needed a way to get an overview what could even be done. This seems like a
nice way to get introduced.

~~~
reilly3000
Serverless is fantastic for event-driven workloads at arbitrary scale. There
are definitely some things to learn about serverless runtimes, but beyond that
there isn't much complexity aside from the large hill to climb which is
understanding IAM.

Here are a lot more examples:
[https://github.com/serverless/examples](https://github.com/serverless/examples)

And if you'd rather define the infrastructure side as code vs YAML, you might
want to check out Pulumi as well:
[https://github.com/pulumi/examples](https://github.com/pulumi/examples)

~~~
squirrelicus
> arbitrary scale

If you have arbitrary funds.

Point is serverless costs more per unit deliverable

~~~
johnday
Asymptotically, yes. But if you factor in development time, infrastructure
management and security concerns, the point where serverless really "costs
more" may be very high indeed.

~~~
squirrelicus
I would love to hear the argument that serverless impacts cost of security
concerns at all. I'm not warm to the idea that it also impacts development
time, but I'd love to hear that argument too.

------
ac360
Responding to some of the questions regarding "Why Serverless Components?"

When the Serverless Framework was created in 2015, there were only few use-
cases you could do with a serverless architecture (an architecture built on
auto-scaling, pay-per-execution cloud services, like AWS Lambda) because the
services that had serverless qualities were few and immature.

Since then, a growing number of new and existing cloud services have
"serverless" qualities. These days, "serverless" seems less of a fad, and more
of an important chapter in the story of the cloud, as it evolves as an
abstraction over infrastructure.

It's likely large and small cloud vendors will continue to introduce
serverless cloud services to the market. All of which will continue to expand
the number of use-cases you can do with a serverless architecture.

The Serverless Framework's initial application model is a great abstraction
for many use-cases, and it helped hundreds of thousands of people start
building serverless applications, easily.

Now, it's time to expand that model. Serverless Components represent multiple
models, all designed around specific use-cases. This approach can better suit
the growing number of serverless use-cases we're seeing. Additionally, as
students of developer tooling and infrastructure provisioning, we've learned
that by first knowing the use-case, you can build better infra/app automation
that's faster, more stable and more relevant. There are many innovations we
seek to introduce with the Serverless Components paradigm.

Overall, the "serverless" movement is about building applications with
radically low overhead. As software eats the world, this trend seems to have
come at an appropriate time. Serverless cloud services will continue to emerge
and mature. Fortunately for us, they represent the greatest building blocks of
all time. Who knows, perhaps a new golden era of software development is upon
us.

Either way, Serverless Components is here to make it even easier for every
developer to deliver radically low cost/overhead software.

------
imafish
I develop and maintain an app using the serverless framework. I have set up
db, API gateway, functions, queues and custom domains through it and love how
easy it is to get going but also how powerful the framework has shown to be in
terms of configuring the underlying services.

With that in mind - you already have a system that is highly configurable and
easy to figure out - I really have a hard time figuring out what the purpose
of Serverless Components is - is it mainly the sharing Components part?

~~~
yumraj
What all services/db/frameworks are you using?

~~~
imafish
My backend is all on AWS, while my frontend is on Netlify.

The backend is a simple event based system. I am using Lambda (.NET Core),
DynamoDB and SQS on the backend. Frontend API calls trigger Lambdas, which
either schedule or create SQS messages, that fan out to a number of Lambdas.
For domain management I use serverless-domain-manager which is able to create
subdomains in AWS Route 53 and create mappings between CloudFront and Route 53
DNS.

I have two deploy stages, dev and prod, which automatically deploy to their
separate instances and subdomains. This is all setup in a single
serverless.yml file and deployed through AWS CloudFormation (which Serverless
allows me to know practically nothing about and still deploy my changes).

GitLab CI/CD builds, tests and deploys my dev stage on commit to develop
branch, while the prod deploy is a manual job in GitLab from the master
branch. Netlify also automatically deploys the frontend on commit.

So I guess that is my tech stack :)

Edit: Also, these services are practically free until you hit a substantial
amount of resource consumption.

------
stunt
I really respect the idea behind Serverless Framework. However, thanks to
cloud providers it's impossible to build a cloud agnostic solution with it.
You always end up creating resources that aren't cloud agnostic alongside your
serverless template.

~~~
ac360
Serverless Components will really help here. Please stay tuned.

------
ernsheong
I recommend folks try out knative, which allows you to wrap up pretty much
anything in a container, and deploy the container in serverless fashion. In
GCP it manifests as Cloud Run, which has been great for me so far :)

------
ac360
Excited to see this on HN!

Many common use-cases (APIs, Websites, Websocket backends, Scheduled tasks)
are perfect for serverless architectures.

Serverless Components give you a React-like experience to deploy them more
easily than ever.

\---

Short video preview:
[https://twitter.com/goserverless/status/1156977112147845120](https://twitter.com/goserverless/status/1156977112147845120)

\---

Here's a quick-start guide...

Install Serverless Framework __

• npm i -g serverless

•
[https://github.com/serverless/serverless](https://github.com/serverless/serverless)

\---

Pick a template:

• Serverless Fullstack App -
[https://github.com/serverless/components/tree/master/templat...](https://github.com/serverless/components/tree/master/templates/8-fullstack-
application)

• Serverless Websockets Backend -
[https://github.com/serverless/components/tree/master/templat...](https://github.com/serverless/components/tree/master/templates/7-backend-
websocket)

• Serverless API Backend -
[https://github.com/serverless/components/tree/master/templat...](https://github.com/serverless/components/tree/master/templates/6-backend-
monolith)

• Serverless Website -
[https://github.com/serverless/components/tree/master/templat...](https://github.com/serverless/components/tree/master/templates/4-website)

• Scheduled Task -
[https://github.com/serverless/components/tree/master/templat...](https://github.com/serverless/components/tree/master/templates/3-scheduled-
task)

• & More -
[https://github.com/serverless/components/tree/master/templat...](https://github.com/serverless/components/tree/master/templates/3-scheduled-
task)

\---

 __Make sure you have AWS credentials set up __

•[https://github.com/serverless/components#credentials](https://github.com/serverless/components#credentials)

\---

Hopefully these enable everyone to build more and manage less.

Enjoy,

Team @ Serverless.com

~~~
Ezku
> React-like experience

Can you elaborate on what you mean by this? As a user of both serverless and
react I’m afraid I’m failing to see your point here.

Other than that - exciting stuff. I’ve been eagerly waiting for the ability to
build some more powerful abstractions, preferably with as little yaml as
possible. :)

~~~
ac360
Sure.

Serverless components can be used declaratively (YAML) or programmatically
(JavaScript).

It's the JavaScript experience that takes a lot of inspiration from React when
you wish to write your own reusable Serverless Component.

[https://github.com/serverless/components#reusability](https://github.com/serverless/components#reusability)

