“Microservices and API Complexity – Inside and Out” on Iasa Global

The signature benefit of a microservice architecture is that its highly granular nature allows for a great deal of flexibility in composing applications. Components are simplified by virtue of a high degree of focus. The ability to replace individual components is enhanced by the modularity inherent in the style.

A very significant drawback to microservice architecture is that its highly granular nature can lead to a great deal of complexity in composing applications. Highly focused components can force service consumers to become more involved in the internals of an interaction than they might otherwise wish. Unwanted options can become more of a source of confusion than useful modularity.

How do you resolve this paradox? See the full post on the Iasa Global Site

Advertisement

“Laziness as a Virtue in Software Architecture” on Iasa Global

Laziness may be one of the Seven Deadly Sins, but it can be a virtue in software development. As Matt Osbun observed:

I often refer to myself as a lazy developer. Occurred to me that people might not get the reference. http://t.co/zmjDZjkTd6

—
Matt Osbun (@MattOsbun) February 06, 2015

Robert Heinlein noted the benefits of laziness:

Progress is made by lazy men looking for easier ways to do things. - Robert Heinlein #quote

—
Tim Fargo (@alphabetsuccess) February 03, 2015

See the full post on the Iasa Global Site (a re-post, originally published here).

“Microservice Architectures aren’t for Everyone” on Iasa Global

Simon Brown says it nicely:

I'll keep saying this ... if people can't build monoliths properly, microservices won't help. #qconlondon #DesignThinking #Modularity

—
Simon Brown (@simonbrown) March 04, 2015

Architect Clippy is a bit more snarky:

I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of microservices?

—
Architect Clippy (@architectclippy) February 24, 2015

In both cases, the message is the same: microservice architectures (MSAs), in and of themselves, are not necessarily “better”. There are aspects where moving to a distributed architecture from a monolithic one can improve a system (e.g. enabling selective load balancing and incremental deployment). However, if someone isn’t capable of building a modular monolith, distributing the pieces is unlikely to help matters.

See the full post on the Iasa Global site (a re-post, originally published here).

“Microservices, SOA, and EITA: Where To Draw the Line? Why to Draw the Line?” on Iasa Global

In my part of the world, it’s not uncommon for people to say that someone wouldn’t recognize something if it “bit them in the [rude rump reference]”. For many organizations, that seems to be the explanation for the state of their enterprise IT architecture. For while we might claim to understand terms like “design”, “encapsulation”, and “separation of concerns”, the facts on the ground fail to show it. Just as software systems can degenerate into a “Big Ball of Mud”, so too can the systems of systems comprising our enterprise IT architectures. If we look at organizations as the systems they are, it should be obvious that this same entropy can infect the organization as well.

See the full post on the Iasa Global site (a re-post, originally published here).

“Microservices, Monoliths, Modularity – Shearing Layers for Flexibility” on Iasa Global and a Milestone

First the milestone – this is my 200th post since starting this blog in October, 2011. I look forward to many, many, more (and hope my readers do as well!).

And now for the meat – “Microservices, Monoliths, Modularity – Shearing Layers for Flexibility” is up on the Iasa Global site:

Over the last fifteen months, many electrons have been expended discussing the relative merits of the application architecture styles commonly referred to as microservices and monoliths. Both styles have their advocates, and the interesting aspect is not their differences, but their agreement on one core principle – modularity. Both camps seem to agree that “good” architecture is modular and loosely coupled. The disagreements lie more in the realm of whether the enforcement of modularity via physical distribution is worth the increase in complexity, latency, etc.

read the rest there

“Microservice Mistakes – Complexity as a Service” on Iasa Global

I’m pleased to announce that I’ve been asked to continue as a contributor to the Iasa Global site. I’m planning to post original content there on at least a monthly basis. In the interim, please enjoy a re-post of “Microservice Mistakes – Complexity as a Service”