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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.