Microservices [video]

I love the joke. But, it is a serious problem.<p>One key part is that naming is important. This is always a fight I am willing to take. Acronyms, fantasy names, names of teams or legacy names that does not represent the functionality of the micro-service plague many companies.<p>If you will not name a method &quot;Jimmy&quot; or a local variable &quot;Galactus&quot;, why developers are naming their micro-services in such a bad way?<p>I do not know what I find more frustrating, the bad naming per se. Or the fact that the same developers would lose their shit if they saw this:<p><pre><code> class Galactus { boolean Jimmy; void turnOn() { Jimmy = true; } void turnOff() { Jimmy = false; } } </code></pre> Sometimes it feels that software development is more a religion that an engineering discipline. That there is rights and wrongs based in tradition instead of sound practices. That is why worse than the naming is the lack of self-introspection that let us here.

This was linked to me right after coming out of a meeting with my product team where I was the engineer in this video. Worse, I had a large hand in defining how our software architecture is designed so I can&#x27;t even blame other people. It&#x27;s largely my fault.

This was my exact experience working at Nike 4 years ago. In this scenario, I was the guy sitting. I got this type of &quot;talking to&quot; when I submitted a bug ticket because jQuery was being loaded 3 times on the same page.<p>The Nike.com software group was over 1,000 employees working on a microservices mess that performed horribly on the customer side. They could have built a much better product with about 50 competent software professionals.

For every microservices system I&#x27;ve seen, this feels about right.<p>It oversimplifies things a bit, though.<p>It&#x27;s odd; I&#x27;ve never seen a &quot;monolith&quot; simplified by moving to microservices, but everyone seems to be doing them.

Modular software is a great idea, always was; and fundamentalism doesn&#x27;t make software better, never did. Good ideas are compromises.<p>The latest system I designed professionally was an ordering system that&#x27;s divided into two parts; a local application with a database and an HTML document and a PHP script on a server.<p>The application itself doesn&#x27;t need internet access to work.<p>The data needed for the online customer order module is uploaded to the server via FTP as needed. Online orders are stored on the server and polled via FTP on request from the local application.<p>The result is modular, very easy to maintain, and performance is good enough to be considered a feature.<p>But the reasons for the choices I made are all about the problem being solved, not organizing developers and keeping them from stepping on each others toes.

We haven&#x27;t gone through the &quot;microservices&quot; craze for pretty scientific reasons: I dislike smug talking &quot;Chief Wizards&#x2F;Architects&#x2F;Scientists&quot; who&#x27;ve been writing posts and giving talks on architecture, clean code, and refactoring, based on that one project in the eighties. Reminds me of those phony martial arts &quot;gurus&quot; who are all about abstract ideas and &quot;energy&quot; channeling, complicating the simple to sell seminars and subscriptions.<p>Anytime something is discussed, we ask ourselves if that change will improve users&#x27; lives. I am sure these are useful for other people at different maturity levels of software, but it is not for us, right now.<p>This is why we don&#x27;t use React, Angural, Webpack and a ton of other things and libraries that are useful for others but add no value to us and only increase. We avoid adding complexity unless it&#x27;s <i>really</i> worth it, and worth it for the users, not to give us pleasure of using a new library. We have side projects for that.

The only 2 valid reasons I have come across for using microservices based system architecture:<p>1) There is a codepath in the application that has <i>radically</i> different load characteristics.<p>2) We want to give each team in the organisation ownership of (most of) their stack, release cadence, SRE etc.<p>(2) seems like an attempt at engineering but is often about management - empowering the teams yada yada.<p>There is a thread here about: &quot;Technology opinion-sphere is a FAANG monopoly&quot; aka &quot;Dude, we got like 3 paying customers!&quot;. I&#x27;ll leave that for another day.

The current trend of adding microservices all over the place feels an awful lot like DLL Hell. Don&#x27;t know if it will ultimately end up that way, but it sure sounds like a rhyme.

I remember reading a blog post some months ago here from a former AirBnb employee where they talked about how some senior manager in the company wrote an incredibly detailed spec for a CRUD feature which required them to invent a datatype because they insisted on using no more than N bytes to store some inconsequential field. There was also a description of how the author had to crawl through a parking garage to escape a meeting wherein he insisted that nobody was allowed to leave.<p>I feel like there is no accountability for these clowns. They&#x27;ll inevitably switch jobs and ruin the work lives of so many developers with their stupidity. There is a culture of not wanting to name your abuser for some reason. It&#x27;s weird.

Hey let&#x27;s design looking backwards and ignore all future needs. Everyone will be happy. Because they all are about saving face and give minimum effort, enough to keep things working as is. It doesn&#x27;t matter if it sacrifices future opportunities nobody can test that. Then it will be just a matter of fact. We will all just pretend this was unavoidable inherent complexity.<p>Imagine playing competitive RTS game and decisions were made with this attitude, tomorrow-not-my-problem as others don&#x27;t have domain expertise to tell otherwise or they don&#x27;t simply care to put themselves as opposing force and do your work to find better solution. In game you&#x27;d be doing seemingly ok and then get destroyed all of the sudden.

As an engineer, I am finding i very difficult to decide on things like capability&#x2F;modularity boundaries, layering constraints etc w.r.t architectural decisions for a B2B, cloud native, SaaS software solution. No matter what resource I refer to, there&#x27;s a lot of conflicting info.<p>Is there an equivalent of &quot;cyclomatic complexity&quot;(McCabe count of code) for cloud&#x2F;distributed systems&#x2F;μServices architecture? Cant find any such objective measure, apart from a few dated research papers.<p>IMO, it could be useful for many of us. Sometime back, I had tweeted tagging @copyconstruct and @kelseyhightower asking this question, but haven&#x27;t got a response - may be it went unnoticed.<p>Would love to get to know if there&#x27;s any such method&#x2F;framework to measure and manage architectural complexity, for the world in cloud.

Not exactly related to the video, but why do some people choose gRPC and others choose event sourcing for microservices communication? Is it just a matter of unneeded complexity in event sourcing? Are there performance issues as well?

I’ve watched this only about 50 times nbd

hits too close to home.