A Cloud Guru Blog

F# actually rusn _very_ well on AWS. There is some official scaffolding tooling you can use[0], and performance with .NET Core is more than sufficient for what your business likely needs[1]. Love this quote: "Both C# and F# on .Net Core 2.0 exceeds all expectations and outperforms all other runtimes in average duration". Thanks for the compliment! And I hope that it all goes well with you. [0]: https://aws.amazon.com/blogs/developer/f-tooling-support-for-aws-lambd… [1]: https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-p…

> Best to keep your workloads as small as possible, cold starts can be very bad, depending on the type of project. Here's a recent, interesting article on the topic that quantifies some of this: https://read.acloud.guru/does-coding-language-memory-or-package-size-a…

It's not that risky, specially for early-stage MVP or prototyping. In my opinion, serverless is the future, at-least for 90% of Web apps, APIs and device app backends. It's great for rapid delivery, high scalability and low maintenance from day one. Cloud Guru, a local Melbourne startup, is built entirely on AWS Lambda. They host Serverless/Lambda community meetups as well, and write about the tech at https://read.acloud.guru/tagged/serverless

From the research I did, here's how languages stack up in Lambda runtime (lowest first): 1. Python & JS 2. Go 3. C# & Java I couldn't find any data on Rust. The understanding at the time was that Python & JS runtimes are built-in, so the interpreter is "already running" Go is the fastest of compiled languages, but just can't beat the built-in runtimes. C# and Java were poorest as they're spinning up a larger runtime that's more optimized for long-running throughput. https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html https://medium.com/the-theam-journey/benchmarking-aws-lambda-runtimes-… https://epsagon.com/development/aws-lambda-programming-language-compar… https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-p… Of course, benchmarks like this only go so far. Use as a starting point for your own evaluation; not as an end-all-be-all.

Monetary savings is basically the main selling point of serverless: https://read.acloud.guru/how-going-serverless-helped-us-reduce-costs-b… https://techbeacon.com/enterprise-it/economics-serverless-computing-re… https://medium.com/perfsys-blog/how-serverless-computing-saves-money-2…

Though Amazon's managed service isn't completely managed at that scale either. There are still hot key partitions. There are still other issues that cause people to abandon DynamoDB at scale. And people still have "the blindfold on." q.v., https://read.acloud.guru/why-amazon-dynamodb-isnt-for-everyone-and-how…

https://read.acloud.guru/deploy-an-aws-appsync-graphql-api-with-amazon… https://andrewgriffithsonline.com/blog/serverless-websockets-on-aws/

If I understand your suggestion right, it's to heartbeat concurrently to force more warm instances. We have played with that, but spikes are spikes - the most interesting ones defy expectations. As with many apps, the conditions that make us spike make performance more important, not less. Just found the same author as OP with a clever solution here: https://read.acloud.guru/cold-starting-lambdas-2c663055589e Having the app pre warm instances on a per-user basis is super cool -- for user-driven workloads like web servers. To make matters worse, we are serving an API that takes hits from third party streams -- so our concurrency is based on their client behavior, not something we can easily link to a session scope, like users. Tricky!

It is not. You obviously get into a different set of problems than you're accustomed with, but it is not seconds, even on "cold" lambdas. https://read.acloud.guru/cold-starting-lambdas-2c663055589e

I was going off of this article: https://read.acloud.guru/serverless-the-future-of-software-architectur…

They have written a blog post that goes into more detail on how they piece together various components with Lambda: https://read.acloud.guru/serverless-the-future-of-software-architectur… I'm pretty sure they have another post coming in the near future too. I am impressed by how fast they built their platform given the size of their dev team. We (I'm a course author there, not developer) also use Lambda for custom slack bots too.

How about this: https://read.acloud.guru/serverless-superheroes-eric-hammond-aws-lambd… From the article: > The most surprising thing I learned from building TimerCheck.io was: If designed well, it is possible for some products built with services like AWS Lambda, API Gateway, and DynamoDB (often categorized as “serverless”) to require zero technical maintenance! The public, free TimerCheck.io microservice API was released in July 2015 and I have never had to do anything to keep it working or to scale it, with one notable and unexpected exception. > The only time I had to do work on TimerCheck.io was when Amazon declared that AWS Lambda support for Node 0.10 was being phased out. If my code base had been larger, it probably would have been easier to simply upgrade to Node 6.10, but I decided instead to rewrite the function in Python 3.6. It has continued operating smoothly since. > As part of the rewrite, I also took advantage of one of several good AWS Lambda deployment tools that have arisen to fill what was an important gap when Lambda was launched. I chose Amazon’s open source chalice tool for this project, and was thrilled with how it eliminated all the work of setting up an API Gateway, a formerly daunting task. > The TimerCheck.io service has had a few short outages over the years, but they were always due to region-wide problems that AWS experienced, and AWS resolved the issue without me having to lift a finger. Even with a lot…