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.
Top comments (2)
I think you missed the point of SOA. Overall, the spaghetti you talk about exists in all code. The monolithic approach forces you to dump everything in one bucket and sort it within a single application. That's spaghetti in my mind. SOA, and microservices particularly, allow you to connect disparate pieces together using simple code. You pick and choose the pieces you need to get the job done, and rather than having to write them, you simply use them.
There's no benefit to writing numerous ways to access the same data. You may have 6 different apps that access the same data, why would you want to write that 6 times versus making a call to the same service in each case? SOA allows you to reuse things more efficiently. The dependencies you talk about that only get worse exist regardless of your architecture. Bottom line is that you have a bunch of different systems and they all need to talk to one another, and there are several ways that this can be done. I've worked in organizations that had monolithic systems - it takes days to troubleshoot problems, no one fully understands them, and everyone is afraid to make a change because they don't know what will break as a result. On the other hand, working with SOA, the services are small enough and recognizable enough that you can easily troubleshoot them even if you didn't write them, and discovery is a breeze.
Thanks for your feedback, although I have to respectfully disagree with your assessment. For starters, the article is more or less about concepts vs implementations. SOA for instance, a great concept. Except when some of its ingredients are omitted and therefore missing the whole point - see where I talk about service providers and service clients. Most implementations out there have no such infrastructure meanwhile I find it to be at the core of SOA. Just because you have a bunch of web services does not make you SOA.
Secondary, monolithic has its drawbacks although I wouldn't dismiss it altogether. It all depends. Some of the best code I've seen out there were monolithic. Meanwhile some of the worst code I've seen claim to be SOA. It's not the architectural style or language that makes a piece of code great or garbage, its the developer.