Dockless electric scooters and bicycles are the latest craze/plague (delete as appropriate) to hit San Francisco. The idea of dockless light vehicles isn’t new: many other cities around the world feature bicycles just parked around town. You walk up to one, scan a QR code with your phone to unlock it, ride it to your destination, where you park it and walk away, leaving it ready for the next person to find and use.
Adding batteries to the bicycles was a logical next step, especially in hilly cities — but having ridden battery-assisted bikes around flat Berlin, it’s still a welcome addition. A bicycle is inherently far nimbler than a car in congested city traffic, and electrifying it significantly extends the bike’s useful range. Uber apparently sees the potential with its recent purchase of JUMP Bikes, one of the leading dockless electric-bike companies.
The extension from bicycles to electric scooters has been controversial. The problem is one that we in IT are all too familiar with: those pesky users, who are leaving the scooters (and even bikes) anywhere and everywhere, including where they really shouldn’t. They’re blocking doorways and even the entire sidewalks, getting in the way of pedestrians, and even becoming an eyesore. Eventually, matters came to a head, and San Francisco instituted a temporary ban on the scooter companies. While rollouts continue in other cities, it is far from clear what the future holds for these vehicles.
This all sounds very familiar from an IT perspective. Let’s take a step back and look at this story again.
Stage One: Dedicated Hardware
With both IT and bikes or scooters, it used to be that you had to own your own if you wanted to get around. You spent a lot of time making sure that nobody else could use it, with big locks that you would use to secure your bike — with the result that utilization rates are actually pretty low. How much time do you spend riding your bike versus how much time it spends parked?
Both serverless computing and new transportation options hold enormous promise, thanks to the removal of friction from everyday processes. There’s a problem, though: by removing constraints, it becomes harder to manage these systems.
In pre-cloud days, how much of your on-premises IT capacity was idle, held in reserve against a sudden peak in demand? Companies sized their IT estate against maximum expected usage, with the result that much of that capacity was unused for most of the time. However, the consequences of running out of spare capacity precisely at the moments of peak demand involved significant business impact, and so companies everywhere over-provisioned to insure against outages.
Stage Two: Sharing, From A Pool
Then along came the first wave of sharing options: docked bike-share programs, and virtualization. Both of these enabled better utilization by introducing shared resources. Instead of owning a bicycle, you find a dock, unlock a bicycle with your credit card, ride it to another dock, return the bike, and walk to your destination.
In the same way, virtualization lets one physical server support a number of virtual servers, with the ability to change the mix on the fly in response to demand patterns. Internal-only or non-mission-critical systems could safely have their capacity reduced or even be decommissioned entirely to redirect capacity to publicly-visible systems when they came under strain. Snapshots ensured that processing could resume with minimal disruption once the usage peak had passed.
Stage Three: No Limits
The next stage in the evolution is to remove constraints: respectively, the dock and the server. It’s much more convenient to ride the bike or scooter straight to your destination and leave it right there, instead of having to find a dock and walk the last part of your journey. In the same way, why bother with servers at all, physical or virtual?
With serverless computing, it’s much easier to build and deploy new applications, without worrying about the underlying infrastructure. System capacity is resized and redirected on the fly in response to patterns in user demand and to other events occurring in the background. If more capacity is required, it can simply be provisioned, usually through entirely automated systems. The entire process is invisible to both users and developers of the applications
No Limits = Loss Of Control
Both serverless computing and new transportation options hold enormous promise, thanks to the removal of friction from everyday processes. There’s a problem, though: by removing constraints, it becomes harder to manage these systems. It was pretty difficult to lose track of physical infrastructure, but the loosened constraints between applications and their substrate introduce new problems in accounting and strategy.
In the same way, once bicycles and scooters no longer need to be returned to a dock, some thought needs to be given to better management of the system, so as to avoid abandoned vehicles becoming a nuisance. The risk is that enraged residents might start throwing the bikes and scooter into trees or nearby bodies of water. Virtual servers don’t pollute in quite the same way, but they do take up capacity, not to mention consuming licenses, and they do need to be actively administered, patched, and updated, if they are not to become a flaw in your security.
Dockless electric bikes and scooters promise to reduce congestion in cities enormously, by improving utilization rates of shared resources. One person traveling a few miles by scooter takes up almost no space on the road, and once at their destination, they do not require a huge parking space for their vehicle. Virtualization introduced (at least potentially) far higher rates of utilization of IT infrastructure. Achieving these promised results, however, requires some thought to be given to management and operations of the platform.
As provisioning additional capacity became easier more widely available, administrators of newly virtualized infrastructure soon found themselves contending with “zombie VMs,” virtual servers that were running and consuming resources but without a clear purpose or owner. In extreme cases, these zombies could entirely saturate available capacity, to the point that admins desperate for capacity would resort to “management by screaming”: turn something off, and wait to see if anyone notices. Not exactly ideal!
Pedestrians are pretty quick to notice if they can’t walk along the sidewalk, so dockless scooter and bike operators have the opportunity to put systems and processes in place to safeguard the promise of their offerings, such as “no parking zones” enforced by the app itself. IT operations teams in some ways have it easier, as they have more control over their platforms — but for them, the issue is scale. Despite their recent prominence in the news, there are still not that many scooters or bikes on the road. Even major cities only offer tens of thousands of bikes. Moogsoft has several customers whose IT estate is larger than the entire worldwide capacity of such vehicles.
Algorithms Enable Management At Scale
The only way to keep track of such vast numbers of constantly-changing resources is by applying cloud-scale thinking: remove all the manual tasks, from both provisioning and operation of the system. This means automation of every step of the process, from initial deployment, through day-to-day-management, to final decommissioning. Much as with the bikes and scooters, the two ends of the process are the easy parts: drop off a few more vehicles on the street, pick up any that have been flagged by users as no longer usable. The middle part is tougher.
We have yet to see how scooter- and bike-share companies will manage, but for IT, we do have a working, proven solution to suggest. Moogsoft’s algorithms let IT operations understand what is important in their environment without being overwhelmed by noise, and how that relates to whatever else is going on. They let them make sense of their situation while operating at the speed their users require.
Those scooters are pretty zippy, after all.
