Technology Doomed to Repeat Itself

Second Verse, Same as the First, Just a Little Bit Worse

So, we’re now at the next phase of this game: maintaining these very complex systems is hard and not your core business, so outsource it (simplifying it would cost too many managers’ jobs, so that is not an option). The Cloud was born, first as a marketing label for an old business model (offering “virtual private servers” to the public), but more and more as a marketing label for an even older business model (the mainframe - we run it, we own it, you lease capacity).

Once upon a time, I made a nice little Rails application—Sipity. For reference Sipity is about Submission Information Package (SIP 📖); and “-ity” brings a playfulness. A dream of mine was to make Sipity Do Da, a processing system for these workflows.

I love that application. Seriously. When I go back to it, I smile. It’s playful name helps, but so does extensive documentation, robust tests, and architecture diagrams.

Yes, it has tech debt. But, it’s predictable and consistent.

I can fire it up and it’s entire test suite completes in under a minute. And I treat anything less than 100% code coverage as a broken build. This means I get rather quick feedback on the system.

I’ve repurposed the database structure, because at it’s core it answers the authorization question: “Who can do what and when.” And all of the associated questions that come with state-based permissions.

These days, I look at it’s class/module structure and think “Wow, I wish I had a mandate to tease out more functionality and greater abstraction.”

I’ve got ideas, and they most certainly are ideas thought by others in years prior.

But, alas, Sipity, you’re not one of the cool kids. Instead, you just work, and get your job done, with minimal fuss. When we need to modify you, we dive back into the diagrams, paradigms, and documentations. We make a few incisions, and poof you do your thing.

And what is that thing? Sipity, at its core, is a multi-user task list with state-machine sensibilities. I do a thing, you do a thing. We advance the state of the object so others can do their thing.

Right now, its the backbone of an Electronic Thesis and Dissertation (ETD) approval and deposit process.

Please give me a moment to humble brag. In the semester we launched this service, through some coordinated communication, we did so with minimal fuss. Everyone started using the system, and it provided a common entry point and approach. Rarely, if ever did help requests escalate beyond the tier 1 tech support.

In other words, we rolled out a new service on campus, and didn’t create many noisy problems.

Heck, we even incorporated cataloging services into this process with minimal fuss. (Hint: Give cataloging services some space to speak their concerns. Listen to their concerns and move deliberately with their concerns. They might experience change more viscerally than you, give them space to share it. Paint the picture of what a future state looks like, and walk with them in this change.)

It’s ready to be so much more; all of the organizations that I know of need a state-based todo list with notifications and dashboards. They have a need for one person to do something, hand it to another, maybe send it back, and ultimately manage the movement of information.

This modeled flow of information facilitates the core business of many organizations.

Sipity runs as a glorious monolith: predicatable and contained within its boundaries. Sipity is ready to expand it’s utility, but rests currently on the back burner as the bright shiny of serverless (e.g. main frame computing with hideous orchestration) struts like a peacock.

In principle, serverless is wonderful. It runs as lambda functions at scale. But lets really be clear, do you actually have “at scale” problems, or do you have resourcing problems (e.g. not enough systems-oriented developers).

Microservies and serverless add to the cognitive overhead of what your creating. And I’d wager that cognitive overhead is not aligned with the core functions of your business.

Reflect and ask yourself: What unholy monster are you creating in your orchestrated microservice labyrinthine hell?

Yes, the monolith is complicated. But I’ve worked to delineate responsibilities and document the architecture. It’s logically consistent. Contrast the platonic promise of Servreless; easy to test in isolation, but hell to orchestrate.