As developers, we love to twist and turn the greatest concepts to ever surface our world. For certain, there is nothing wrong with that and it is how you learn and grow. Take Service Oriented Architecture, for instance, a great idea, right? Yes of course. Until you see it implemented. How about Object-Oriented? Great concept, right? I guess you know where I’m going with this. Most recently I’ve been contemplating SOA in its various implementations – more specifically through Microservices. Who doesn’t love Microservices? Like most great ideas, if not well understood and thought out properly, the result is often worse than anticipated. In this short article, we will look at the spaghetti code done in the name of SOA.
The most lacking tool in most software development teams out there is not the right technology. Most technology stacks in use today will sufficiently get the job well done. It’s mostly a matter of taste and other factors but rarely the ability to get the job done. Discipline, however, that we don’t have much of. Often, new concepts are not all that new after all. Why did we go from Services to Micro-services? Well, "Microservices* are services done well. Better yet, why services to begin with? Loose coupling? Easy to deploy and test? Maintenance? Nothing new here. Discipline is more important than whatever architectural style your team implements. No language or style will prevent you from writing shitty code. I guess we can say that architecture is more about people than technology.
Is your SOA implementation more like our good old spaghetti friend? There is a thin line between, and this is centered around the concept of the “service consumer” and “service provider”. Typically, to help SOA systems achieve loose coupling, the service consumer does not ask for a specific service from the service provider. The bus and repository building blocks are responsible for communication performance when the service is called. A simplified model can, of course, be realized by bypassing this communication block and soon or later you will find your organization in a spider web of services – time to welcome back our spaghetti friend. A bunch of services all calling left and right to accomplish a simple task. Dependencies that only get worse as your application grows. Not only is this such a bad dependency problem to have, but it also impedes productivity as your team grows and more services go up. One must become intimately familiar with a huge landscape of services to get up and running. SOA is complex to achieve for most organizations despite what most architects would confess to. Half-baked implementations are even worse, but is Monolithic the only alternative? One would hope not but whatever the answer to this is for your organization, discipline is the most important ingredient – the basis of any successful architectural style within your organization.