Dawson – A Serverless Web Framework for Node.js on AWS(dawson.sh)
dawson.sh
Dawson – A Serverless Web Framework for Node.js on AWS
https://dawson.sh/
90 comments
So here's the thing - they all need enough IAM privileges that, effectively, a malicious script could get -any other access it wanted-.
That is, to be able to function these things need stuff like CreateRole, CreatePolicy, and the equivalent assignment actions (as your functions need a role and policy to execute under).
The AWS policy descriptors are not sufficiently robust to allow the creation of roles/policies that, themselves, only have certain policies/rules attached to them. That is, you either have the ability to create a policy of anything, or you do not have the ability to create a policy, period. Same with role creation.
Because of this, having the necessary permissions the framework needs to do what it says on the tin necessarily means it also can give itself -any other permission-. You can't give it the ability to create and assign policies, but prevent it from accessing, say, EC2 instances, because the role the framework operates under can create a policy for all EC2 actions, for all resources, and assign it to its own role.
So while, sure, it would be nice to enumerate just the permissions it actually needs, and what's going on behind the scenes, just so the user knows exactly what is going on, that set of permissions is still effectively administrator access. There's no security benefit.
That is, to be able to function these things need stuff like CreateRole, CreatePolicy, and the equivalent assignment actions (as your functions need a role and policy to execute under).
The AWS policy descriptors are not sufficiently robust to allow the creation of roles/policies that, themselves, only have certain policies/rules attached to them. That is, you either have the ability to create a policy of anything, or you do not have the ability to create a policy, period. Same with role creation.
Because of this, having the necessary permissions the framework needs to do what it says on the tin necessarily means it also can give itself -any other permission-. You can't give it the ability to create and assign policies, but prevent it from accessing, say, EC2 instances, because the role the framework operates under can create a policy for all EC2 actions, for all resources, and assign it to its own role.
So while, sure, it would be nice to enumerate just the permissions it actually needs, and what's going on behind the scenes, just so the user knows exactly what is going on, that set of permissions is still effectively administrator access. There's no security benefit.
AWS policy descriptors are certainly robust enough to handle something like this. These frameworks are built for hackathon type projects where you are just using a personal AWS account and you don't care about fiddling with permissions. Try getting access to an Administrator user/role at a big company.
To back up my first point, the framework owner could easily instruct users to set up a temporary user/role that creates the initial function roles/policies as one-time setup. Then a user/role with only the service-level permissions (Lambda etc.) could manage all the actual resources.
The devs who build these frameworks want them to be super simple to use, otherwise they won't retain users!
To back up my first point, the framework owner could easily instruct users to set up a temporary user/role that creates the initial function roles/policies as one-time setup. Then a user/role with only the service-level permissions (Lambda etc.) could manage all the actual resources.
The devs who build these frameworks want them to be super simple to use, otherwise they won't retain users!
AWS policy descriptors actually aren't, that I've seen anyway (I'd invite you to provide a counter example though; I'd -love- to see it, because it's something I'd definitely use). In IAM, you have an action, and a resource. I can create a user that has access to CreateRole and CreatePolicy, but I can't limit what kind of policy that user can create. There's no way to say "This person can only create a policy that involves the dynamodb:, lambda: actions, and no others", for instance. They either have access to create any policy, or they can't create any.
And to your first point, it's not just being super simple though; fundamentally you have to have that admin access to be able to deploy initially.
After that, sure, provided you make no changes to the policies, the framework could theoretically diff the policies with just the iam:Get* actions applied, ensure they're the same, and deploy without touching it. But you get into weird situations where you decide "oh, this function now needs access to Dynamo, so let me modify the policy for the role the lambda is executing under", and now you have to have admin credentials again. Any new resources in AWS you want access to require you to have the iam:PutRolePolicy action, which, given you already created it and attached it, is again equivalent to admin rights, and the ability to do anything.
And to your first point, it's not just being super simple though; fundamentally you have to have that admin access to be able to deploy initially.
After that, sure, provided you make no changes to the policies, the framework could theoretically diff the policies with just the iam:Get* actions applied, ensure they're the same, and deploy without touching it. But you get into weird situations where you decide "oh, this function now needs access to Dynamo, so let me modify the policy for the role the lambda is executing under", and now you have to have admin credentials again. Any new resources in AWS you want access to require you to have the iam:PutRolePolicy action, which, given you already created it and attached it, is again equivalent to admin rights, and the ability to do anything.
Sure, I agree with you and with most of the replies here.
dawson will soon switch to using an AWS CloudFormation Service Role, which allows us to require users to grant fine-grained permissions. We will then provide a copy-pasteable Policy for users to set, and update the documentation accordingly.
Currently, since CloudFormations runs with the CLI user's AWS Credentials, such user needs to be granted the permission to do every action, including, for example, managing DynamoDB Tables, S3 Buckets etc...
Also, imagine you're adding an S3 Bucket as a custom resource to your app. dawson will create such S3 Bucket using CloudFormation; CloudFormation needs to be run by a user with S3::CreateBucket permission. This applies for each resource managed by dawson/CloudFormation.
Again, thanks for your valuable inputs and feedbacks!
~ The maintainers,
dawson will soon switch to using an AWS CloudFormation Service Role, which allows us to require users to grant fine-grained permissions. We will then provide a copy-pasteable Policy for users to set, and update the documentation accordingly.
Currently, since CloudFormations runs with the CLI user's AWS Credentials, such user needs to be granted the permission to do every action, including, for example, managing DynamoDB Tables, S3 Buckets etc...
Also, imagine you're adding an S3 Bucket as a custom resource to your app. dawson will create such S3 Bucket using CloudFormation; CloudFormation needs to be run by a user with S3::CreateBucket permission. This applies for each resource managed by dawson/CloudFormation.
Again, thanks for your valuable inputs and feedbacks!
~ The maintainers,
Just a clarification:
NONE of your App's code will run using such "AdministratorAccess" policies. Each function will run in its own iam:Role with limited permissions defined by the developer.
The AdministratorAccess is currently required only for the CLI but, as said in my previous comment, we'll eventually move to using a Service Role and providing a more restrictive policy.
NONE of your App's code will run using such "AdministratorAccess" policies. Each function will run in its own iam:Role with limited permissions defined by the developer.
The AdministratorAccess is currently required only for the CLI but, as said in my previous comment, we'll eventually move to using a Service Role and providing a more restrictive policy.
Delving into the intricacies of IAM policies can take up a LOT of room on a tutorial or blog post. Whenever I post an AWS tutorial, I usually say to pick the policy that gives '*' access to that particular service, but with a strong disclaimer that this is not for production usage, and to narrow down the permissions accordingly.
EDIT: Not global admin privileges, just full read/write to whatever AWS service I am basing the tutorial on.
There are a lot of good IAM policy setting tutorials out there that I usually point them to.
EDIT: Not global admin privileges, just full read/write to whatever AWS service I am basing the tutorial on.
There are a lot of good IAM policy setting tutorials out there that I usually point them to.
Why not just give a copy-pastable policy?
Where the policies are simple, I try and do that, but sometimes there can be complex ARNs etc. that will take too many words to try and explain, or might distract from the pace of the tutorial itself.
It is actually quicker to point to one of the built in or pre-made AWS policies, which are usually fairly generic.
It is actually quicker to point to one of the built in or pre-made AWS policies, which are usually fairly generic.
Links to such tutorials would be greatly appreciated!
Did you mean IAM tutorials? A Google search on "AWS IAM Tutorials" should show you a lot of them, but some that I have pointed to myself are:
http://tom.meinlschmidt.org/2014/06/12/aws-s3-iam-user-polic...
http://mikeferrier.com/2011/10/27/granting-access-to-a-singl...
If you mean some of my AWS tutorials, a couple are:
https://hackernoon.com/building-a-face-recognition-web-app-i...
https://hackernoon.com/building-an-iot-dashboard-using-the-o...
http://tom.meinlschmidt.org/2014/06/12/aws-s3-iam-user-polic...
http://mikeferrier.com/2011/10/27/granting-access-to-a-singl...
If you mean some of my AWS tutorials, a couple are:
https://hackernoon.com/building-a-face-recognition-web-app-i...
https://hackernoon.com/building-an-iot-dashboard-using-the-o...
Definitely not more convenient, however if they're going to give a getting started guide that provides quick instructions, they should also pair it with a more detailed explanation of the permissions required.
Speaking from experience, the developers themselves probably don't know off hand. Its one of those things where they probably selected AdministratorAccess permissions with the plan to later take inventory of the actual permissions used, but never ended up doing the second step. If they want people to think their framework is polished, that second step is necessary.
Speaking from experience, the developers themselves probably don't know off hand. Its one of those things where they probably selected AdministratorAccess permissions with the plan to later take inventory of the actual permissions used, but never ended up doing the second step. If they want people to think their framework is polished, that second step is necessary.
Yes, I think you can do much better with IAM. Experienced AWS users will not follow such a suggestion, as I suppose that doc is meant to provide a quickstart for beginners.
It's not more convenient to select the correct privileges. It is certainly a good idea, but for something where you want to get started quickly, just giving full access is much easier. However, I think whereever this is done in a tutorial, there should be a big disclaimer with a link on how to set permissions correctly.
That is the point. It is a terrible idea to provide full administrative privileges to something you are testing. I.e, it does not need to remove EC2 instances so it is a bad idea granting it against you AWS account.
If the tutorial provides a policy ready to copy & paste with all the required privileges, you will be able to customise it better or just using it as it is.
If the tutorial provides a policy ready to copy & paste with all the required privileges, you will be able to customise it better or just using it as it is.
Not sure why one would decide on using a framework because it is integrated with a few vendors that are popular at the moment. There is significant lock-in, and just because it is open source does not make it free. Lots of companies right now release client libraries that work only with their own remote server under a liberal license, giving the illusion of freedom.
Just for comparison, Amazon sees what is going on here -- explosion of 3rd party management frameworks for API Gateway & Lambda -- and wants to avoid fragmentation.
They're working on a thing called SAM which is built on CloudFormation: https://github.com/awslabs/serverless-application-model
More analysis here, which basically notes that SAM is more declarative in nature, and will likely push 3rd party frameworks to be more cross-platform and/or application-centric in focus: https://techbeacon.com/aws-open-sources-serverless-model-wha...
They're working on a thing called SAM which is built on CloudFormation: https://github.com/awslabs/serverless-application-model
More analysis here, which basically notes that SAM is more declarative in nature, and will likely push 3rd party frameworks to be more cross-platform and/or application-centric in focus: https://techbeacon.com/aws-open-sources-serverless-model-wha...
Having started with Apex (http://apex.run/), used Serverless (https://serverless.com/) and tried to work with SAM, I find the SAM is not nearly as easy to use or documented well enough (compared to Serverless) to be useful. On top of that, SAM feels more like a method of using CloudFormation to deploy Lambda Functions and setup API Gateway which means a lot steeper learning curve for people getting into Lambda.
After reInvent, I was pretty excited about SAM because it seemed like a perfect system to integrate with the Code Build/Pipeline tools, but after spending a week on it and not getting anywhere, I couldn't really recommend it to anyone.
After reInvent, I was pretty excited about SAM because it seemed like a perfect system to integrate with the Code Build/Pipeline tools, but after spending a week on it and not getting anywhere, I couldn't really recommend it to anyone.
I'd actually compare it more closely with Chalice. SAM is essentially an extension to Cloudformations, whereas Chalice is the equivalent to Serverless (but in Python, and not nearly as mature). https://github.com/awslabs/chalice
I wish "serverless" was instead called "daemonless" or "function as a service / faas". Too late, I know, but "serverless" is just not what's going on. It seems more appropriate as a term for apps that run locally (even in a browser) without backend dependencies.
Agreed. There is precedence for reclaiming abused terminology, like how 'isomorphic' javascript has become 'universal' javascript (though I'm not a big fan of that name either).
Either way, it's a confusing term for the uninitiated and sort of presumes that only the web-dev world exists (because as you say, serverless already has a meaningful definition in the computing world)
Either way, it's a confusing term for the uninitiated and sort of presumes that only the web-dev world exists (because as you say, serverless already has a meaningful definition in the computing world)
Much like "literally", I think it's too late to save it.
This looks neat.
I am new to the whole serverless concept, can someone explain how it works? Let's say I have to do some processing on the server (schedule some cron jobs, generate a PDF or send an email), how do I go about doing that? Do I use AWS Lambda for that?
I am new to the whole serverless concept, can someone explain how it works? Let's say I have to do some processing on the server (schedule some cron jobs, generate a PDF or send an email), how do I go about doing that? Do I use AWS Lambda for that?
Spoiler alert: serverless is made of servers.
But seriously what they mean is that you rent an allotted amount of resources on a server farm to run your application for a short period of time, and then the resources are freed again. Not all applications will fit this environment, such as any embedded databases, persistent connections, and so on.
But seriously what they mean is that you rent an allotted amount of resources on a server farm to run your application for a short period of time, and then the resources are freed again. Not all applications will fit this environment, such as any embedded databases, persistent connections, and so on.
I never understood the naming for this trend. It's misleading at best.
I think it's that people assumed (as I did) that everyone would say, "Well, of course, there's not "no servers", because that would be like saying "computerless" or "processorless", but it is practical to say serverless and mean that you don't have to provision, administer, scale, or retire servers, nor do you have to pay for persistent compute resources rather than simply execution"
But that's a mouthful, so "serverless" seems to fit the bill outside of what feels a bit like pedantry.
But that's a mouthful, so "serverless" seems to fit the bill outside of what feels a bit like pedantry.
> mean that you don't have to provision, administer, scale, or retire servers, nor do you have to pay for persistent compute resources rather than simply execution
Given all the work this appears to save one, there's a curious explosion of "serverless" articles, frameworks, APIs, 'practices', crash-courses, workshops, talks .. ah well, par for the course with anything tech that gains a catchy moniker.
(Perhaps that's why FP doesn't take off quite as much, "Monads" should have been called "Promises" 30 years ago, and Peano Numbers "numberless maths"!)
Given all the work this appears to save one, there's a curious explosion of "serverless" articles, frameworks, APIs, 'practices', crash-courses, workshops, talks .. ah well, par for the course with anything tech that gains a catchy moniker.
(Perhaps that's why FP doesn't take off quite as much, "Monads" should have been called "Promises" 30 years ago, and Peano Numbers "numberless maths"!)
I think "nanoservices" would have been a better name.
nanoservices isn't specific enough. serverless has great meaning to initiated web developers. i for one know exactly what they mean by that and always did, whereas nanoservices, to me at least, could mean all sorts of things.
Think of it as serverless pricing model.
I hadn't heard the term before, but these pages have good explanations:
https://en.m.wikipedia.org/wiki/Serverless_computing
https://aws.amazon.com/lambda/
"Run code without provisioning or managing servers [...] pay only for the time you consume"
Makes sense, but based on the name, I initially expected to see a framework that lets you spin up an app without writing any backend code, perhaps like using Firebase but more framework and less service. Then I thought there are even more ways to remove the server.
Maybe there should be multiple levels of "serverless". Type 0 serverless is an html file. Type 1 serverless is a static web page. Type 2 serverless is a dynamic app with a backend service; no writing backend code. Type 3 serverless is a dynamic app plus backend code with a backend management service; no provisioning or managing backend instances.
:P
https://en.m.wikipedia.org/wiki/Serverless_computing
https://aws.amazon.com/lambda/
"Run code without provisioning or managing servers [...] pay only for the time you consume"
Makes sense, but based on the name, I initially expected to see a framework that lets you spin up an app without writing any backend code, perhaps like using Firebase but more framework and less service. Then I thought there are even more ways to remove the server.
Maybe there should be multiple levels of "serverless". Type 0 serverless is an html file. Type 1 serverless is a static web page. Type 2 serverless is a dynamic app with a backend service; no writing backend code. Type 3 serverless is a dynamic app plus backend code with a backend management service; no provisioning or managing backend instances.
:P
Yea you can totally use Lambda for that.
For example you can schedule triggers in Cloudwatch that runs a lambda at intervals to do whatever you need, for example generate a pdf and put it on s3 where you or your users can access it directly.
+1 for CloudWatch scheduled triggers. We used to have a few EC2 worker instances running cron jobs, but since switching to CW scheduled triggers and Lambda, have managed to save a bunch of $$$ on running instances that were doing menial work.
Sure. I've been working professionally with it since shortly after the API Gateway was made available in 2015, and am actually giving a couple of talks on it later this year, so I may be able to give a decently thorough, abbreviated discussion of it, at least in the AWS world.
Essentially, the motivation is to abstract away from caring about the underlying operating system and virtual machine. That is, in the same way that a VM attempts to abstract away from the underlying hardware (so that you, the system operator, need not care about it), serverless attempts to abstract away from the underlying VM and operating system. You the developer shouldn't care about that; you should just care about your code.
So how is that achieved? Well, in AWS, Lambda is a key portion of it. They are small units of execution, defined by arguments in, arguments out, and side effects (same as a function in any language). They have access to a set amount of cpu/memory resources, as well as a bit of hard disk scratch space (note: this space is -not- guaranteed to exist across function invocations; any state you wish to persist between functions must be stored in another services, such as RDS, Dynamo, S3, etc). So you can certainly create a function that, when called, executes some bit of functionality (based on the input, or not, as appropriate).
What then matters is how it is called. Per another comment, you can trigger them via Cloudwatch to execute at a scheduled time (so perfect for cron jobs). You can also cause them to trigger based on certain events in AWS (such as S3 uploads; whenever a file lands in S3, spin up a lambda to process it in some way). But more than that, you can stick an HTTP(S) endpoint in front of them to create a RESTful API. You can do this via the AWS API Gateway. You map how the HTTP request gets passed into the lambda, and then your code can process it whenever the HTTP(S) endpoint is hit.
So with this you effectively have a REST API that will scale predictably. There is cost associated with it (and you have to evaluate whether the cost makes sense; it may not if you have already invested in sysops style resources, or if your load is so high that the Lambda + API Gateway cost is prohibitive compared with running equivalent EC2 instances), but that cost scales with use. And there are a few other caveats as well to learn about and be aware of. But if you then rely on other AWS services for things like data storage, messaging, etc (including email sending; have a look at AWS SES) you can create an entire backend without any servers that you, personally, have to maintain or care about.
'Serverless' frameworks tend to focus on the Lambda + API Gateway integration, to provide you with a developer environment that you can run locally, and then with a single command deploy to AWS, getting both your function and your API in place. They generally have no knowledge of other related infrastructure (which you will likely need, though you can likely configure just once and be done with it; unlike a lambda, you're not changing it frequently)
Essentially, the motivation is to abstract away from caring about the underlying operating system and virtual machine. That is, in the same way that a VM attempts to abstract away from the underlying hardware (so that you, the system operator, need not care about it), serverless attempts to abstract away from the underlying VM and operating system. You the developer shouldn't care about that; you should just care about your code.
So how is that achieved? Well, in AWS, Lambda is a key portion of it. They are small units of execution, defined by arguments in, arguments out, and side effects (same as a function in any language). They have access to a set amount of cpu/memory resources, as well as a bit of hard disk scratch space (note: this space is -not- guaranteed to exist across function invocations; any state you wish to persist between functions must be stored in another services, such as RDS, Dynamo, S3, etc). So you can certainly create a function that, when called, executes some bit of functionality (based on the input, or not, as appropriate).
What then matters is how it is called. Per another comment, you can trigger them via Cloudwatch to execute at a scheduled time (so perfect for cron jobs). You can also cause them to trigger based on certain events in AWS (such as S3 uploads; whenever a file lands in S3, spin up a lambda to process it in some way). But more than that, you can stick an HTTP(S) endpoint in front of them to create a RESTful API. You can do this via the AWS API Gateway. You map how the HTTP request gets passed into the lambda, and then your code can process it whenever the HTTP(S) endpoint is hit.
So with this you effectively have a REST API that will scale predictably. There is cost associated with it (and you have to evaluate whether the cost makes sense; it may not if you have already invested in sysops style resources, or if your load is so high that the Lambda + API Gateway cost is prohibitive compared with running equivalent EC2 instances), but that cost scales with use. And there are a few other caveats as well to learn about and be aware of. But if you then rely on other AWS services for things like data storage, messaging, etc (including email sending; have a look at AWS SES) you can create an entire backend without any servers that you, personally, have to maintain or care about.
'Serverless' frameworks tend to focus on the Lambda + API Gateway integration, to provide you with a developer environment that you can run locally, and then with a single command deploy to AWS, getting both your function and your API in place. They generally have no knowledge of other related infrastructure (which you will likely need, though you can likely configure just once and be done with it; unlike a lambda, you're not changing it frequently)
[deleted]
I am a big fan of the "serverless" approach. If you structure your code in the right way, it is still easy to move away from it and use your own infrastructure if need be anyway. For getting off the ground for MVPs and such without having to deal with hosting and deployment too much and only pay by usage, it's pretty great!
This looks interesting but if you like it I encourage you to check out https://serverless.com/
It has a very active community, is extremely powerful (because for AWS it is built on AWS CloudFormation), and very robust. I wrote by own framework and eventually moved to Serverless.
Not to mention in supports other languages (although the Python documentation is lacking... Java has good documentation though) and other providers (Azure & Google).
Edit:
For a quick comparison:
Dawson - 4 contributors on Github, and almost 650 commits
Serverless - Over 200, and almost 6000 commits
I don't want to be the type of person that discourages innovation. Sometimes you need to innovate because the current state of affairs is broken. But in this case Serverless Framework is not broken... it is very very good.
Footnote: I'm not a contributor but I am a long time user. I don't have any personal stake in the Serverless project.
It has a very active community, is extremely powerful (because for AWS it is built on AWS CloudFormation), and very robust. I wrote by own framework and eventually moved to Serverless.
Not to mention in supports other languages (although the Python documentation is lacking... Java has good documentation though) and other providers (Azure & Google).
Edit:
For a quick comparison:
Dawson - 4 contributors on Github, and almost 650 commits
Serverless - Over 200, and almost 6000 commits
I don't want to be the type of person that discourages innovation. Sometimes you need to innovate because the current state of affairs is broken. But in this case Serverless Framework is not broken... it is very very good.
Footnote: I'm not a contributor but I am a long time user. I don't have any personal stake in the Serverless project.
We're not comparing dawson's maturity to Serverless, nor we are financially backed as they are, so comparing those numbers is pointless.
Anyway, if someone's interested in diving in deeper, instead of just counting our stars, this deck might be a good resource: http://slides.com/lanzone31/dawson20170303
A few corrections to your comment:
>is extremely powerful (because for AWS it is built on AWS CloudFormation)
dawson is also built entirely upon CloudFormation
>Not to mention in supports other languages
we'll merge python in master in a few weeks
Anyway, if someone's interested in diving in deeper, instead of just counting our stars, this deck might be a good resource: http://slides.com/lanzone31/dawson20170303
A few corrections to your comment:
>is extremely powerful (because for AWS it is built on AWS CloudFormation)
dawson is also built entirely upon CloudFormation
>Not to mention in supports other languages
we'll merge python in master in a few weeks
That slide deck is very helpful.
I wasn't counting stars, I was counting contributions. You have some catching up to do.
For what it's worth I tried to weight my post because I think the project looks pretty good and I don't want to discount that achievement. Just Serverless is mature and used but a lot of people in production / live environments you have a lot of work to catch up.
One place where you can potentially not just meet Serverless but win is getting started documentation.
And I don't mean just hello world.
For example: how do I create and use a DynamoDB database in your Framework? Serverless certainly supports that but it is a learning curve and trips up new users.
Another concern I have is the edge cases. Stuff Serverless isn't even good at. For example:
- CloudFormation has a 200 resource limit. How do you deal with that. Severless hasn't solved it yet.
- How do Lambda functions get versioned? Serverless does this very well.
- How do I hook up a lambda to a SNS stream. Serverless does this really well too but the documentation is poor.
One think Serverless does very well is letting you set up various Lambda triggers without having to know much of the internals.
I wasn't counting stars, I was counting contributions. You have some catching up to do.
For what it's worth I tried to weight my post because I think the project looks pretty good and I don't want to discount that achievement. Just Serverless is mature and used but a lot of people in production / live environments you have a lot of work to catch up.
One place where you can potentially not just meet Serverless but win is getting started documentation.
And I don't mean just hello world.
For example: how do I create and use a DynamoDB database in your Framework? Serverless certainly supports that but it is a learning curve and trips up new users.
Another concern I have is the edge cases. Stuff Serverless isn't even good at. For example:
- CloudFormation has a 200 resource limit. How do you deal with that. Severless hasn't solved it yet.
- How do Lambda functions get versioned? Serverless does this very well.
- How do I hook up a lambda to a SNS stream. Serverless does this really well too but the documentation is poor.
One think Serverless does very well is letting you set up various Lambda triggers without having to know much of the internals.
> But in this case Serverless Framework is not broken... it is very very good.
Just as a caveat, though, they've had a lot of breaking changes in the last few releases. Each release, it does feel broken for a while.
Just as a caveat, though, they've had a lot of breaking changes in the last few releases. Each release, it does feel broken for a while.
Release v.1.0 was a complete breaking change (even from release candidates... the RCs were nothing like the final product). But I haven't experience that issue with minor version updates. For the most part they have been pretty smooth. A few of them I had to go in and manually fix some things in the AWS console but it hasn't been too bad.
Dawson looks way simpler. That's clearly it's selling point. Dawson looks like what it should be for the modern javascript developer. They nailed the API whereas Serverless is more daunting. Perhaps it's time for a new contender to iterate its way to the top spot.
Are there any unopinionated serverless frameworks that allow you to deploy to multiple clouds?
Check out Hasura[1]. Unopinionated: yes, serverless: not really. I think serverless essentially means you want to run code on the server but not really worry about server provisioning, maintenance etc.
Hasura[1] is a PaaS (based on Docker+Kubernetes) + BaaS. There are some built-in backend components (like auth and a data service). You can also write any code and deploy (via docker images) to multiple clouds.
Disclaimer: I work at Hasura.
[1]: https://hasura.io
Hasura[1] is a PaaS (based on Docker+Kubernetes) + BaaS. There are some built-in backend components (like auth and a data service). You can also write any code and deploy (via docker images) to multiple clouds.
Disclaimer: I work at Hasura.
[1]: https://hasura.io
The Serverless Framework now supports multiple serverless platforms (AWS Lambda, OpenWhisk, Azure Functions and Google Cloud Functions).
Depends on what you consider "unopinionated"...
It handles all the deployment lifecycle across all providers but won't abstract away all the implementation details. It is not possible to "lift & shift" from one provider to another without making some changes.
Depends on what you consider "unopinionated"...
It handles all the deployment lifecycle across all providers but won't abstract away all the implementation details. It is not possible to "lift & shift" from one provider to another without making some changes.
By unopinionated I simply meant that it allows you to deploy to multiple clouds. As someone that hasn't read up on this stuff, can you explain to me the implementation differences that would prevent you from 'lifting and shifting'?
It can definitely do this, it supports AWS out of the box and has "provider plugins" for everyone else. The workflow for deploying and managing applications is the same across all providers.
At the implementation level, the providers do differ. From small things (like the function interface) to bigger things (like event services).
I did a talk on this a while ago: https://speakerdeck.com/jthomas/taming-serverless-dragons-mu... https://serverless.london/meetup/feb2017/serverless-framewor...
At the implementation level, the providers do differ. From small things (like the function interface) to bigger things (like event services).
I did a talk on this a while ago: https://speakerdeck.com/jthomas/taming-serverless-dragons-mu... https://serverless.london/meetup/feb2017/serverless-framewor...
Looks great! Wonder if we can port this to be used with Google Cloud Functions.
What specific "sugar" and features would dawson add to Functions? Google Functions is already super easy to get up and running and integrates with git/GitHub. The only features I currently see as missing in Google Functions are:
1.) Ability to provide a custom domain for http triggers
2.) Scheduling/cron to trigger functions. E.G. trigger function foo() every 22 minutes. Trigger function bar() on April 10th 09:24:23.
1.) Ability to provide a custom domain for http triggers
2.) Scheduling/cron to trigger functions. E.G. trigger function foo() every 22 minutes. Trigger function bar() on April 10th 09:24:23.
I don't understand why custom domains wouldn't be an option straight out of the gate?
Even if I personally hate the word "serverless" because at the end everything is based on EC2 instances which are servers, it's made with love in Milan so.. Big up guys!
Well, everything is still based on CPU registers, but I guess everybody here prefers the abstraction provided by C, Python, Java, Ruby, JavaScript, or Go.
Nobody calls JavaScript "computerless" or "codeless".
Because the abstraction already has a name: high level language.
That's not the reason why people don't call JavaScript "computerless" or "codeless" though.
I think serverless is a bit sensationalistic and ultimately unhelpful of a name. I don't blame new projects for adopting the term since it's already in the public awareness, but I can't say I'm a fan.
I think serverless is a bit sensationalistic and ultimately unhelpful of a name. I don't blame new projects for adopting the term since it's already in the public awareness, but I can't say I'm a fan.
It's a nice spin of cloud providers to use "serverless" as a euphemism for "runs only on our proprietary platform and is virtually impossible to migrate away from".
It really depends on how you use it. If you structure your code well and you mostly use it to build RESTful APIs (which is what dawson is meant for), you will be able to easily migrate it to any other system. Especially if you use Lambda + RDS, you won't need too much work to re-deploy the same database and functions elsewhere (either another serverless vendor or your own infrastructure).
I saw the first talk from its author in Milan, the feature I like most is that it emulates AWS Lambda locally with a Docker.
Got a video link?
None that I know and sadly I missed the event but the slides are at http://slides.com/lanzone31/dawson20170303#/
Here's the meetup event link -> https://www.meetup.com/Serverless-Italy/events/237189798/
(no videos though)
(no videos though)
What is the use case for this type of setup?
Mostly serverless web applications in JS (and Python coming soon!), served with CloudFront (static S3 files) and API Gateway (dynamic APIs).
Putting AWS credentials as plaintext in environment variables does not seem like the best security practice.
It's fine because it's an ephemeral value in a docker container, put there during provisioning by ansible where it was pulled from a properly encrypted vault. Kubernetes can totally manage that for you so you can finally go serverless.
How is this differentiated from serverless.com ?
If this works:
# run your app locally
$ dawson dev
Is there an equivalent for the Python runtime? When I started using Lambda there wasnt, but I haven't looked at whether that changed since.
We'll ship full first-class support for the python runtime (including the dev server) in dawson in a few weeks.
Also if you don't want to install serverless-offline there is "serverless invoke local" built-in.
From what I saw in the documentation a difference seems to be
> You should be able to start using dawson without creating any configuration file
The configuration obviously exists. It is scattered around as
* environment variables for AWS secrets
* the api property of functions for defining path, params, etc [1]
* a package.json for everything else, maybe not necessary for a minimal deployment without db [2]
[1] https://dawson.sh/docs.html#4-function-configuration
[2] https://dawson.sh/docs.html#5-application-configuration
> You should be able to start using dawson without creating any configuration file
The configuration obviously exists. It is scattered around as
* environment variables for AWS secrets
* the api property of functions for defining path, params, etc [1]
* a package.json for everything else, maybe not necessary for a minimal deployment without db [2]
[1] https://dawson.sh/docs.html#4-function-configuration
[2] https://dawson.sh/docs.html#5-application-configuration
Thanks. The main goal here is to cover a couple of use cases without needing a single configuration line (aside from the app name, which is always required).
It all looks interesting, but I still don't see the advantage over pure Lambda? I get that it is a one command deployment, but really at the end of the day, does it save much time over zipping up my Node working folder and uploading to Lambda via the console? (In terms of installing extra framework stuff on my dev PC)
- it should make easier to replicate Lambdas to different AWS Regions or to use different stages (development, testing, production, ...)
- allows running of lambda functions locally, which significantly speeds up development
- provides you with a full production-ready environment (CloudFront + S3 + API Gateway + Lambda + ...) out of the box
- allows running of lambda functions locally, which significantly speeds up development
- provides you with a full production-ready environment (CloudFront + S3 + API Gateway + Lambda + ...) out of the box
What if you want to automate a build/deployment?
Ok, I see the logic if you want to set up some sort of continuous automation pipeline. From reading the documentation, it looks like this sets up a whole suite of services for a deployment, including CloudFront etc.? Anyone got a sample of a real world deployment using this framework? Any nasty hidden surprises in AWS billing that you've experienced by doing so? (Not snarky - asking out of actual interest)
> Any nasty hidden surprises in AWS billing that you've experienced by doing so?
- just a few cents of S3 Storage (if you're out of the free tier) to host versioned Lambda deployment packages - which will expire automatically anyway.
- in production, by default, dawson creates an AWS WAF (Web Application Firewall) WebACL which cost ~5$/mo. You can opt out this behavior if you don't need one.
- just a few cents of S3 Storage (if you're out of the free tier) to host versioned Lambda deployment packages - which will expire automatically anyway.
- in production, by default, dawson creates an AWS WAF (Web Application Firewall) WebACL which cost ~5$/mo. You can opt out this behavior if you don't need one.
wake me up when browserless is a thing
I have no idea why you would want to use this instead of running it directly in aws yourself. Maybe the learning curve is less steep but you lock yourself in with a 3rd party framework and if you run into problems you probably will have to learn aws anyway.
From the docs: "search for a Policy named 'AdministratorAccess', click next and confirm".
It would be much more convenient to request only the needed privileges while teaching the user what is the tool doing in the background.