Integrating Ceph and Kubernetes is complicated and needs a GUI

Take a trip with me back in time to the early ’80s. I had my first computer, a TRS-80 Color Computer (a.k.a. CoCo), and a subscription to the newly minted Rainbow magazine. (Rainbow…for color computers…get it?) The first edition of The Rainbow was a one-pager, front and back, from a dot-matrix printer. The magazine came with features about programming, and every edition had a few programs you could key in for yourself to see what would happen.

You could also buy games that someone had already typed in, um, coded. The Sands of Egypt was one of my first purchases. You could load from cassette tape or 5 1/4" floppy disk. Innovative. To play the game, you typed instructions, and the game would interpret what you typed, as if by magic.

Obviously it wasn’t magic. The parser could understand a programmed set of instructions. Type “GO NORTH” or just “N” to move one scene to the north. (It’s not that you were shouting GO NORTH. At the time, keyboards didn’t offer lowercase letters.)

Now that I think of it, that was one of my first experiences at a command line. The game had simple graphics of desert, pyramids, and snakes, but all of the action took place via keyboard by typing verb/noun combinations. The range of the instruction set was kept a bit vague. Also, you had to keep your own maps of the game world terrain. You also needed to figure out how to survive. Pick up the canteen, walk to the oasis, fill the canteen, drink.

As a cerebral adventure game, puzzling through it was a big part of the fun. “FUN” The game was programmed with “an extensive vocabulary” that you mostly had to figure out on your own. Finding a word combination that it recognized involved experimentation and a bit of luck. On the other hand, not finding the words led to frustration and giving up. I am almost certain that I never won the game.

In contrast, Atari had Adventure. In that game, you used a joystick to move, and everything was visible on your television screen. All you had to do was find the chalice – while avoiding the dragons – and return it to the castle. The game also had puzzles to solve, like picking up a sword to slay the dragon that was guarding the key to the chalice room. Spoilers. Maybe the kids who had Atari didn’t learn how to write software, but their games were way better. When Ms. Pacman came out, I spent a large portion of my summer vacation at my neighbor’s house.

Enough living in the past. Let’s return to today.

Who would believe that 40+ years later we would still be tapping away at keyboards? Shouldn’t software be writing itself by now? Short of that, why isn’t everything more like the movie Minority Report? We should be waving our hands around in the air to manipulate holographic user interfaces (HUIs?).

Instead, in IT we are interacting with dozens, maybe hundreds, of software tools mostly at the command line. Most tools have extensive capabilities, and the best have a well-designed command-line interface (CLI) to match. Each tool has at least a few options for handling different conditions and use cases. Options are enabled with flags or text-based configuration files. As a baseline, this makes sense.

Why stop there? Why not provide a graphical user interactive? Why not make the options available from drop-downs and fields with validation? Complex systems need an interface that reduced complexity and helps the operator understand what can be done. With only a CLI, the operator has to pour through documentation in search of the the magic words that make things happen.

Those who develop software tools know what happens. First, you need a CLI while you get things working. That is still the easiest way to tell your programs what to do. You tend to sort out the instruction set iteratively as you add features.

Then, by the time your tool is loaded with functionality, crafting a GUI is a lot of extra work that seems redundant since the CLI already has a way to do everything.

That logic has at least one flaw. Anyone who hasn’t been following along, which is to say most users of tool, is going to face a learning curve. Have mercy if that curve is too steep, or if the incantations for what they are trying to do are not spelled out in the documentation. (Surely you have great documentation, right?)

To matters worse, often new users have to adopt multiple tools at once and face as many learning curves. When something goes wrong, they have no way of knowing whether the problem is the tool, the combination of tools, or their own inexperience. Probably a puzzling combination of factors.

For example, take Kubernetes. If you are like me, the first time you tried the mighty K8s, you were faced with a dozen new CLIs. For any given Kubernetes setup tool, the “Getting Started” guide lists prerequisites that take you to more tools and more getting started guides. Hitting a snag with any one of those can be a show-stopper.

Once all of that is settled, you can start playing in the K8s environment, where it’s all CLI commands and yaml configuration files. Based on my experience, the odds of getting things set up in the first go are about 0.000001.

Kubernetes needs a GUI. Give me a wizard that takes me step-by-step, explaining what needs to be done, laying out my choices, and giving me a few buttons and drop-downs to make it all easy. That still won’t be “easy” because there is a ton to understand. But someone somewhere has this knowledge. Do us all a favor, and build the GUI that brings that knowledge to the surface.

Next, I can take my argument a little closer to home. I am the CTO of a start-up that is based on Ceph data storage. We are maintainers of Rook, which connects Ceph storage to K8s environments.

If K8s is complicated, Ceph is overwhelmingly complex to anyone who is unfamiliar with how data is managed at the disk level. Genuinely, I am impressed with the level of technology that the Ceph community has put together to do amazing things with data storage at massive scale. It’s awesome. It’s also terrifying.

By the time all of that code is working, and with a steady stream of improvements to work on, the team of volunteers barely has time for documentation. That is not a knock on the effort or the documentation that there is. The problem space is enormous, and keeping the documentation organized and up to date is a daunting task. Who has time to build a “mostly redundant” GUI version?

Except that a GUI shouldn’t be redundant. Take the analogy of an automobile steering column. All of the electronics for telling the car what to do are transformed into buttons, levers, and nobs around and about the steering wheel. The wheel itself points the auto in a direction you hope gets you where you are going. You don’t have to go find the right wires to get things to happen.

In other words, a helpful GUI will mask complexity by bundling options that go together and that take you in the right general direction. That simplification is anything but redundant, even though the outcomes should be the same with either approach.

In fairness, Ceph has a dashboard that gives you a good sense of what is running and how things are operating. There are notions of being able to update things via a GUI as well. So the thought is there if not the capacity to devote to it.

In parting, I leave you with two thoughts about what holds back GUI development for tools. First is that the programmers who can build great tools may lack the skills and knowledge to put together a decent GUI. UX is its own specialization. Getting a UX designer and GUI developer to collaborate on a data project does not happen by chance.

UI tools these days ship with graphical tools - dev tools, code pens, playgrounds, etc. - tools for trying out the tools. Why can’t infrastructure devs have nice things like GUI devs? Because GUI devs know how to make GUIs.

Second, people who work on tools for serious work—like keeping data corruption free—are naturally risk averse. Adding another layer to the development stack adds a layer of risk. What if the GUI introduces errors and confusion that make it even more difficult to make things right? Or to troubleshoot when they go wrong?

What if someone codes a Self Destruct button (with the best of intentions) and gives it a tempting “EASY” label? By making things easier, a GUI can make problems happen more quickly.

We can agree that adding a GUI requires extra effort and a degree of care. As with all software development, if we start with limited functionality and incrementally build upon a stable base, it can all work out in the end.

Now go play some video games. Life is short.

If you manage your own data storage, you might want to try the Koor Data Control Center. It’s a monitoring, management and automation GUI that makes it easier to operate large-scale data stores yourself.

By simplifying the deployment and use of Rook Ceph, Koor Data Control Center helps medium-size and large businesses take back control over their data storage and management. Sign up for a free trial of Koor software or subscribe to Pro.