3 ms·

This is really great! I wrote and operate a pipeline framework for analyzing data from multiple astronomical observatories in low-latency [1], and I'm currently

This is really great! I wrote and operate a pipeline framework for analyzing data from multiple astronomical observatories in low-latency [1], and I'm currently adding this sort of burst-performance scaling for things like background simulations. Things like Kubernetes spin-up time or packaging huge libraries for AWS Lambda are, indeed, challenges. Getting those startup times down and doing autoscaling in a relatively platform-agnostic way with low boilerplate overhead would be really game-changing for these sorts of analyses (among other applications). If you can run an analysis in low-latency and detect a joint gravitational wave/EM source, for example, you can quickly follow it up with other telescopes, like we did with the first direct kilonova observation [2]. Though the gamma-ray detection localization wasn't good enough to really aid counterpart searches for that event (GW170817), there are other types of candidates (like GW+neutrinos, my project) for which this rapid localization would be a huge improvement. And if you can do really hard things like estimate the GW source parameters before merger (e.g. whether you're looking at a binary neutron star merger, which is likely to emit detectable light if it's close enough), you can try to get fast-slewing telescopes pointing on source at merger time. Not to mention that burst processing would let you do more clever things with your statistics (getting better sensitivity) in low-latency as well. So stuff that makes this easier is really exciting! Maybe if the API is amenable to my own solution I'll be able to implement this as a backend :) [1] http://multimessenger.science http://multimessenger.science [2] https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.119.161101 https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.11...

isoprophlex 7y ago
Reading all that makes me think.... you must have one of the coolest jobs around
- stefco_ 7y ago
  It is! My response to the other comment describes some of the challenges, but overall it's wonderful! It feels a lot like running a startup, though of course the compensation is more spiritual than financial. But it has all of the great and exciting parts of a startup combined with the bonus of getting to think about stars crashing into each other for your actual job.
jedberg 7y ago
Check out lambda layers to help with your large package deployment issues.
- stefco_ 7y ago
  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]
deleted 7y ago
[deleted]

isoprophlex 7y ago

Reading all that makes me think.... you must have one of the coolest jobs around

stefco_ 7y ago
It is! My response to the other comment describes some of the challenges, but overall it's wonderful! It feels a lot like running a startup, though of course the compensation is more spiritual than financial. But it has all of the great and exciting parts of a startup combined with the bonus of getting to think about stars crashing into each other for your actual job.

jedberg 7y ago

Check out lambda layers to help with your large package deployment issues.

stefco_ 7y ago
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]

deleted 7y ago

[deleted]