I have, and they're great! But limited. The real issue is the size of the dependency stack for scientific computing; I need to use a lot of monolithic, project-

I have, and they're great! But limited. The real issue is the size of the dependency stack for scientific computing; I need to use a lot of monolithic, project-wide libraries (read: minimal python installs of many gigabytes), far beyond Lambda limitations. The solution is pretty obviously to split up my own monolithic architecture so that subcomponents can run in limited environments, allowing some steps in my pipeline DAG to be implemented on Lambda; this is the direction I'm moving in (it also has certain development advantages). That said, leaving my own monolith behind requires some careful planning. For one thing, reproducibility is easier if you only need to track a single code version; it's more work to have a fully-reproducible infrastructure (something I'm working on with versioned containers, detailed file-generation metadata, and automated build/test processes). It's also sometimes necessary to hot-fix things in production: this is science, so the APIs I pull data from are not versioned and are subject to breaking changes during production with nothing more than a short email thread to announce them (I get hundreds of emails a day from both major collaborations I'm in (LIGO and IceCube), so tracking these changes is its own hell). This means being able to develop and fix things extremely quickly is paramount, which is also easier on a properly-factored monolith unless you have a proper microservices architecture and deployment system. We also get crazy demands for new features during production from other collaborators and scientists that make my software development friends gasp. And nobody understands anything I do because documentation isn't prioritized, so I have to do all this in a way that's maintainable and extensible by one person. (Seriously, I need to fight to document and properly refactor/maintain my code sometimes because people don't want to allocate time for these tasks.) This is all hard fundamentally because scientific software development is a garbage fire of overworked developers and misaligned incentives (you don't get credit for code no matter how many man hours it saves/science it enables; only papers count). It's like we're running in constant do-or-die startup mode, with MVPs developed by 22 year-olds who just learned python for the first time used as mission-critical undocumented abandonware after they finish their PhDs. All of our code has 1/3 the manpower it should, so we're all prioritizing ruthlessly with varying degrees of success. Some people have done really amazing, inspiring work using best-practices devops and the rest, and it's slowly getting better in many spots, but the systemics of the dev environment means that unless you're a 10x person, your scientific code is going to be pretty rough around the edges. All this is to say that Lambda is great but not exactly what I can use at the moment, though my plan is to support it once I've Balkanized my code a bit :) [edit: typo]