The problem with Fargate is the cold startup time and lack of support for GPUs. It's also quite new and there's all sorts of issues with it but hopefully will get resolved.
I think ECS is a better fit if you require GPU or you can do with not scaling to zero. Obviously once Fargate catches up and polishes its kinks it would stand on its own but given the way Cognito is, I have very little faith that things will improve quickly (theres an open ticket in cognito that is over 3 years old).
Cold start would be just as much of a problem on lambda, no? Which is to say, it would or wouldn't be a problem depending on your needs modulo language/runtime choice. If we expect to compute for >15 minutes, cold start is probably not a big deal.
Makes reading ruby so much more difficult. Also optional return statements. If you need to refactor a function, it’s not always obvious that it’s relying on an implicit return and super easy to break things IMO
(not trying to convince you as I think in this thread no one will be convinced of anything)
Knowing that in Ruby a method will always return its last executed line unless explicitly returned early makes (at least for me) things very easy to get.
A method with two branches will always return the last line of the executed branch, thus you will always know what the response could be.
But this (IMO) is because Ruby OOP where the main concept is that when you are invoking a method you are actually sending a message to that object thus you should get a response. So Ruby makes this way of working with objects universal.
Once you call a method you will get a response.
I find it strange the other way around, working in languages where I need to put return even on the last line of the method. For example after almost one year of full time backend development in Ruby, I needed to write some JS code. I debugged for half an hour why a short function that I wrote was not working properly until I got it: I need to add 'return' to that last line to get the actual result. This was strange for me :)
Agreed, in complicated Ruby packages with layers and layers of dependencies it quickly becomes a nightmare to identify which class comes from which import, where it’s defined, etc. Never an issue in python
One of my biggest complaints about Ruby is that that it’s so much harder to drop into a debugger. In python it’s as easy as import pdb; pdb.set_trace(), but for ruby (at least the versions on our build systems), you need to figure out how to add the dependency for pry/byebug first which is non trivial.
A fair complaint, but FYI it’s outdated as of Ruby 3.0 (released in 2020) which includes the `debug` gem [0]. So in Ruby 3.0 onwards it’s as easy as `require 'debug'; debugger` just like you want. Hopefully your build systems will upgrade to a newer Ruby before too long.
Yes! (in some cases) The tradeoffs are that lambdas are way faster to start up, but they max out at 10GB of memory, 15 minutes of runtime, you can't use GPUs, and you get 250MB to store your code (you get more if you build a container) and 512MB of temp space. We're in the middle of working on adding this as an option--we want to make it seamless to switch between running your code on Lambda (for short, quick jobs) vs EC2 (for longer, more resource-intensive jobs) depending on what kind of workload you have.
Good news. We've found lambdas orchestrated with step functions and properly split out as to function can do a lot of data processing even with the limits you stated before needing to switch over to AWS batch or ECS. Nice to have that tool in the belt. I'll check it out.
