Serverless Components | Hacker News Reader

Serverless Components

github.com

83 pointsskellertor34 comments

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.

I think the implied missing phrase is "for a simple deployment". How the web server works and and how the certificate is issued are irrelevant to launch a personal blog, but before this, if you wanted to do that on Serverless, you had to worry about that stuff.

Their point is that you don't have to worry about any of this stuff to get simple tasks done, which you used to have to worry about.

In time we will have an article about serverless components being bloated, and how what we really need is componentless components. Why bother with all the configuration and deployment? Just write it as procedural javascript and serve it from your laptop!

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

I think you misread what I wrote.

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.

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

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

AWS has also introduced Query API for AWS RDS, and Data API for Aurora Serverless. Both are designed to send query requests over HTTPS (same as what you would do with DynamoDB). And that means the Lambda function doesn't have to deal with a database connection, thus there shouldn't be performance issues when using Lambda+RDS "anymore".

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

100ms is pretty damn slow still unfortunately. Also, I much prefer postgres to mysql.

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

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

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

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.

You can't just use the same data models and normalization strategies of a relational databases in the DynamoDB. Plus there are many differences with other Nosql databases too that you must be aware of. (e.g. scaling behaviour)

I often see teams and devs failing to use DynamoDB effectively only because they don't know/use best practices. It just needs more time.

What I don't like about DynamoDB is the vendor lock-in. Otherwise it's a great product and works really well for many use cases.

I agree DynamoDB is a great product that works well for many use cases. I use it for certain things and it works very well. Relational db's are a better fit for most web apps though.

+1 on querying model challenges: https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

DynamoDB, however, has:

1) 1st-class integration with aws-sdk

2) A cool feature "streams" which can trigger other services when your data changes: https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

For what it's worth, this tool kit (components) could be useful useful for the toy case of someone setting up something like DocumentDB. DocumentDB (not DynamoDB) is the mongo-emulating nosql document-based DB option-- it has automated vertical/horizontal scaling (up to 64tb https://docs.aws.amazon.com/documentdb/latest/developerguide...)

A DocumentDB cluster has no public endpoints so any resources that interact with it (ie a lambda function) need to be in the same. You can't modify a lambda's VPC unless that lambda function has a special permission set from an IAM blah blah

Automating that bit would be cool

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.

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

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

>> if you'd rather define the infrastructure side as code vs YAML

Or AWS CDK

https://aws.amazon.com/cdk/

> arbitrary scale

If you have arbitrary funds.

Point is serverless costs more per unit deliverable

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.

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.

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.

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?

What all services/db/frameworks are you using?

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.

Good question. I responded in a separate comment regarding "Why Serverless Components?"

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.

Serverless Components will really help here. Please stay tuned.

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

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

---

Here's a quick-start guide...

Install Serverless Framework

• npm i -g serverless

• https://github.com/serverless/serverless

---

Pick a template:

• Serverless Fullstack App - https://github.com/serverless/components/tree/master/templat...

• Serverless Websockets Backend - https://github.com/serverless/components/tree/master/templat...

• Serverless API Backend - https://github.com/serverless/components/tree/master/templat...

• Serverless Website - https://github.com/serverless/components/tree/master/templat...

• Scheduled Task - https://github.com/serverless/components/tree/master/templat...

• & More - https://github.com/serverless/components/tree/master/templat...

---

Make sure you have AWS credentials set up

• https://github.com/serverless/components#credentials

---

Hopefully these enable everyone to build more and manage less.

Enjoy,

Team @ Serverless.com

We updated the Template links. The correct ones can be found here:

Pick a template:

• Serverless Fullstack App - https://github.com/serverless/components/tree/master/templat...

• Serverless Websockets Backend - https://github.com/serverless/components/tree/master/templat...

• Serverless API Backend - https://github.com/serverless/components/tree/master/templat...

• Serverless Website - https://github.com/serverless/components/tree/master/templat...

• Scheduled Task - https://github.com/serverless/components/tree/master/templat...

• & More - https://github.com/serverless/components/tree/master/templat...

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

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

Reply on news.ycombinator.com