Fragment: Bring Your Own Infrastructure (BYOI)

Over the years I posted various fragmentary thoughts on delivering software to students in BYOD (bring your own device) environments (eg Distributing Software to Students in a BYOD Environment from 5 years ago,  BYOA (Bring Your Own Application) – Running Containerised Applications on the Desktop from 3 years ago, or Rethinking: Distance Education === Bring Your Own Device? yesterday).

Adding a couple more pieces to the jigsaw, today I notice this Coding Enviroment Landing Page at the University of Colorado:

The environment appears to be a JupyterHub environment bundled with VSCode inside using the jupyter_codeserver_proxy extension and the picture editor bundled as a JupyterLab extension.

Advice is also given on running arbitrary, proxied web apps within a user session using Jupyter server proxy (Proxying Web Applications). This is a great example of one of the points of contention I have with Jim Groom, “Domain of Your Own” evangelist, and that I’ve tried to articulate over the years (not necessarily very successfully), several times previously (eg in Cloudron – Self-Hosted Docker / Containerised Apps (But Still Not a Personal Application Server?) or Publish Static Websites, Docker Containers or Node.js Apps Just by Typing: now): in particular, the desire to (create,) launch and run applications on a temporary per session basis (during a study session, for the specific purposes of launching and reading an interactive paper in a “serverless” way, etc).

The Colorado example is a really nice example of a simple multi-user environment that can be used to support student computing with an intelligent selection of tools bundled inside the container. (I’m guessing increasing numbers of universities offer similar services. Anyone got additional examples?)

Another jigsaw piece comes in the form of eduID, a federated Swedish identity service that students can use to sign in to their university services, whichever university they attend. One advantage of this is that you can create an identity when you start a university application process, and retain that identity throughout an HE career, even if you switch institution (for example, attending one as an undergrad, another as a postgrad). The eduID can also be linked to an Orcid ID, am international identifier shceme used to identify academic researchers.

What  eduID does then, is provide you with an identity that can be registered with an HE provider and used to access that HEI’s services. Your identity is granted, and grants you, access to their services.

So. Domain of Your Own. Hmmm… (I’ve been here before…) Distance education students, and even students in traditional universities, often study on a “bring your own device” basis. But what if that was an “Infrastructure of Your Own” basis? What would that look like?

I can imagine infrastructure being provide in various ways. For example:

  1. identity: a bring-your-own-identity service such as eduID;

  2. storage: I give the institution access to my Dropbox account or Google Drive account or Microsoft Live Onebox, or something like a personal SparkleShare or Nextcloud server; when I load a personal context on an institutional service, if there is a personal user file area linked to it, it synchs to my remote linked storage;

  3. compute: if I need to install and run software as part of my course, I might normally be expected to install it on my own computer. But what if my computer is a spun-up-on-demand server in the cloud?

(It may also be worth trying to compare those to the levels I sketched out in a fragment from a year ago in Some Rambling Thoughts on Computing Environments in Education.)

I’m absolutely convinced that all the pieces are out there to support a simple web UI that would let me log-in to and launch temporary services on on-demand servers (remote or local) and link and persist files I  was working on using those services to a personal storage server somewhere. And that all it would take is some UI string’n’glue to pull them together.

PS Security wise, something like Tailscale (via @simonw) looks interesting for trying to establish personal private networks between personally hosted services.

PPS anyone else remember PLEs (personal learning environments) and distributed, DIY networked service oriented architecture ideas that were floating around a decade or so ago?

Author: Tony Hirst

I'm a Senior Lecturer at The Open University, with an interest in #opendata policy and practice, as well as general web tinkering...

2 thoughts on “Fragment: Bring Your Own Infrastructure (BYOI)”

  1. TOny,

    Big fan, I actually see this as a logical extensions of Domain of One’s Own, and I know the spinning up and down of computing resources is a major difference based on the stack options right now we provide through cPanel. I own our limits for sure. And the idea of linking Dropbox/Box/Google Drive to a middle ware that allows folks to spin up there own apps is awesome, the question remains though—what application makes it simple to spin up server-based apps that is seamless enough that there is no server configuration?? I would argue that was our interest in CloudRon, and Sweden’s ID network is unique and a brilliant example, but outside that context it gets tricky, though federation shibboleth (inCommon) provided by Internet 2 in the the US institutions fairly close. My argument would be no mater what we still need an open source middle ware between the open source apps and containers/serverless resources and the personal storage and ID management. That piece is crucial, and not certain where it lives in your discussion above. Is it AWS? Digital Ocean? I think that piece providing coherence is what I am increasingly thinking could make this seamless and not default back to Google, Amazon, Digital Ocean, or some other 3rd party. Does that make sense?

    1. Hi Jim

      I think that Digital Ocean is one of the places that comes close, though posts like show that the steps in the middle need collapsing to a single button.

      CLI tools like and (and self-hosted variants like exoframe.js), where commands can also be wrapped as desktop shortcuts, perhaps provide tools for prototyping workflows and working out steps that can be further collapsed and simplified.

      Thinking about how provisioning tools like Docker and vagrant can provide a common command UI for launching services locally or remotely (as per yesterday’s post) is also right there, somewhere, I think; graphically, tools like ContainDS (a fork of Kitematic, moved on somewhat) show how we can launch prebuilt environments, or build them ourselves from provided/linked config scripts, locally (and I keep hoping that the ability to launch against a remote, as well as local, docker engine will be added to that app at some point).

      The Kitematic UI resembles the Cloudron one, and also the JupyterLab launcher, by providing buttons to launch applications, so that is a useful design idea I think. As you say, how the linking and plumbing works is another, both in terms of:

      1. where the launcher actually exists, is run from, and accessed (desktop app, browser UI etc);

      2. where the credentials are entered and stored, as well as how stored credentials are accessed;

      3. how the service launchers are wired (that is, how the launcher launches a server and/or a service on a server or locally, in a credentialled way if credentialled auth is required (which it would probably be on remote services, but not locally, or for free and open on demand services like MyBinder (although they in turn may be configured to only accept launch requests from requests made from certain domains or cookie authed browser sessions).

Comments are closed.