6 ms·

Serverless Components

83 points by skellertor 7y ago

ac360 7y ago
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/templates/8-fullstack-application https://github.com/serverless/components/tree/master/templat... • Serverless Websockets Backend - https://github.com/serverless/components/tree/master/templates/7-backend-websocket https://github.com/serverless/components/tree/master/templat... • Serverless API Backend - https://github.com/serverless/components/tree/master/templates/6-backend-monolith https://github.com/serverless/components/tree/master/templat... • Serverless Website - https://github.com/serverless/components/tree/master/templates/4-website https://github.com/serverless/components/tree/master/templat... • Scheduled Task - https://github.com/serverless/components/tree/master/templates/3-scheduled-task https://github.com/serverless/components/tree/master/templat... • & More - https://github.com/serverless/components/tree/master/templates/3-scheduled-task https://github.com/serverless/components/tree/master/templat... --- 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 7y ago
  > 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 7y ago
    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
- ac360 7y ago
  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/templates/fullstack-application https://github.com/serverless/components/tree/master/templat... • Serverless Websockets Backend - https://github.com/serverless/components/tree/master/templates/backend-websocket https://github.com/serverless/components/tree/master/templat... • Serverless API Backend - https://github.com/serverless/components/tree/master/templates/backend-microservices https://github.com/serverless/components/tree/master/templat... • Serverless Website - https://github.com/serverless/components/tree/master/templates/website https://github.com/serverless/components/tree/master/templat... • Scheduled Task - https://github.com/serverless/components/tree/master/templates/scheduled-task https://github.com/serverless/components/tree/master/templat... • & More - https://github.com/serverless/components/tree/master/templates https://github.com/serverless/components/tree/master/templat...
imafish 7y ago
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 7y ago
  What all services/db/frameworks are you using?
  - imafish 7y ago
    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.
- ac360 7y ago
  Good question. I responded in a separate comment regarding "Why Serverless Components?"
davidjnelson 7y ago
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/templates/8-fullstack-application 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-first-look/ https://www.jeremydaly.com/aurora-serverless-data-api-a-firs...
- jwilliams 7y ago
  What makes DynamoDB a bad choice for a web app? Seems to be where it excels.
  - davidjnelson 7y ago
    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/developerguide/SQLtoNoSQL.Indexes.html 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-you-actually-using-nosql-for.html http://highscalability.com/blog/2010/12/6/what-the-heck-are-...
    - jwilliams 7y ago
      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
Fredej 7y ago
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 7y ago
  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
  - pdelgallego 7y ago
    >> if you'd rather define the infrastructure side as code vs YAML Or AWS CDK https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/
  - squirrelicus 7y ago
    > arbitrary scale If you have arbitrary funds. Point is serverless costs more per unit deliverable
    - johnday 7y ago
      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 7y ago
        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 7y ago
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.
skywhopper 7y ago
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 7y ago
  "Complexity is inevitable" is a self-fulfilling prophecy.
  - skywhopper 7y ago
    I think you misread what I wrote.
    - ac360 7y ago
      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.
- jedberg 7y ago
  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.
deleted 7y ago
[deleted]
ernsheong 7y ago
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 :)
stunt 7y ago
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 7y ago
  Serverless Components will really help here. Please stay tuned.

83 points by skellertor 7y ago

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/templates/8-fullstack-application https://github.com/serverless/components/tree/master/templat... • Serverless Websockets Backend - https://github.com/serverless/components/tree/master/templates/7-backend-websocket https://github.com/serverless/components/tree/master/templat... • Serverless API Backend - https://github.com/serverless/components/tree/master/templates/6-backend-monolith https://github.com/serverless/components/tree/master/templat... • Serverless Website - https://github.com/serverless/components/tree/master/templates/4-website https://github.com/serverless/components/tree/master/templat... • Scheduled Task - https://github.com/serverless/components/tree/master/templates/3-scheduled-task https://github.com/serverless/components/tree/master/templat... • & More - https://github.com/serverless/components/tree/master/templates/3-scheduled-task https://github.com/serverless/components/tree/master/templat... --- 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 7y ago
> 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 7y ago
  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
ac360 7y ago
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/templates/fullstack-application https://github.com/serverless/components/tree/master/templat... • Serverless Websockets Backend - https://github.com/serverless/components/tree/master/templates/backend-websocket https://github.com/serverless/components/tree/master/templat... • Serverless API Backend - https://github.com/serverless/components/tree/master/templates/backend-microservices https://github.com/serverless/components/tree/master/templat... • Serverless Website - https://github.com/serverless/components/tree/master/templates/website https://github.com/serverless/components/tree/master/templat... • Scheduled Task - https://github.com/serverless/components/tree/master/templates/scheduled-task https://github.com/serverless/components/tree/master/templat... • & More - https://github.com/serverless/components/tree/master/templates https://github.com/serverless/components/tree/master/templat...

imafish 7y ago

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 7y ago
What all services/db/frameworks are you using?
- imafish 7y ago
  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.
ac360 7y ago
Good question. I responded in a separate comment regarding "Why Serverless Components?"

davidjnelson 7y ago

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/templates/8-fullstack-application 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-first-look/ https://www.jeremydaly.com/aurora-serverless-data-api-a-firs...

jwilliams 7y ago
What makes DynamoDB a bad choice for a web app? Seems to be where it excels.
- davidjnelson 7y ago
  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/developerguide/SQLtoNoSQL.Indexes.html 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-you-actually-using-nosql-for.html http://highscalability.com/blog/2010/12/6/what-the-heck-are-...
  - jwilliams 7y ago
    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

Fredej 7y ago

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 7y ago
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
- pdelgallego 7y ago
  >> if you'd rather define the infrastructure side as code vs YAML Or AWS CDK https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/
- squirrelicus 7y ago
  > arbitrary scale If you have arbitrary funds. Point is serverless costs more per unit deliverable
  - johnday 7y ago
    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 7y ago
      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 7y ago

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.

skywhopper 7y ago

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 7y ago
"Complexity is inevitable" is a self-fulfilling prophecy.
- skywhopper 7y ago
  I think you misread what I wrote.
  - ac360 7y ago
    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.
jedberg 7y ago
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.

deleted 7y ago

[deleted]

ernsheong 7y ago

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

stunt 7y ago

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 7y ago
Serverless Components will really help here. Please stay tuned.