Why I'm No Longer Talking to Architects About Microservices

Code monkey is really the more accurate term. Not even slightly kidding here.

The latter seems to occur and mature in software more.

Personally I think software engineering is absolutely engineering, it just has mostly different constraints from physical engineering. Most of this has to do with the dealing with the costs and consequences of building things in the physical world. Without those disciplines, a huge capital cost goes into building a bridge that fails, or an expensive machine that can't do its job. We also have to account for the limitations of physical materials and a harsh environment, which are in some ways harder to account for, but also more stable as a well-understood substrate than pure software (ie. all animals have some intuition about physical things, physics doesn't change, materials capabilities change slowly, etc).

When folks lament the lack of "discipline" in software engineering I think it's a misplaced, grass-is-greener sentiment that hasn't really been thought through. The reality is software has different constraints, not harder or easier, just completely different apples to oranges differences. For instance, durability and maintenance in physical objects is about material properties and physical wear and degradation from the operating environment, whereas software bits are infinitely durable and replicable, but they get broken by the environment itself since they have to interact with thousands or millions of other software artifacts created over many decades. With physical engineering it's mostly about discrete objects with natural and intuitive encapsulation that are in a sense "immutable". Some software is like this (like pre-internet console video games shipped on cartridges), but typical cloud-based software is nothing like this, it's a constantly evolving tangle of interconnected logic and ever-growing data used for widely heterogenous purposes, often never fully understood by any one person or entity.

This messiness is one of the frustrating things about software, but it's also its strength. Anyone that tries to declare rigid civil-engineering-style discipline to software will not survive in the marketplace because most software is not life-or-death. The discipline put into the Mars Rover or the Therac 25 successor would simply be overkill for average software. That said, of course there are cases where the importance and impact of software correctness is unknown, like if the government were to start using social media sentiment to impose real-world consequences on its citizens, but these types of considerations are much more fluid and harder to nail down than physical properties like "will this bridge stand up for 50 years". Software engineering in my view, is about leveraging the malleability of software to solve problems in a constantly evolving landscape. We're not just standing on the shoulders of giants, we are directly calling their APIs to solve new problems they couldn't even have conceived of. One could argue this is too broad to really be "engineering", but I can't think of a better word to describe the highly technical process of understanding and solving problems with software.

Anyway, it's not really so surprising that there are few hard and fast and replicable rules in "software engineering" as there really aren't in, say, essay writing. There are best practices and tips and techniques that are generally more effective than others. And there _are_ actual constraints around software that don't exist around essay writing as, ultimately, software does have to translate to real physical limitations like available memory and such, but the abstraction away from those physical limits is by and large the point and purpose of software.

All patterns & practices come with their benefit and drawbacks. So all decisions are very much dependent on the circumstances. This is what you called "local maxima".

The organizational costs come from communication overhead between engineers: Sync or maybe async calls within a codebase turn into an ad hoc distributed system, where a different team (and maybe different management chain) owns each network endpoint.

In the end I think that microservices are not a big deal. It’s like choosing your programming language or choosing whether you want to use object-oriented programming. These decisions all have impact, but they generally aren’t revolutionary decisions. Object-oriented programming didn’t give us a massive wave of reusable code. Rust hasn’t unlocked some new, previously unseen level of developer productivity. Microservices are the same way.

The reason things shift for software is because they can and because there's no 1 "right" solution to almost any problem. There's no 1 correct way to represent data. And when we've tried to do that in the past (see SOAP) it ends up in a wild spaghetti mess of standards that tend to hamper development rather than speed it up.

There's also the very real problem that users of software LOVE to work around standards to the point where they create their own standards that ultimately end up needing to be supported in software. I can't tell you the number of times a "description" field in some set of data has ultimately ended up needing special handling in our data normalization process because an end user has decided "When I mark foo with this, it's actually a bar and the system needs to handle it slightly differently". To which our POs are happy to oblige. Often because software we didn't write is what the users are interacting with to send us data and the "description" field is the only thing they have the power to change.

> Are these not immediately obvious impacts to the business?

Depends; for b2b loads all those concerns but the final one can be be met with a single beefy server for DB writes, with multiple read only replicas.

Run multiple instances of your monolith app behind a load balancer and you should be good for maybe 100k users working on that app at mostly the same time.

With care (redis serving session data) this is fine for even very high loads.

Once you start doing b2c and have millions of users logged in and doing stuff at the same time then those concerns are valid.

At very least, having clear boundaries on data ownership is something I really wish my company had done from the start. We have legacy structures that are very hard to iterate on because they get loaded by ~20 different applications directly from the database. That means any minor change to that structure requires careful planning and roll out of the shared library to these 20 services.

Were these behind a service, we'd still have to negotiate the structure (we could, for example, delete a field willy nilly) but we'd be able to add new fields to the structure or change the way those fields are populated to meet current business requirements without a mass rollout.

I do think the micro/nano approach can often be wrong. I think a service should be as big as it should be to cover the domain it's dealing with. But, importantly, who owns what bit of information is by large the most important thing to get right.

I also have a working definition of a microservice, which is that it is a functional part of a system which exposes its functionality to other parts of the system via HTTP. This works for my team.

In general, we shouldn’t fetishize any particular technology, idea, or phrase. If a term obfuscates more than it clarifies, it’s not very useful.

I personally don't believe at all in microservices, at least not in the organizational sens, I do not mind e.g. genservers in Erlang but then teams owns many of them. But that said this trend is not proof that they are bad, just that they do not magically solve the problems.

I could watch it happen in real time. Person A would advocate a position on one of those items, and their nemesis on the team, B, would then build their whole personality around being against that position. They would adjust every existing belief to now fit their new perspective. It would become boringly predictable.

So when someone is really passionate and certain about something like this, my natural thought is "who hurt you?". Especially on something as amorphous and hard to pin down like microservices where it's easy to attack it from a hundred angles that likely have no relevance to an actual implementation.

Like, it really doesn't matter that much. You can make an excellent solution using almost any approach. You can use all sorts of frameworks and languages and platforms, etc. It'll all be okay.

That sentence is doing a lot of heavy lifting.