One design pattern for an enterprise software business model creates an "off-the-shelf solution" to a complex problem. There's a big price tag. Also included is an equally big price tag for "support and services" to _customize_ the solution to _your specific business needs_. But wait! There's more! It also comes with compelling whitepapers and testimonials explaining your business need to you.
**The Age of Dot Bombs**
In 2000 I started at Spatial Technologies an established software company based in Boulder. They created the three-dimensional modeling kernel which was the heart of AutoCAD. I soon learned they were also suffering declining revenue, declining market value and angry investors. Only a few months after I started, Spatial sold their kernel and became PlanetCAD, pivoting into an Internet startup just in time to join the "Dot Bomb" age of Internet businesses.
Bloomberg says: As of November 19, 2002, PlanetCAD, Inc. was acquired by Avatech Solutions, Inc. in a reverse merger transaction. PlanetCAD, Inc., prior to the merger, was engaged in developing, marketing, and supporting cycle time reduction software solutions that integrated engineering processes and data for the manufacturing supply chain. link 
I was the lead developer for that "cycle time reduction software solution" though it was sold at the time as a "design chain management system" to riff on enterprise supply chain management systems. Today it would probably be sold with words like "dataflow management" or maybe "data pipeline".
It was a common play for failing businesses of the time to pivot from "Internet-scale" into "Enterprise Solutions." We had several really big _potential_ customers piloting our stuff. We answered a lot of feature requests from Black & Decker, Freightliner, and Caterpiller, but as far as I know none of them ever actually did buy the software after we'd built those "critical missing features." I also think at least one of those corporations negotiated a deal whereby PlanetCAD intellectual property was held in escrow to protect the customer in case PlanetCAD went out of business. That is one way for the big fish eat the little fish.
**The Sub-contract that saved the sub-contracts**
Some years later I worked for a small software consultancy. The two founders, Rob and Paul, are exceptional programmers, even more so working together. One of Rob's super-powers is discovering the customer's _real_ business problem instead of the "solution" they think they need. Paul can see the simplest way to solve a business problem and he's never distracted by "cool" or "flashy". He "just" solves one business problem simply and moves immediately to the next business problem.
A customer asked them to help convert a huge pile of XML documents from their current schema to another schema.
"Why do you need to do that?" Rob asked.
Apparently the target shape of the data would make it fit into Documentum.
"Why do you need to do that?" Rob asked.
Apparently, there was an upstream sub-contract of a sub-contract of a sub-contract. Somewhere up the chain, Documentum would be used to convert this XML schema into yet another schema. Rob continued asking "why?" and learned that ultimately the Federal Aviation Administration needed these docs in specific format.
Paul spent a week on a small-ish perl script to convert the whole pile of XML documents into the final schema needed by the FAA, thereby rescuing a whole chain of failing sub-contracts and saving the day.
"Well, why did we need to spend a million dollars on Documentum then?" asked someone in that chain?
"Why indeed?" asked Rob.
.
Conversations for Platform Earth motivated me to reminisce here. Several solutions have been proposed coordinate microservices: DreamFactory, Mule ESB, and Istio. DreamFactory has a nice picture of the problem and proposed solution that all three of these things are offering. The picture is more valuable than the words. On the left (and bad), a clearly tangled web of point-to-point REST APIs. On the right (and good), put Our Platform in the middle for clean and untangled joy. And colorful arrows pointing you helpfully in The Right Direction.
Transported image.
source
It so happens, this is almost exactly what I was building for PlanetCAD. The technologies under the hood for Mule ESP are especially familiar: tried-and-true enterprise java systems. Back in the day these were known as Message Oriented Middleware and then Service Oriented Architecture. Those always felt like views of the same system... one looked at the messages, the other looked at the things sending & receiving messages. Even the idea that non-programmers would be able to connect the services into workflows that would allow your engineering data to move seamlessly from start to finish is familiar. These days we retrace the steps of the Java community at the OS level instead of inside or between JVMs. We use docker containers and microservices and orchestration. Kafka is often used now where JMS and various message queue solutions used to live.
Rob would ask us - why do you need to coordinate microservices? - how many microservices do you have now? - what is it you're actually trying to do? (microservices might not actually be what you need)
At the time I worked with Rob and Paul, the most complicated software-as-a-service we were running managed the formal balloting for IEEE Standards Association. IEEE SA basically provide the governance for all sorts of different engineering communities to argue about technical standards. Their business is extremely political and extremely technical and part of their business model is keeping clear documentation for _when_ they get sued by the businesses who loose in some standards negotiation.
The second-most complicated software-as-a-service is an investment club accounting system -- the same difficult math problem as mutual funds with the added complexity of the United States Federal Tax Codes and many State Tax Codes for limited partnerships.
There were at least a dozen other projects in production at the same time and hosted on the same infrastructure.
All of this deep complexity and production-critical code ran on, I think a total of *six* servers, all of which had been bought used, and which Rob later described as "total overkill." It was basically a redundant pair of load-balancers, application servers, and database servers. That basic 3 tier thing was sufficient for a pretty large scale.
**These Days**
Everyone seems to think you have to _start_ with kubernetes which wants at least 3 VMs.
I think Docker brings enormous value to the table for creating consistent and reproducible systems configurations. It basically lets everyone enjoy what Java has been doing for decades, without having to write their code only in Java.
I think kubernetes is both awesome and overkill. Which is also to say, I expect the complexity of kubernetes itself to be too much to ask of most coops anyway.
And that gets me to the heart of my position here. I think we need to build something like coop services for the rest of us, not something enterprise-scale.
In fact, I think the patterns that make sense for enterprises are almost certainly _exactly opposite_ of the patterns needed for the commons. Enterprises are all about centralization and command and control and their software systems pull in exactly those centralizing directions.