Thanks for sharing. I've just started work on a server-free AWS architecture, but instead of using the AWS API Gateway feeding into Lambda, I'm working on static pages with AWS SDK for Javascript (served from S3) talking directly to Cognito, RDS and S3 with lambda for async processing:
I'm surprised I haven't seen more discussion of SDK for Javascript since it removes a lot of the server requirements. Have you considered using AWS SDK for Javascript, or do you explicitly want a REST API as an abstraction layer? The API certainly provides some advantages if you ever want to migrate off AWS. In my case, the lambda functions get invoked by particular events on RDS, S3, or manual/browser triggers instead of AWS API Gateway invocation.
You can use Amazon's IAM Web Identity Federation and grant access to resources only for users that have signed in with Google, Facebook etc. with approved user identifiers.
So basically, instead of embedding the AWS access keys in HTML, you use AWS.config.credentials = new AWS.WebIdentityCredentials(...) with the OAuth access tokens you get from Google or Facebook.
For S3, which permits IAM authorisation, there's AWS Cognito as a role-based token vending machine.
For RDS, I suspect DocSavage is likely to soon learn that browsers don't speak RDBMS wire protocols; they'll need a CRUD wrapper at least. The canonical AWS "serverless" solution would be API Gateway + Lambda.
It just happened :/ I actually was planning on DynamoDB until an architect at AWS Loft convinced me last Friday that RDS was easier for my modeling. Won't work, though, if only RDS management is exposed through the Javascript and not the actual RDBMS wire protocols. Back to DynamoDB.
Unfortunately my client is closely coupled to a venture I'm doing on the side. I won't be open sourcing it. If it's just static web pages you need without mutable data, you can do that directly off Amazon S3. There are lots of blogs and open source projects for that:
If you sprinkle in AWS SDK for Javascript in the browser, you can handle mutations directly into various persistence services without needing EC2. I'm still very early in my exploration of this approach so I was hoping to see some case study myself. If there's no direct way to invoke lambda from a service event (e.g., an RDS mutation), you could invoke it from the client after returning from the RDS request.
I’m almost at a point where I think static websites are a solved problem. Compile your website with whatever (Jekyll, Octopress, etc), save it to GitHub for good measure, and push it to an S3 bucket with CloudFront og CloudFlare in front of it.
You can always find somewhere else to host your stuff, but I’d say I’m pretty happy with a deployment workflow that’s basically
bundle exec jekyll build
s3_website push
Aaand you’re done. And you can even roll those two into a pre- or post-commit hook.
I like this approach. I'm all about removing server requirements!
For now, I favor the traditional REST API layer because REST APIs are well understood. They also may require less effort to access via IOT devices and expose publicly for other developers to hack with.
Overall, I'm interested in the best. If you have thoughts on how to incorporate this approach into JAWS for optimal effect, I'm definitely paying attention.
As far as JAWS goes, the next step is to be able to define your API in JSON via Swagger, and then import it into AWS API Gateway to instantly create/update your API. This should dramatically reduce development time and make it much easier for everyone building their JAWS REST API :)
I would view your approach as a complimentary architecture. At some point, I'll want to provide developer APIs that can be throttled, measured, etc, and the API Gateway is a perfect interface for that. But sometimes you'd want client code that directly uses AWS services without the intermediary, particularly since the surface area of all AWS services is massive and generated JAWS REST APIs would likely be smaller, domain-specific interfaces.
I am also experimenting a serverless architecture on top of AWS. Just like you, I tried to directly use S3 + cognito, which is great. The only problem I see is that it is not possible to limit the space used by a bucket and, therefore, it could be used as infinite storage by malicious clients.
I've checked out with AWS people [1] and asked on stackoverflow [2], but it seems not possible yet. They suggested me to use lambda to delete unwanted content after it was uploaded, which surely works, but is a waste of bandwidth and of lambda time. Did you find the same problems? Any other solution?
Beside, it looks like a great approach, but it surely ties you to AWS way more than other approaches.
I've been working on something like this as well and the biggest problem that I have found is that there is a hard limit of 100 S3 buckets per aws account. Which, unfortunately makes it impossible to use S3 in the manner I had intended.
AWS has hard limits, but usually can be easily overcome just by asking to their support. We increased many times the hard limits on EC2 instances and EIP.
> Bucket Limit Increase: You can now increase your Amazon S3 bucket limit per AWS account. All AWS accounts have a default bucket limit of 100 buckets, and starting today you can now request additional buckets by visiting AWS Service Limits.
That's true, but the S3 bucket limit, just like the VPC security group limit, is fixed at 100, even if you are Netflix.
---
Edit: Wow, what a difference a day makes.
look into namespacing your buckets. a bucket is not the same as a table. aws works in massive scale production and can suit all kinds of needs. the good folks at the aws popup loft in SF set me straight on this one
Unfortunately namespacing won't work for us. We need the ability to point a domain name at a bucket. Can't do that with a folder inside a bucket. If I am incorrect on this, it would be great if you could set me straight too.
The last time I checked (and my information is very dated, 5+ years) this was a fairly popular piece of software in the blind community. I also do not know the status of trademark around the term. If you were going to change names, its early days for you now would be the good time to do it.
I agree with you "minimal" risk assessment. However we have all see companies do stupid things. I don't remember off hand if you are REQUIRED to defend a trademark for it to be enforceable.
I'm not affiliated with Amazon, nor do I know anyone over there. I'm a freelancer in Oakland, CA., and my goal is merely to offer some open source code to help people take advantage of emerging tech so that they can build ridiculously cheap and scalable web apps.
You can't put a wordmark on a word like Jaws. These two peices of software are completely different you can't confuse them, they aren't competing, there is no trademark infringement. Its not an issue.
Maybe this (great!) project could be renamed to the Javascript Amazon Web Application Stack and abbreviated to JAWAS... I'm sure there will be no trademark problems with that AT ALL!
Agree. Beautiful stuff! The second problem with the name JAWS is that it's not very SEO friendly - competing with a lot of stuff. My first reaction was to google for some examples using JAWS, but that pulls up a huge variety of things (including the Freedom Scientific software, which is confusing at first). I give +1 for the JSAWS (j-sauce) acronym.
Note that you should be wary of AWS Lambda limits. We blew through them on our first day directing traffic on a system we were testing with Lambda. They were able to increase our limits a few days later, but something to think about before you base your whole stack around it.
AWS introduced API Gateway because they want back-ends being built on AWS Lambda. They will raise the limits, but this is all bleeding-edge tech and they are likely moving forward with caution.
They've already increased it from the originally published concurrent requests per function limit (originally 50, now 100) [1]
We'd like the "Total size of all the deployment packages that can be uploaded per account" increased. Since you have to "require in" (as you put it) all your dependencies with each published function it's plausible to hit that limit pretty quick.
The average node module is 1.6MB [2]. If your functions have 3 dependencies, you're near 5MB. That limits you to ~300 functions. That initially seems like a lot until you realize you may have to start breaking up complex logic into multiple functions to hit time limits. You also might need to maintain multiple versions for backwards compatibility (think v1 endpoints). And if you use Java 8, you're just screwed. That size limit can be hit quick.
It might be possible to write a wrapper function that pulls a larger function from S3. I think you get up to 500mb of /tmp storage per function. Obviously the initial startup time would be atrocious but if you have a high enough TPS it wouldn't be hit too often.
I could also see Lambda adding a paid-for option to keep a function "warmed up" at all times.
Great work - looks like a really useful piece to help you quickly get going using the AWS stack and Lambda/JS. The biggest issue I've always found is the extra steps between writing your code and getting it onto a server.
The "no server" movement definitely seems to be gathering steam, with Firebase and Parse on the data side and Lambda (augmented with JAWS and others) on the computation side. Am excited to see what this area will bring, in particular due to the combination of scalable hosting and containerisation.
(Plug - we're working on StackHut (http://www.stackhut.com) in the "no server" space that provides a language-agnostic Lambda-like platform (currently JS/ES6 and Python with Ruby soon) that's powered by Docker and is accessible via JSON-RPC over HTTP. Would love to hear your thoughts on this and the "no server" space in general.)
Thanks so much for looking, sorry that the public APIs didn't work correctly. I've ran a few tests and most work apart from the `pdf-tools` demo for converting PDFs - thanks for raising that to our attention (the life of a beta product!). Can I ask what browser you're running?
I'm presuming you're on Sky in the UK? They are currently blocking HTTPS on various CloudFlare endpoints (such as ours!) We're attempting to get this sorted ASAP. Let me know if this isn't the case!
I am on Sky in the UK, looks like it is an ISP issue then. I'll keep an eye on you guys though, I'm a big fan of being able to just run functions on-demand like this. I used to use PiCloud extensively before it was bought out.
I believe to support RDS in Lambda you'll either need to dynamically add the Lambda instance's public IP address to your RDS security group (and remove it once complete) on each run or make the RDS instance open to a large number of AWS IP ranges^1
Hmmm, I'll look into this. Either way, I'm sure Amazon is aware that RDS in Lambdas is a good thing, and they will continue to make this and their other tools easier.
Just added a section in JAWS Optimization on the AWS Pop-Up Loft because it's a tremendous resource and I don't think many people know about it. Since this page is so popular, I'll paste the section in here:
AWS Pop-Up Loft
AWS has an office/loft in downtown San Francisco where you can meet with an AWS engineer for free to discuss your project and your use of AWS services. It's an incredibly valuable resource, but I don't think many people know about it.
All you have to do is schedule a meeting in advance. Meetings can last up to 1 hour and can be scheduled M-F during normal business hours.
Further, their office and loft is also a free co-working space, as long as you are using AWS services. They have some nice couches and desks and it's a great way to network with other developers who use AWS services.
Again, all of this costs nothing. If you're in SF, or traveling there, check it out!
But seriously, there aren't any servers. There is a local development server included, to help you code your web site locally. But, it's not a server you use for production.
Much of my time as a developer is spent deploying/configuring/monitoring/managing/scaling/paying for servers. I'm tired of that. Further, I'm broke. AWS Lambda and on-demand cloud computing in general can reduce and eliminate a lot of that.
Much love for servers, much love for containers, but AWS is putting out technologies that are more efficient. The goal of JAWS is to help everyone take advantage of this new tech.
It's awesome to see this because I've been planning on doing something very similar for a future project. The only major difference between what I was envisioning is that I was still going to have a few EC2 servers to maintain WebSocket connections to the client as I want near-instant responsiveness. Another minor difference is that I was planning on using a static site hosting provider like Netlify to host static content since it's a) cheaper and b) automatically uses a CDN.
But my worry has been on the performance side of Lambda...that near-instant feel is going to be compromised if there's much latency introduced and I still haven't done any performance testing to see how much latency Lambda introduces. Have you done any exploration along these lines? In particular, I'll need to figure out what the consistent overhead is and how often Lambda doesn't reuse previous instances and forces db reconnects and the like.
It's no server because Lambda is not a server like VPS that you get it up and running 24 hours, it's a service that gets a call and runs your function. You don't have a server up it's a function on the backend. It's being called by the JS SDK on the browser, therefore no server, plain static + function calling architecture.
Isn't App Engine no server by the same metric? You could make an autoscaling app engine module with some HTTP handlers and it seems like you have the same thing.
It's "no servers" for the developer in the sense that there is zero infrastructure to manage, configure or deploy. This is popularly known as a "PaaS" or platform as a service, ala Heroku and similar providers.
You're not paying for a server being up for you 24/7, you're not managing a server, you don't worry about what's being provisioned. That's what "no server" means, yes everybody knows there's a server! There's no magic hat tricks! It's just a new trend word now :), say "no server"
the pricing difference is huge too, AWS's PaaS Elastic Beanstalk took away the "server management" part for the most part but this allows a lot of power when you need it and absolutely no costs when you don't.
I've been trying to find a core example of how Jaws works without having to download anything. Could you include an example in your readme of an example API using lambda? Even some pseudocode would help me understand.
The examples are very interesting, as it's not necessarily cheaper, because if you could handle the same 3 million requests per month with a t2.micro for ~$10 per month, Lambda approach would be close to 2x more expensive.
However, the benefit here is that you don't have to provision to peak capacity needs + (some safety fudge factor), thereby having paid for, but idle capacity.
It's a very intriguing proposition for new services where you may not be able to optimize costs as much for fear of losing up time, but I'm sure it makes a lot of financial sense for AWS. Nothing stopping this from being a win/win though.
Here's a problem with cloud economics. People don't compare apples. Essentially, I am not short $10 but I could use some time back in my week.
Getting bogged down in managing servers, or a fleet of instances, or the devops stack to automate a fleet of instances; it's all a time sink with either an actual cost or at the very least an opportunity cost, orders of magnitude beyond that $10/month.
This is especially true for organisations where provisioning an instance requires an epic chain of approvals "because it's a server". Unfortunate but all too common.
Of course if you were planning to become (or already are) a competent devopsy admin then provisioning instances is not necessarily a waste of your time. For everyone else, platform-as-a-service such as Lambda can be an huge win. Sure, there's still a tipping point but it's much greater when time, rather than simply price, is considered.
On the other hand, and contrary to the Amazon-is-scalping-me gripes I hear on HN all too frequently, my experience has consistently been that AWS want you to minimise costs due to design. Every well-run business knows the long-term virtuous cycle of satisfied & continuing customers far outweighs a short-term revenue grab.
ObDisclosure: I am a former AWS architecture manager but do not speak on behalf of my ex-employer.
Is there a way to use a file system-backed storage with this? For example, I would love to create a web frontend for ledger [1]. Ledger only reads text files but for a frontend to be useful it would need to write entries to files.
Really cool... Now we just need longer Lambda execution times (current limit is 60s) and a proper crontab. For a complete auth flow you can also check:
Great experiment here. Lambda has been intriguing me for a while. More and more, as I scope out work for clients, I'm finding bits that could probably be run as Lambda processes instead of requiring an entire EC2 instance. This is kind of like taking a REST interface to a natural extreme.
I was looking into using lambda functions called in response to an S3 event. Specifically, I wanted to create a record in my SQL database after a file is uploaded to S3. Users are uploading directly to S3 using pre-signed requests, so I needed some way to step in and create a database record after they actually perform the upload to S3. S3 supports this via several methods, one of which is the lambda functions, but when looking into lambda functions there was no way to have the code access my SQL database internally, I would have had to make my SQL database open to the world. I didn't find any IAM rules etc to enable lambda functions to access my SQL database resources. I'd be curious to see how this is handled by this JAWS work flow.
I've also needed to have Lambda functions access databases on an RDS instance within a VPC and haven't been able to do so without opening the database up to everyone. Seems like a feature they should think of adding soon.
I'm presently about three quarters done with writing one of these myself; Lamdba plus SQS plus arbitrary functions. I have a different take on deployment, going with CloudFormation. Version updates are something you have to think about quite hard with this sort of system.
The real challenge is how to manage within the 60 second, 1024 thread limits in a sane way, however. You have to approach application decomposition in a much more rigorous way.
If App Engine had some neat AWS features early on, it could have done really well. I think App Engine was one too many hops away from 'mainstream dev', but is probably very close now.
Maybe a cloud platform has to offer everything. So, in the same sense gce was a move from app engine to ec2, they are both converging to the same "anything you want as a service" offer.
Is it really true that Lambdas can take 5 minutes to start up? Doesn't that rule them out as useful for things like running a website (instead of just background jobs)? Or does the article mean 5 minutes from the first time you deploy a new one to the time it's available, but after that new lambdas can be spun up in milliseconds to server each request?
No, that is not true. While AWS Lambda has cold-start issues, they can be mitigated.
While AWS continues to improve Lambda performance (it's still early tech), I've started an "Optimization" section in the wiki, detailing how everyone can get better performance out of JAWS.
Further, JAWS is optimized for AWS Lambda performance.
Great job, grabbed my attention, I really liked this, but I'm doing so great with gulp that if I used this I really would still need to use gulp because of the optimizations, I'm also using S3 and Lambda, but I like the idea of running aws lambda locally before uploading and the "run a server locally" before upload.
Could you share some of your gulp optimizations so that I can incorporate them into the project?
You don't have to share their code if you don't want to, but if you could write down what the gulp tasks are, I could incorporate them into the JAWS Command Line Interface.
I really liked the concept of your project and it's in my bookmarks already. I can share, can you add me in twitter it's ramonck, I'll write down a paper in Medium sharing the details, I already wrote down the concept of a mobile product I did with Gulp and Lambda I'm about to share in Medium as well, I'll also be glad to share the indepth details of the technology, but I think it will be more productive for you and for others to have it in a single spot. Add me there I'll share in the next week or so.
Nice work on the project! Big fan of the graphics also :)
Reminds me of Divshot [0], a heroku-like service for hosting static sites. It's great that you can roll your own site, and don't need a middleman to host for you.
I've got to implement a simple site this week for our customers to be able to upload photos to S3 and then I need an API endpoint to list these photos. JAWS seems like a great solution for this.
this is really cutting edge stuff, great job. Would be event cool to include polymer webcomponents (on client side) , AWS Cognito for authentication along with this.
Jaws already exists as a software project, for the blind.
Perhaps I am exposing ignorance about the needs of the blind community, but it would seem to me that a primarily important piece of software for them could be more confusing to find and update and so on if another piece of software appears with the same name. Maybe you should consider changing the name of your software before it's too late? It's possible that your Jaws may, in the long run, cause considerable confusion for the users of the pre-existing Jaws software.
I'm making a case based on empathy rather than trademark law and so on.
Woohoo! It's the second coming of stored procedures and PL/SQL! Party like it's 1988!
Seriously though, these kinds of architectures come at a cost. The website's claims are either misleading, or the authors haven't understood the problem domain. E.g.:
Each of your API URLs points to one of these Lambda functions. This way, the code for each API Route is completely isolated, enabling you to develop/update/configure/deploy/maintain code for specific API urls at any time without affecting any other part of your application(!!!).
Even if you add more exclamation marks, you'll still end up with front end code depending on the interface exposed by your backend code, meaning you'll have to do versioned rollouts, except you no longer have a single deployable but a zoo of store proce^W^Wlambda functions, with unclear interdependencies and (usually) no proper versioning or tracking.
This might be the right architecture for certain apps, but it's not the easy win/win that's presented here.
I haven't used JAWS, and I don't see where they speak to this question, but I do work on AWS lambda "applications", and typically they're versioned using versioned S3 buckets. It's very easy to continuously "deploy" code artifacts to S3, but only update the revision working on production traffic when you're good and ready. You can also optionally spin up complete duplicates of your infrastructure using the new revision, for exceedingly realistic integration or performance tests.
I'm not really sure what you mean by "tracking," but you can log anything you like from a Lambda function, and include version information in those logs.
My point is that the advertised separation of frontend and backend using stored procedures in your database can be a huge misfeature - it requires a lot of management and rigor to maintain a compatible API interface that allows that kind of architecture. Frankly more than I'd expect from a bunch of JavaScript snippets (where you usually don't have a lot of tooling to support you).
Relying on stored procedures in a hosted database system also means you cannot write locally reproducible, reasonably hermetic tests.
It also (obviously) completely binds you to a single vendor.
In short, it has all the drawbacks this architecture had when it was still Oracle database servers and stored procedures in PL/SQL (and/or the equivalent from MS, IBM, ...). It also has similar benefits (no need to manage a separate server, simpler architecture, often simpler to get things done for novices).
There are good reasons why that architecture largely lost in the market by now, I'd be very careful to make sure this is a good fit for your problem. But of course only you can be the judge of that.
The single deployable server you advocate is a single point of failure.
I'm not talking about a deployable server, I'm talking about a deployable as a unit of deployment, e.g. a war archive. A deployable is a compile time artefact, a single point of failure is a runtime concept. In that sense, saying a deployable was a single point of failure is like saying a line of code is a single point of failure.
Lack of git/versioning integration is pretty key and is one of the downsides of requiring deployment from the browser. We're hacking on something that solves this @ https://stackhut.com.
While I understand the need to give a snappy comment, does this really contribute any value to the discussion? It's obvious that OP means develop apps without dealing with servers. I don't think anyone would imagine that the entire app is running without any servers at all.
https://aws.amazon.com/sdk-for-browser/
I'm surprised I haven't seen more discussion of SDK for Javascript since it removes a lot of the server requirements. Have you considered using AWS SDK for Javascript, or do you explicitly want a REST API as an abstraction layer? The API certainly provides some advantages if you ever want to migrate off AWS. In my case, the lambda functions get invoked by particular events on RDS, S3, or manual/browser triggers instead of AWS API Gateway invocation.