Does your data science platform check the following boxes?
This bite-sized post is the first in a series that digs into using Git effectively from within Gigantum. We start with the the most basic thing, which is importing an external Git repository (or "repo") with some data. Gigantum does a lot of Git automation under the hood. While that automation provides nice features like version control by default and the Activity Feed, naive inclusion of a Git repos in your project can lead to some hiccups! So how can we use a dataset that's published on GitHub?
This recaps our first webinar of June 23, 2020. It was fun and we wanted to give access to the video.
The webinar demoed creating portable and reproducible work in Jupyter and RStudio, as well as an easy system for transferring work between CPU and GPU resources. It further explained why decentralization, not centralization, is best for collaboration and productivity in data science. The current remote work situation makes this decentralized approach even more critical.
In the webinar Dean (CTO) and Tyler (CEO):
- Outlined the technical problems of collaboration and managing data science work;
- Related this problem to cost and productivity concerns;
- Explained "centralized vs decentralized" and why decentralization is better;
- Explained how local automation can make decentralization robust & scalable;
- Demonstrated Gigantum's Client + Hub model for scaling collaboration and productivity.
Decentralization means letting data scientists work across resources in a self-service fashion. For us, it also means container native, not just cloud native. It is that simple.
The key to decentralization is automation and a UI at the local level, not as a monolithic, managed cloud service. We call this "Self Service SaaS", which is sort of a silly phrase but captures what we mean.
Self Service SaaS takes the good parts of the SaaS experience, i.e. nice UIs and automation around difficult tasks, and eliminates the bad parts, i.e. zero control over deployment and everything that entails.
Check out the video and let us know what you think. We love to talk about this stuff and we want to hear your story and your problems. You can watch by filling out the form below.
In this post, we explore some of the cutting edge tools coming out of the RAPIDS group at Nvidia. This highlights yet another use-case for the portability provided by the Gigantum Client - we're going to make it easy to try out an evolving code base that includes some fussy dependencies. This post revisits some skills we picked up in our previous post on Dask dashboards, so be sure to check that post if you're interested in parallel computing!
Working exclusively in a single cloud isn't possible for most people, and that is not just because it is expensive. Real work requires significantly flexibility around deployment.
For example, sensitive data typically can't go in the cloud. Or maybe each of your three clients uses a different cloud, or maybe you spend significant time on a laptop.
It would be nice if things would "just work" wherever you want them to, but the barriers are many and large. Git & Docker skills are table stakes. Typos & hard coded variables rule the day. No matter how careful you are, stuff goes wrong. Maybe your collaborators don't have the same level of care and technical skill you do.
Who knows? The possibilities are endless.
Well, it used to be hard. There is a new container native system that moves reproducible work between machines (virtual or bare metal) with a few clicks.
No need to know Docker or Git. No need to be obsessive about best practices. No need to worry who is on what machine.
We will demo it here using Dask and DigitalOcean for context. In the demo we:
- Create a 32-core Droplet (i.e. instance) on Digital Ocean
- Install the open source Gigantum Client on the Droplet
- Import a Dask Project from Gigantum Hub and run it
- Sync your work to Gigantum Hub to save it for later.
Computational reproducibility should be trivial but it is not. Though code and data are increasingly shared, the community has realised that many other factors affect reproducibility, a typical example of which is the difficulty in reconstructing a work’s original library dependencies and software versions. The required level of detail documenting such aspects scales with the complexity of the problem, making the creation of user-friendly solutions very challenging.
Today, we present Gigantum, an open source platform for creating and collaborating on computational and analytic work, complete with:
- Automated, high-resolution versioning of code, data and environment for reproducibility and rollback
- Work and version history illustrated in a browsable activity feed
- Streamlined environment management with customization via Docker snippets
- One-click transfer between laptop and cloud for easy sharing
- Seamless integration with development environments such as JupyterLab