Service-Disoriented Architecture

Indeed.<p>CRUD apps (which I&#x27;ll argue are the vast majority of applications) are easier to write, easier to understand, and easier to make have the behavior users expect when there&#x27;s only one datastore and you never have to deal with eventual consistency or distributed or half-applied migrations.<p>As an anecdote, at a previous employer, we provided user accounts and OAuth for connecting these accounts to our API. We made separate user and OAuth services, with separate databases.<p>What resulted was an unnecessary amount of complexity in coordinating user deactivation, listing OAuth tokens for users, delegation, and doing all that while authenticating requests between microservices. Our API could not safely expose a method to deactivate a user and all of their OAuth tokens in a single DELETE. A single instance that handled both would have been easier to build and wasted less time up front dealing with complexity that we didn&#x27;t need or make good use of for our scale at the time.<p>To solve this, we eventually merged all the data back into a single database, so we could expose sane invariants at the API level without needing to build an eventually-consistent message queue.

I will be the guy bringing Erlang (or more precisely BEAM -the Erlang VM- and the various languages that run on top of it) into this thread... But it&#x27;s amazing how much Erlang got right so long ago. Erlang applications are effectively fine-grained, Service Oriented, with a very low overhead.<p>There is, of course, one drawback: you loose the low overhead advantage as soon as you step outside of the Erlang world. That&#x27;s a major drawback given that a non-negligible part of the Service Oriented Architectures appeal is the possibility to use the best possible tool for a given job, no matter what language&#x2F;VM&#x2F;hardware that tool is built with...

Ah, it seems we have moved to the deprecation phase of the buzzword lifecycle. Consultants and pundits would be well-advised to begin seeking the next thing.<p>Meanwhile, those of us who actually build systems will probably continue to make all our services as small as possible, and to compose systems from discrete processes that may or may not require more than one computer.

This discussions tend to focus on the two extremes.<p>What are best practices for making monoliths ready for future SOA design<p>- Workers listening on event bus<p>- Database queries abstracted in RepositoryObjects<p>- ServiceObjects isolating domain logic<p>- Specs isolated around concepts<p>- Extracting to plugins (eg vendored gems) if not part of domain logic<p>What are your recommendations?

While the overhead of SOA is pretty well documented and understood, I feel like this is the crux of it: &quot;Adopting a microservice architecture does not automatically buy you anti-fragility.&quot;<p>Not only do you have new, hard problems -- but you didn&#x27;t just innately get a solution to your previous problems. I&#x27;ve seen this in practice, and it is pain, all around. There&#x27;s immense organizational overhead to having your core product distributed across 4x as many projects&#x2F;repos&#x2F;components as you have developers. And if you haven&#x27;t <i>actually</i> solved all the fragility and failover problems, you are <i>very</i> fucked.

A common pattern I&#x27;ve seen with companies sprinting head-first into a microservices architecture is something I call &quot;femtoservices&quot; -- when your system is new and doesn&#x27;t do much, it&#x27;s easy to split things up into components that are way too small. I&#x27;ve seen systems that essentially have a microservice per database table, effectively destroying any reasonable way to perform non-trivial queries. Fixing this is far harder than splitting out a monolith that has been designed well.

It seems like an endless cycle of some new trend coming out (microservices), then the reactionary comments which create even more new trendy buzzwords. Application design and development is not this black and white. SOA is not GOOD or BAD. It is a design structure that some people like, and some people seem to hate. There are good ways of doing things and bad ways of doing things. In my experience, having small manageable code bases that are responsible for one domain makes things so much easier to develop and maintain. But, that is my opinion not something I think is a universal truth. Architecture&#x2F;Design&#x2F;Implementation of any complex system is not an exact science with perfect formulas for creation. It would be nice to have more articles about new and exciting ways of doing things, instead of the same old tearing down of others for being stupid&#x2F;wrong&#x2F;etc because they think functional&#x2F;OO&#x2F;SOA&#x2F;microservices&#x2F;containers&#x2F;etc is the wrong way to do things.

Surprised security wasn&#x27;t mentioned as a reason to decouple services (IMO security is a top reason to split out a service).<p>Otherwise I tend to agree with the author.

It seems to be a common fault of youth to assume that you can solve every problem with just another level of abstraction. I call myself happy that I have used a lot of Java in my university days. The nice thing about Java is that you have so many tools and frameworks that do a lot of great things but always try to be as flexible as possible, ending with you having the power to do the same stuff in the library that you could have also done with pure Java: everything. I&#x27;m lucky because I never head to spend years writing such a tool that can do everything but nothing really well. Thanks to many tools who already made that mistake I could learn it by using it just a few weeks.

re this:<p><pre><code> &gt; The better strategy is a bottom-up approach. Start with &gt; a monolith or small set of coarse-grained services and &gt; work your way up. Make sure you have the data model &gt; right. </code></pre> the part about &quot;or a small set of coarse-grained services&quot;<p>I like this advice, but this is effectively starting with SOA! - just coarse grained. So the drive of this post should be so start with a simpler SOA, don&#x27;t pre-optimize etc, not build a monolith.

I think the biggest issue is to realize whether we are designing for humans or machines.<p>In all my work building big systems, microservices have never really made sense. The vast amount of developer time is spent in code where things are already nicely separated with solutions, projects, namespaces, IoC, etc.<p>When it&#x27;s all deployed and running, who cares if it all goes out as one big monolith? The machine doesn&#x27;t, it&#x27;s all just code. It&#x27;s way easier to deploy everything with a master version on the package and it guarantees everything works together. Easier to monitor, configure and scale. It&#x27;ll probably run faster too. You can still use queues&#x2F;message bus&#x2F;whatever to talk to other systems but outside of that, I feel a lot of the reasons for SOA are over stated and often unnecessary. As the overall business gets bigger, maybe certain large systems can get isolated but a lot of this microservice&#x2F;tiered stuff is way too granular and ultimately unproductive.

Agree with many of the points expressed here.<p>One area where microservices are very useful is in constrained environments, where being able to swap out idle services at runtime makes a lot of sense. This was actually the original driver for OSGi.

If you read original Service Oriented Architecture papers from IBM or the original Microservices bliki that Martin Fowler and his team wrote, you&#x27;ll see a lot of really smart ideas that sound really groundbreaking and feasible.<p>If I recall correctly, the original SOA vision focused a lot on creating a services catalog and ecosystem, with service location transparency, and loose-coupling between services, yellow pages for advertising and discovering services, and the calling interface formed a contract between caller and provider.<p>It seemed like a new combination of ideas that could change how software was delivered, but the vision was really tough to realize ... like, how do you bind to a service when its location can change? There was a lot of blind alleys to run down trying to solve that, and ultimately the vendors trundled out their Enterprise Service Bus products. These provided mediation, transparent failover, and quality of service. ESB servers were a new single point of failure, and deploying to ESB&#x27;s was incredibly painful since you couldn&#x27;t commit the configurations to source control easily, but you could get that transparency as originally advertised.<p>And it seemed like everything else in SOA was like that. A lot of solutions begging for problems, or incredible complication that inevitably required massive vendor products to implement - which also led to atrocious runtime performance&#x2F;instability due to shovelware vendor code.<p>The Microservices bliki read to me like a reboot of SOA - but a really good reboot. Gone were the service catalogs. And in was discussions of how to organize teams around code&#x2F;features. There was the whole novel versioning scheme, where multiple versions of a microservice could be deployed simultaneously. And deployed code was immutable - you would never redeploy or modify the code of a version, you&#x27;d just deprecate and release another version.<p>All this stuff screamed &quot;PRODUCTIVE&quot; to me, and was more a return to patterns and not leaving gaping voids in the description for vendors to fill with more shovelware.<p>It just turns out that software components are tougher to work with and maintain the further away they are from each other.<p>You can have two components A and B, where A depends on B. A and B are in the same code repository, just kept in separate folders. Doing this is handy because you can do refactorings against A and B and it&#x27;s easy to keep them in sync. Perhaps A and B are built separately with different build scripts, but they get deployed together and they are versioned together.<p>Now let&#x27;s move A and B into their own code repos. Now refactoring is a bit more difficult because now you have to make sure to keep A and B in sync. Why did we put A and B into their own repos? Because the boss is convinced that this separation was critical because he worked at Oracle awhile back (huh?) So, versioning is now an issue too, A has to refer to a version&#x2F;range of B that it wants. Needless busy work, but alright!<p>Now that we have our sea legs, we can go ahead and build and deploy A and B as independent microservices: A expects particular versions of B to be deployed, and A calls B via HTTP RESTful service calls. Refactoring is now officially painful, it requires a lot of negotiating between teams. B is required for A to function, the A team has to produce a client library for calling B that issues proper maintenance alerts when B is unavailable. Does B really need to be a microservice and are HTTP calls to it justified? PAIN PAIN PAIN! Hey, couldn&#x27;t B just be a library that gets called by A and not get its own microservice? (NO! Because Oracle!) That is where the whole &quot;Monolith&quot; discussion starts.<p>I fault Fowler for painting a rosy SOA&#x27;esque picture initially, but I can&#x27;t fault him too much. The original Microservices discussion he helped launch was really refreshing. It felt doable, it felt scalable, and it felt patterny instead of tooly.<p>Maintaining service contracts and encouraging intra-team friction is going to hurt agility, and it&#x27;s a miss that he didn&#x27;t call that out originally. So, I&#x27;m calling you out Martin Fowler: your good idea wasn&#x27;t a panacea!