This is the second episode in a series of posts reviewing the first Global Software Architecture Summit that took place in Barcelona the 10th of October. To see the whole list of episodes, please visit this.
Applying architectural principles, processes, and tools
The second speaker was Len Bass (@LenBass4), who started by giving us what seemed to me a first-day lesson in college on the 5 key characteristics a software architect must be proficient in, but when the time for questions arrived, dropped plenty of valuable thoughts.
One of the main vectors of change in how software is created has been the recent incursion of Operations in it. Traditionally, developers cared very few of how the code they produced was actually run. Since the DevOps, the role of developers has evolved quite quickly, and right now a developer who does willingly ignore the operational part of the software gets (or should get) easily unemployed.
Which, incidentally, drives in another of the main leit-motives of the whole event: which level of architectural complexity should we accept because of that invasion of Operations in software. Illustrated with the neverending monolith versus microservices debate. Some of the speakers in the debates were contrary to the adoption of microservices and others were in favour of them, if and only if microservices fit the problem and context. This latter seems a pretty cautious position to me, but definitely it was not conservative enough for those who complain every time things evolve faster than they can follow.
We will have time to come to this again. Before that, I would like to note three other thoughts from Len Bass: one was the idea that it is very rare that software crafters participate in the creation of any application which is not similar to other applications already created. An example of a true novelty is the Amazon’s invention of a bunch of new technologies, tools, and procedures in its seek of Infrastructure Scaling. In general, though, we should keep ourselves aware of what other people is doing all the time, as well as being open and communicative so that others may also benefit of our work.
A second thought is that log files are quite more important than we think: log files mainly exist to help first responders in case of an emergency. But they also help us gather deeply valuable information of our software’s behaviour. Which reminded me of Observability, a field that fascinates me for its promise of providing us with the ability to query the system any time, and which depends on log files to deliver its magic.
For those also interested in Observability, I highly recommend this introductory page in the Honeycomb website (I have no liaison with this particular company, except by the fact that I got completely mesmerized by a speech of their former CEO, and current CTO, Charity Majors, back in 2018 in London). There is a podcast that I follow too: o11ycast. And a conference, O11ycon, which happened in San Francisco last year. Slides and videos are free to access online.
A third idea that Len Bass said that shocked me was that Microservices potentially drive technology inconsistency into our application ecosystem. This is a common criticism, though I doubt that it is fair. It seems reasonable to assume that there is a limit in how much diversity organizations can handle. Where this limit lies on, and why is the blame put on microservices when they just expose this limit, are the two factors that look unfair to me.
Bearing in mind that Microservices allow organizations to isolate disparate technologies as long as they communicate via standard protocols, like HTTP or asynchronous messaging (by the way, another schoking moment was when someone in the audience asked a question in a way thay made me think this person believes microservices are asynchronous per se, which is wrong), the potential incosistency in adopting those disparate technologies cannot come from them as an architecture style. For it is completely possible, even reasonable in some contexts, to adopt microservices using just one technology.
I believe that microservices allow us to pick the technology that best fits in every case, but this is my believe, not something that microservices force organizations to do. And even I accept that this is an ideal: in practice, the resources are scarce, and organizations must focus on less than 5 technologies. I worked in a company where even more than 5 thecnologies were in use, and everyone was aware of the reasons why, but I do neither recommend that, nor see it happening a lot. On the contrary, my advice would be to focus on the operational, and the infrastructure, issues, get skilled on that, before bringing in additional diversity.
In my opinion, inconsistency comes out of us making bad decisions, not by the adoption of any particular architecture style. Microservices, as any other architecture style, are neutral, optional. Pick them if that fit your needs, simply ignore them if not.
Copyright notice: Featured picture taken from the Haproxy website without permission
how possible 