Last week I attended the O'Reilly Software Architecture Conference in New York City. While not "officially" a software architect anymore, I was keenly interested where the industry zeitgeist was regarding microservices, devops, and event-driven architectures. There was some very valuable information on tap (by the end of the second day I had a few thousand words in my notes file). But there was also a couple shadows cast; apparitions that still have me cringing a week later.
A session would begin by establishing a strawman: an omission or lack of proper design would lead to an undesirable consequence in production. In one case, for example, the presentation presented an erroneous decomposition of a problem. Rather than bounded contexts around a business capability, they jumped straight to resources, letting the data define the subsequent API design. The result was redundant data seemingly owned by resources, requiring additional data synchronization across the distributed data-sources; i.e. a "distributed monolith".
The presenter would then proceed to outline a more elaborate solution, one that required the initial design failure. The more elaborate solution would have a titillating sounding name, of course. It was usually some combination of yesterday's buzzword and an action adjective . My take-away from these presentations is that anyone is just a "hyper-componentization", "rational-serverless" or "pico-ops" away from a lucrative career in conference speaking and consultant fees.
The technical press is incentivized to unearth a steady stream of THE NEXT BIG THING™! The dopamine drip of discovering the bigger, better, and/or faster way of doing things is what drives attention to online publications, book subscriptions, and conference attendance. Too often, though, this seems to result in an industry that casts off yesterday's solutions as quickly as they can get tomorrow's promises. Rather than proceeding with care and practice after missing the mark, the solution, all too often, seems to be to find new silver bullets.
That phenomenon is unfortunate, and (probably) unavoidable. It is also, however, not the most challenging thing. Many of the presenters were proud (and, in some cases, rightly so) for demonstrating purely architectural solutions. Engineering conferences probably present developer solutions to the similar problems. I also guarantee that business folks are solving things from their perspective. While occasionally victories are possible, systemic success is not guaranteed because the problem is not being approached in a systemic, cross-disciplinary way. A company's business, culture, and technology are inextricably linked. Addressing one in isolation, without considering the push and pull of the others, is likely to doom an effort (or, at a minimum, impede it).
Take, for example, microservices. Microservices are, simultaneously, a software architecture pattern, a cultural change, and a business concern:
- Most technologists understand microservices as a software architecture pattern. Defining service boundaries through principles domain-driven-design for the sake of decomposition is a powerful thing. But only having the tech right doesn't mean microservices will be successful in an organization.
- Culture, as defined in the O'Reilly book, Microservice Architecture, is "a set of values, beliefs, or ideals that are shared by all the workers within an organization." If a employees do not trust each other, microservice coordination can't be minimized. If the organization values calendar release cycles tied to marketing blitzes, maximizing deliverable independence will be hard.
- Adoption of any new behavior must be tied to a business benefit. If the combination of speed and safety inherent with successful microservice execution isn't reflected in a business metric, it becomes "a tech thing". "Tech things" have a way of being entertained when times are good. However, when adversity happens, anything that isn't obviously tied to a business objective is in jeopardy.
It is a mistake to look at the success that Amazon and Netflix have had and attribute it to only one of these parts. Their systematic success requires systematic solutions. Succeeding with a new architectural paradigm, like microservices, means creating cultural, business, and technological change. Separating meaningful approaches from buzzword buzzards at single-discipline conferences is one thing. Having the position and/or professional network to holistically apply it successfully is another.
