Analysis of Software Architectures

Related: "The Architecture of Open Source Applications" (http://aosabook.org/)

They've recently released new chapters of the upcoming fourth volume.

This analysis brings to the front a personal frustration, and I imagine it's not unique to me.

This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don't have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM).

The issue with the CoA is that it cares more about buzzwords than quantifiable claims or objective measures. CoA was once addicted to microservices, when that model failed it'll be "all about" another, and so on. Rife with academic good-sounding CoA words that nobody can argue with like "SOLID" and such.

To be a little more concrete, "Broker topology" is a 25-cent word for a 1-cent idea (and it's not the only one, see every keyword in bold in the page, it's almost like a college textbook). There seems to be an implicit assumption in CoA that there is a finite number of architecture patterns and they must be learned by name.

Again, to be more concrete, "layered" architecture is an oversimplification of a fundamental idea (abstraction) in engineering.

This textbook-esque presentation also really misses the spirit of coding. It presents a UML (another CoA must) of "Event-Driven" architecture, then one of "Layer" Architecture, without really explaining if these can be combined or are mutually-exclusive (of course they could be combined). But by treating them as named nouns it creates a misleading and complex language around fundamental ideas.

This articles makes the assumption that features are easier to develop if subsystems are broken up into separate components, with separate data sources and deployments.

But experience shows that this is only sometimes the case. Monolithic applications with a big SQL engine as the backend have the advantage that you can do joins very easily. If the data is split into three microservices, you spend much more time thinking about how to do the these cross-service joins more efficiently, narrowing down the amount of data you have to fetch from the other services and so on.

People argue that cross-service joins should not be necessary, but that's also easier said than achieved; in reality, they tend to show up, no matter how carefully you partition the services.

Also this article isn't as good as it could be. too much happiness about micro services. Microservices makes more sense in a bigger team than in a small team. A small team can't work really easily with a codebase that is splitted too much (and with small I mean less than 10).

A startup should ALWAYS start with a dumb monolith

Regarding microservices. They sound nice in theory, and certainly work for some cases. But what is the common pattern to handle a situation like this (in a performant and "scalable" way).

Say you have two (completely separate micro-) services:

- Order service - Customer service

Now when a customer buys something, it is stored in the order service. But how is the customer information referenced in the order service? Do you store just some "customer id" and let the clients of this service worry about what it means? Or do you store some customer information also in the order service (in memory cache or in the services own datastore, both solutions which then need to synchronize this data somehow)?

Eg. how about a situation where you want to display a sortable list of orders, and it includes the columns for the customers first and last names. How can you sort on these columns if the order service doesn't know anything about the customer other than some "identifier"? Especially if the list is paged so you can't look up all the needed customer's information.

Just thought about this because this article (and many others) tout microservices as some kind of silver bullet.