Yes! We are definitely looking forward to championing awesome projects to build languages for the Runtime API. Take a look at the Rust and C++ examples as they show you a bit of how it all works. (Chris from AWS Serverless team)
695 karma · joined June 1, 2017
One could easily configure lots of things wrong in life that would end up wasting money! That said we find that many customers end up saving a lot by moving workloads from more traditional "serverfull" models to Lambda and serverless application patterns. We also see entire startups starting this way and getting to fairly massive scale without ever needing to manage a host anywhere. While not a silver bullet, the use-cases for Lambda are many and proven. More here: https://aws.amazon.com/lambda/resources/#Customer_Case_Studi...
Sounds like an idea for the next YC class!!
-munns
On per request pricing this is something you can do with Lambda now semi-trivially. You can figure out average Lambda execution cost based on duration of execution and memory you have configured + API-GW related request costs. Depending on your DB you can potentially tie this back as well (harder with some DBs vs. others)
I'd say that while we see cost savings for most serverless platform customers, like an overwhelming amount honestly, we also see companies adopting it for the benefits of time to market, reduced operation burden, and the overall capabilities that they don't need to write themselves. Hard to ROI some of that. While this article did take on a cost based view I'd love to see more folks talk about how these "softer" benefits impact them.
Thanks for your reply!
- Chris
In my experience from pre-AWS days hiring good Ops people for systems, networking, etc is hard no matter what. I'd argue that the developer's role/day to day changes little in the move from traditional "on-prem" type infrastructure to cloud, even with serverless platforms in play. Generally speaking though I'd aim to hire people who are hungry to learn and have enough fundamental knowledge of networks, operating systems, and hardware to be able to ramp up on public cloud technologies. If you learned it one way, you can learn it this way and there's a massive amount of people here at AWS at least to help you along the way (training folks, support folks, solutions architects) as well as 3rd parties like ACloudGuru, Linux Academy, and others with training/consulting capabilities. The future of technology is moving towards public cloud and I'd argue serverless application development models whether you want to get on board or not. No one cried for the last blacksmith in the town when cars replaced horses.
Best practices are hard for people to follow no matter the technology, and the easiest solution is rarely the "best" (see people leave SG's wide open, open S3 perms, etc). We at AWS know its our job to make security best practices easier to grok and implement and there are tools that help with that today (IAM testing/reviewing tools, trusted advisor as examples). There's more we can do here.
Thanks for your reply!
- Chris
A lot of the comments here are comparing bare metal/virtual servers to a combination of two+ products with literally dozens of built in capabilities, security controls, built in scaling, monitoring, logging, deployment mechanisms, and built in high availability. These are not apples to apples comparisons in the least.
Fwiw I've run my own metal at some fairly large websites(can go find me on Linkedin) and I can honestly say that to discredit the amount of time you spend on solving the above capabilities WELL is to probably toss more than 120% of the cost out the window. People time to manage what goes on the hardware is almost always higher than the cost of the hardware. I've spent 5+ years working with everyone from startups up through massive enterprises and only the top 10% does any of this well when doing it themselves.
Taking some of the other examples here, let's say you do try and solve this with 2 virtual/physical servers from a traditional hosting provider. What now do you do for: high availability, nearly instant scalability, monitoring, logging, alarming, deployment and security controls. Those last few all scale on their own too (oh you've never filled a harddrive with logs before?). Are you going to run all of your software on these 2-3 hosts? What happens when they go down? How quickly are you recovering? What impact is there to your customers during this time? What value do you place on that downtime? How many of your tools just failed? Lost data?
How about patching the OS, the software you run on it, your tools, your languages/packages? In busier environments where I ran my own logging, monitoring, metrics, alarming, backups, software, firewalls, etc + the operating systems those things ran on + the modules/packages most developers use these days in languages such as node.js and python, you are talking about whole days in a week to track, test, and understand these changes and the risks associated.
I'm a #serverless zealot by trade sure, and I am happy to be called out on that, but these comparisons of a very high level platform that essentially removes most of the day to day care and feeding of your own "iron" can not be compared to running your own iron at just that iron's cost.
Today given that aliases/versions do not have any sort of different permissions you are probably best to either run completely different stacks of resources or the multiple account model. With AWS Organizations these days its not that hard to run multiple environments across accounts.
We did a webinar on some of this a few months back, the slides here might be useful to you: https://www.slideshare.net/AmazonWebServices/building-a-deve...
It heavily leverages AWS's tools, but you could create similar practices using 3rd party frameworks and CI/CD tools as well.
Thanks,
-munns
Thanks, - Chris
I thought this was a really great list. Some big ones I like to call out:
#9: Travel - This gets me more than most things. I have on occasions bumped into other speakers completely unprepared for their travel for or for things that might go "boom" such as: laptop failure, presentation corruption, display adapters not existing (or breaking which is harder to prepare for) and my personal favorite Immunity Boosters. Hell yes. A coworker turned me on to these two years ago after coming down with the plague after speaking at a few too many events in a short period. Now its a must for me and whether its placebo effect or not I haven't gotten sick while traveling/speaking since.
#10: Showtime - No one is born a great speaker. Flat out no one. I know people who speak weekly at public events and they used to suck at it too. Don't be afraid/stress too much before a talk. That said, I have seen people bite off more than they can chew and give a first talk at a major tech event such as AWS's Re:Invent where rooms average 1k people. If you're going to choke at your first event, don't have it be that big/visible of a one. Start with local meetups!
#5/6: A big one that I always recommend is peer review your content before you even start dry runs. Presentations often live longer on sites such as Slideshare than they do in the minds of those who have seen them live. It is in sites like Slideshare that your spelling, grammar, and even design issues will stand out the most. Get someone who is detached from your presentation to read through it, maybe even two people, take that feedback and then move forward. For me, my wife who was a journalism major reviews almost all of my content despite not knowing much about the technical nature.