I’m over in the Cloud-Native Geospatial Foundation’s blog today with a post called “Cloud-Native Geospatial If You Don’t Speak Snake”. This post comes from an UnConference session at the 2023 ESIP July Meeting, organized by Alexey Shiklomanov, focusing on what tools and what gaps exist in the cloud-native geospatial workflow for non-Python users. It was an absolutely fantastic UnConference session, and I’m hoping that my summary of our takeaways is as useful for others as it was for me.
One challenge in the session – and one that I don’t get into in the post – is that “cloud-native” means a lot of different things to different folks! The CNGF themselves have a pretty straightforward definition:
Cloud-Native data formats are structured to be efficiently retrived from cloud object storage services which are designed to serve large volumes of data using generic RESTful / HTTP data transfer protocols.
But our UnConference session was interested in a much broader definition, one that was a bit closer to the CNCF definition of the term:
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
My post focuses a bit more on tools and gaps relating to the CNGF definition – it’s on their blog, after all! – but our working group was interested in API specifications, serverless runtimes, and all sorts of other topics that I think haven’t seen the same amount of standardization as the data format and retrieval side of geospatial workflows.1 There’s a lot of activity around geospatial workflows right now, and I’m excited to see what the future has in store!
Footnotes
Most of my data storage and retrieval work boils down to “use COGs, use GDAL’s virtual filesystem interface”. I wish my analysis, runtime, and codebase setups could be boiled down to that level.↩︎