A few weeks ago I created a small framework called lambdaphp[1]. The site https://www.lambdaphp.host/ is hosted on AWS lambda only!
My aim was to host a Wordpress or Laravel site on AWS lambda without paying any monthly hosting charges. I got everything running on it (sessions, fs, request, etc).
Some things are different though, like when you write to a file using file_put_contents, etc it writes to a S3 bucket instead of fs (thanks to PHP's S3 wrapper), or when you create a session, it uses AWS DynamoDB to do that behind the scenes.
I've created some examples like this sign-in example which uses AWS Cognito + AWS lambda to create a login/signup page[2], file uploader, etc[3].
Of course my project was just for my own amusement but I think this can be good for side project where you just want to host something and forget about it.
This is a very neat project. For those folks where this doesn't quite fit and you want the serverless experience checkout OpenFaaS and our PHP template too - https://github.com/openfaas/faashttps://github.com/openfaas/faas-cli#templates we use composer for installing components at build time with Docker (not on your host system directly)
Thank you. Also just want to mention that as per AWS's recent announcement they are going to make Amazon RDS lambda like, i.e. You dont have to pay monthly for your Mysql server but query wise or Cpu consumption wise.
I certainly hope so though I haven't tried it myself. I've managed to get the sessions, routing, fs, etc working just fine without any additional configuration, but of course there will be some quirks during the actual Wordpress installation which I haven't explored yet. Maybe next week I will try it :)
> The Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month.
> The Lambda free tier does not automatically expire at the end of your 12 month AWS Free Tier term, but is available to both existing and new AWS customers indefinitely.
(emphasis added)
That is awesome. Providing you could get your application compatible with lambda. This application may help for WSGI-based (python) applications: https://github.com/Miserlou/Zappa
This would be way more useful if there was an indefinite free tier (or just a smooth bill per usage!) for API gateway. I have seriously considered moving my personal projects to Azure because Functions can be triggered via HTTPS without a $3.50 charge cliff.
> Providing you could get your application compatible with lambda.
I know Erica at iOpipe and like what they are building. OpenFaaS is an alternative that can run on Docker or Kubernetes to provide a more flexible serverless environment with containers. Check it out https://www.openfaas.com
I'm sure it's quite obvious to those who work intimately with Amazon services, but for the rest of us, and because it's un-googlable, this apparently is referring to a specific service, AWS Lambda. Would be helpful to include any explanation at all on the landing page.
I watched the overview video below and the tldr for me is that although serverless is doable now and can be done well, the tooling is not there yet, and you're also locked into AWS. So check back in back in 2-3 years.
For me, I think Kubernetes + virtual kubelet (for container instance creation, with per second billing, only on Azure right now) is the safest option. It gives the benefit of easily scalable compute with no need to move to an event driven model or constraints on function duration and resource usage.
It will be great to have Fargate as a provider for the virtual kubelet along with Azure (and I forgot to mention Hyper.sh). Do you know if AWS plan to build a virtual kubelet provider themselves or let the community?
Servers.lol was a side project for us to figure out if some of our own workloads were a good fit. Our day jobs are to build tooling for serverless applications. You can find more at http://iopipe.com
Nice calculator, but it's missing an important field: How many hours per day do you keep your machines running. It assumes you run 24/7.
S3stat's nightly job needs 60 or 70 hours to run, but it all has to happen in the few hours after Amazon finishes delivering logfiles for the day. So I spin up 15 or so machines as spot instances that churn through the queue then shut down.
This calculator tells me that should cost $600 or so per day, when reality it is more like $12. So even though it claims Lambda could do the same thing for $5, it'd take a long time to win back the engineering cost of making the switch. (A little over a month for every hour I spent working on it, it seems).
One of the big value propositions of the cloud was to automatically provision extra servers in response to load - either like you are doing, or by detecting load spikes and spinning up instances.
Trouble is, people don't seem to do that. I see a lot of 'Boss says use the cloud, lets just provision our current network in AWS 24/7'.
I kind of see serverless abd redshift as a workaround for the fact that users are currently mostly doing it wrong, and will eventually figure out that an always on cloud deployment is more expensive than just hiring server or colo.
We had huge problems with Java and Lambda start up times. I would strongly recommend python/nodejs or maybe Go. For whatever reason .Net core was still slower but not Java holy crap slow.
It seems to be. It can be "cold" when the lambda hasn't run at all in a while and the first instance starts, or "cold" when due to increase in load, or for whatever reason that you're not supposed to know or care about, instances are running but it runs on a new instance.
I'd add a cloudwatch alarm keeping track of the number of invocations you expect in a given hour. You can also set a concurrency threshold (a relatively new feature)
At Re:Invent last month, AWS introduced per-function concurrency limits that users can set. It can still rack up charges, but it offers a bit more control than before!
That's where you apply some software developer diligence and do proper testing and monitoring. You're saying right now that regular servers / instances allow developers to be lazy because hey, automatic caps.
Everyone makes mistakes. If a dev deploys something to a server with fixed costs that starts hammering CPU at least we won't be hit by literally thousands of dollars in extra charges.
Wonderful website! Really appreciate the detail put into this. And it worked very smoothly on mobile.
Indeed, lambdas are worth considering for some but not all projects, and this tool seems helpful for people who may need a place to start researching their options.
This claims that on close-to-breakeven applications that moving to serverless might reduce dev costs or accelerate dev work... Serverless proponents: how does that work in theory?
In practice, all the serverless guys I've seen have a pre-CI pre-VCS pre-UAT kind of workflow using the AWS console where there's no change control or ability to collaborate.
I've been using Zappa https://github.com/Miserlou/Zappa for a few side projects and even at work, and you can definitely set up a robust version-controlled, CI + UAT + CD pipeline if you have the discipline.
CI/CD is pretty easy. Another commenter mentioned Jenkins+Terraform. A year or so ago, I did a great project using just Jenkins+CloudFormation for Lambda deployments, too. Took a bit of initial investment but after that it was maybe the best development experience I've had, despite the tooling being lackluster and best practices still sort of emerging. We used TypeScript to build microservices in the backend with API Gateway talking to a proxy tier, Angular 2 in the frontend. All super enjoyable to use.
Of course it depends on the use case, but for smaller functions it definitely reduces dev work. For AWS, Lambdas can be versioned and aliased. Blue green deployments are trivial since you can switch Lambda versions on the fly. Rolling back and invoking dev versions are similar.
You can now even do canary deployments where you switch a small amount of traffic to a new version of your Lambda. The FaaS (function as a service) ecosystem is rapidly reaching parity with traditional software.
We've got a CI pipeline that deploys Lambda functions via Terraform and Jenkins. There are some slightly tricky bits but it's not really that hard to do.
Yeah... I tend to end up on "We're kind-of like a start-up inside of the Enterprise" teams which frequently fail to see the benefit of change control or release engineering, they're edit-on-production PHP cowboys or Java devs that are used to feeling like operations and integrating their code changes are someone else's problem, but who have no such support.
Teams that have (only fairly recently) discovered AWS lets them escape the snail's pace of getting something into production within Enterprise IT, their little walled garden that IT has siloed them into (for their own good). They just absolutely love Node + Lambda because servers are scary (they tend not to have CLI skills to even CD / LS around the VFS) and it lets them get things done -- which is all their superiors value.
Places where IT doesn't value time to market, and nobody values maintenance or costs (we regularly have products owned by failing to apply patches to products using OSS, we rack up AWS bills by leaving manually created test resources around for months or ramping up products like Lambda to the moon for a batch job then forgetting to turn it back down once it finishes).
It's unclear if the Requests/minute is per instance or total. I tried putting in 500k/minute (total) and got a $40k Lambda bill vs $2k EC2 bill (which is roughly what we pay). If I switch it to 20k/minute (per instance) then it's more-or-less the same price for either.
I get the feeling that lambda is only good for small apps..
Once request volume goes up, instances are much cheaper.
So lambda makes sense for hobby stuff and those small services that you only use occasionally. And then again, the financial motivation probably have more to do with maintenance cost.
It can be good for very bursty things too, particularly in the background. I process 'lots' of json on S3 using it. With no setup or anything complex I can churn through a a TB of json in a few minutes. Not sure on total time, but it's less time than it take me to sync the resulting files to my local machine. Running a thousand things at once for a few minutes is great.
Serverless is great for all the tiny little things I want to schedule and forget or setup a trigger for and forget. But my type of usage is not going to pay the bills for serverless.
I just don't get why anyone is using stuff like lambda for big projects unless they have extremely unpredictable and extremely spikey traffic.
Because any kind of sustained usage will quickly be cheaper to put on a nano instance and scale up from there.
The main disadvantage of serverless though is the need to learn an entirely new tech stack, and one that is locked in to AWS. Migrating a large (or medium sized) Django app to Lambda has non-trivial cost in terms of engineering time. Also the Lambda stack is less well known, which may cause some challenges for the engineering team (ramp-up time for new hires, etc.)
Eh - I wouldn't say an entirely new tech stack. The main difference is breaking your components into microservices; after that - you just need a wrapper for your serverless provider of choice. The majority of the logic should be reusable though.
I'm curious, is there an intersection of people who make significant use of AWS who purport to support the open source movement? If so, how do you reconcile centralizing so much of your business/personal data and technology influence behind such a proprietary platform?
You save your code to your Intel laptop, and it gets run.
Neither of us have the complete source code that is used to run that code. You have to be ok with that, and drawing a line in the sand at the hypervisor level just seems super arbitrary.
i can buy an amd laptop and run my code. where you gonna run your aws architected code if aws changes their policies to something you don't like? hint: it's called vendor lock-in.
Ok, so then I spend 5 minutes changing some boilerplate and upload it to Azure/Google Cloud/a server I bought on craigslist? Even if that did happen, I probably would still have saved time overall, because I didn't have to maintain physical infrastructure between now and whenever that distasteful policy change takes place.
Is there any work emerging on a standard environment/framework for serverless code? As it stands it all represents vendor-lock-in due to the comparatively high costs of moving between stacks. An environment that's deployable to any of the serverless providers would be ideal.
I believe serverless works on a bunch of different providers. I have no affiliation with this project but it’s a pretty good tool! https://serverless.com/
Perhaps you could factor in something about cold-start?
I know that in my context, this has been a key issue. Another odd one is that our organization has only certified RHEL and Cent OS running server-side code.
What exactly are your issues with cold start? This typically only affects functions that are called a few times a day, and can be solved for those functions by running a CloudWatch event that triggers your function every few minutes or so. You get 1 million free invocations a month, so this typically doesn't increase your bill.
We have code that you can run on your AWS account for more accurate information from servers.lol based on Cloudwatch metrics. Latency and coldstart information would be totally interesting, I'll suggest it to our team!
This lets you run the same Lambda execution environment on any device you own. Typically, we see this being used by customers that need to do computing at the edge where Internet connectivity is poor or intermittent (think oil and gas fields, mines, etc.)
No, but take a look at OpenFaaS or FaaS-netes, similar concept but running on-premises. Definitely less mature, but they can get you 90% of the way there if you're not doing anything super complicated.
What's the benefit or use case of running serverless on-premise? Isn't the whole ideal of serverless is that you do not maintain servers yourself? Instead of specific Lambda/FaaS solution for on-prem, could we not just use docker package the function in startup script to achieve the same?
It's in the list but when you click on it, it says "Some of the languages you are using are not yet officially supported in Lambda, but there are still runtime workarounds. Here are some resources:" and links to a blog post about running Haskell on Lambda.
My aim was to host a Wordpress or Laravel site on AWS lambda without paying any monthly hosting charges. I got everything running on it (sessions, fs, request, etc).
Some things are different though, like when you write to a file using file_put_contents, etc it writes to a S3 bucket instead of fs (thanks to PHP's S3 wrapper), or when you create a session, it uses AWS DynamoDB to do that behind the scenes.
I've created some examples like this sign-in example which uses AWS Cognito + AWS lambda to create a login/signup page[2], file uploader, etc[3].
Of course my project was just for my own amusement but I think this can be good for side project where you just want to host something and forget about it.
[1] https://github.com/san-kumar/lambdaphp [2] https://www.lambdaphp.host/examples/auth/ [3] https://github.com/san-kumar/lambdaphp#examples