661–670 of 733 posts
Earlier quoted context omitted.
You are not wrong. But it is all about saving money on labor. The rest are just the constraints of the system you use. (Aka requirements) its like complaining about the need to use posix for Linux.
I feel like we're just transferring the labour from ops to dev though. Where I work we still haven't got as good a development workflow with lambdas as we did with our monolith (Django).
PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article: 1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. 2. Use managed services whene…
> Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. Shouldn't this not be a problem if you're doing 10 million requests a day? If you have enough requests, your lambdas should stay hot most if not all the time.
Earlier quoted context omitted.
So, to summarize, you should: 1. not use the programming language that works best for your problem, but the programming language that works best with your orchestration system 2. lock yourself into managed services wherever possible 3. choose your api design style based on your orchestration system instead of your application. 4. Use a specific frontend rpc library because why not. ... I've hacked a few lambdas toget…
Think about serverless as framework-as-a-service. It has a learning curve, but if you buy in, it is an amazing productivity boost. (If Reddit’s video hosting being built and operated on a serverless stack by a single a engineer won’t convince you, I don’t know what will.)
That thing almost never works.
Earlier quoted context omitted.
I feel like we're just transferring the labour from ops to dev though. Where I work we still haven't got as good a development workflow with lambdas as we did with our monolith (Django).
Paying one guy is cheaper than two. So... You are not wrong :)
Earlier quoted context omitted.
I built an azure function that runs for free that just pings my .NET MVC pages periodically so they are always hot on my cheap hosting.
You can just use application insights for this. It can also show you the results of the ping over time in a scatter chart.
Earlier quoted context omitted.
Burst traffic with high writes? --> Use a stream. Burst traffic with high reads? --> Use a cache. Large compute and memory intense stuff isn't suitable for serverless
What kind of stream do you have in mind? I don’t follow.
Earlier quoted context omitted.
>I've had jobs that took 18 hours to run on single machine finish in 12 minutes on Lambda. I could run that process 4 times a month and still stay within AWS's free tier limits. Ok I'll bite. What takes 18 hours to run on a single machine but finishes in 12 minutes on Lambda.
I worked on a service a year ago that would stream a video from a source and upload it to a video hosting service. A few concurrent transfers would saturate the NIC. Putting each transfer job in a separate lambda allowed running any number of them in parallel, much faster than queuing up jobs on standalone instances
PSA: porting an existing application one-to-one to serverless almost never goes as expected. Couple of points that stand out from the article: 1. Don’t use .NET, it has terrible startup time. Lambda is all about zero-cost horizontal scaling, but that doesn’t work if your runtime takes 100 ms+ to initialize. The only valid options for performance sensitive functions are JS, Python and Go. 2. Use managed services whene…
DevOps is not a synonym for "ops" or "sysadmin". It's not a position. DevOps is like Agile or Lean: it's a general method with lots of different pieces you use to improve the process of developing and supporting products among the different members of multiple teams. DevOps helps you save money, not the reverse.
You don't even need an "ops person" to do DevOps.
Earlier quoted context omitted.
Rust AWS Lambda Runtime author here: while the Rust runtime tends to beat all other runtimes, Go is _very_ close in terms of startup times.
this? https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws... https://github.com/awslabs/aws-lambda-rust-runtime https://crates.io/crates/lambda_runtime you rock! That docker based build system makes building those MUSL based rust binaries a snap!