Skip to content

System architecture reflects businesses and teams

Over coffee with a student from back in my coding bootcamp instructor days – said student is now a half-decade into their software engineering career and thriving as a senior engineer at this point – we stumbled into a discussion about essentially “Why microservices?”

The thing is, as I explained at the time and will in more detail here, lots of seemingly technical decisions aren’t really about the technical merits. They’re often about the business or team environment at the time.

Or they’re cargo-culting. A lot of that goes around, too.

In my career, I’ve worked on monoliths, massive rewrites, and microservices. Looking back, each one was a reflection of the team and business that was building the software.

An illustrative example:

We were building a new product inside of a venture-funded software startup, based off the bones of another, failing VC-funded startup.

We started off using their technology stack – one filled with “neat” and “interesting” bits of technology that could be chosen because they had no customers, and there was no downside to building a thing on top of a pre-1.0 graph database using a still-wet-around-the-ears programming language.

We started pumping a massive amount of data through their proof of concept system built on speculative tools and, as could probably be expected, the whole thing fell down.

And this was three months ahead of our planned launch of the product – timed for a conference – and right at the start of a planned beta program for it. The data that brought it down was the first few beta customers and testers.

I was leading the engineering team at the time and was faced with a choice: Try to rescue the existing codebase and technology, or replicate a lot of the bits of it from scratch.

After hedging our bets for a bit – trying desperately to get the database up and running while simultaneously spiking out a fresh version – we decided to commit to the new way.

From a dead start in May, we were facing an August deadline.

What I had available to work with were:

  • An in-house team that was split between the new product and maintaining the existing product line
  • Some contract bandwidth from the other, failed startup’s team, who knew the logic behind their application and had built it once already
  • An expandable team of offshore developers in India who knew javascript and node
  • A kickass devops lead who knew entirely too much about Kafka

What I’m describing here is not a technology problem, it’s a business problem.

How do you take those ingredients and get this done in this time frame?

The only way I could make it work was by managing concurrent work streams. And ensuring that we made decisions as few times as possible.

So, we settled on a microservices approach centered around Kafka, and settled on a core list of technologies – Ruby because that was the existing team’s wheelhouse, node because the contract resources could use it reliably (even if the other startup team might grouse about it), and Elixir because it looks like Ruby if you squint and we needed a little oomph in performance for some of the work.

We wrote down our principles ahead of time – what a micro service was and how we expected it to operate, what the minimum requirements were.

And off we ran. And finished in time.

It ended up being an architecture that ran relatively pain free, and we gradually started peeling off pieces of our existing monolith(s) to use the new system instead.

But, tellingly, that architecture is an outcome of the business problem – build this in three months – and the available ingredients – a lot of commodity development resources, and some specialized (and useful!) internal resources.

It wasn’t because “microservices are cool” or “So and so uses microservices, so it must be a good idea. It’s vetted.”

If the business problem was different, maybe if we had a year to build it for instance, my decision might have been different.

If the resources available were different, a bigger internal team or less devops horsepower for example, the decision certainly would have been different.

Good technology decisions are based on business context, not warm and fuzzies and not on whatever’s hot today.

They’re based on the shit that has to get done – and what resources you can get to do the work.

If you’re in an environment where you’re unsure of a decision that’s been made, take a step back and look at the business context, and you might discover why things are the way they are.

Or you might discover a crate of cargo fell out of the sky and now you have to run Kubernetes locally.

Leave a Reply

Your email address will not be published. Required fields are marked *