3 ms·

I've worked in a few small organizations where the decision was made to build a new product using a service-oriented architecture. Not a single time did this pr

I've worked in a few small organizations where the decision was made to build a new product using a service-oriented architecture. Not a single time did this prove to be a good idea. I now get instinctively wary of anyone extolling the virtues of SoA on a small team. Here's what usually happened: * Testing got slow. Rather than just running a bunch of tests with nose or pytest, you had to provision a number of services, sometimes on a VM or build slave. * Testing got bad. Because services have enforced privacy, you can't test or mock their internal states, so you have a bunch of happy path functional tests but much less in the way of comprehensive unit and integration tests. * Communication deteriorated. In a perverse corollary to Conway's law, our team struggled to maintain a system that didn't mirror its own structure. * We spent a long time re-implementing basics (auth, JSON serialization, parallelization), and less time building product. This was always justified to the product owners as a necessary short-term sacrifice, but it ended up being a long-term sacrifice too. * Security failed -- distributed systems are harder to secure than monolithic ones, and most of the small companies trying to execute SOA don't have a clue about application security. The fact that they don't have robust implementations of common components available to them (because auth is now handled as a service, for example) doesn't help. * Performance degraded: HTTP, JSON and TCP are slow compared to passing around objects in memory and pushing to the stack. They always will be. Most people forget that the database is more than a dumb repository of tuples, and thus end up reinventing the relational algebra in JSON—only with horrendous performance. * Reliability was hurt. The idea that you have multiple services that can each go down without affecting the whole system is an absolute pipe dream. If the database goes down you can't do anything. If the web server segfaults, no one can see your site. End of. And things are far more likely to fuck up when you try to build a distributed architecture. You probably don't have the time or money to implement the correct provisioning or monitoring either, so when stuff does break you're gonna have a really fun time discovering and debugging it. These are just my experiences from being on teams of a few people. In larger organizations I'd postulate that SOA is the better approach. But please don't fall into the trap of buying SOA before you've reached a definite need for it.

eckyptang 14y ago
The point is really that SOA is probably for larger established organisations, not simple web apps etc. Your experience suggests that the organisations were not quite ready for SOA or chose the wrong tooling. I'm only making this point because I work on a successful SOA architecture which exhibits none of these problems. The difference is that we moved to this architecure when the product was 10 years old and used AppFabric+WCF to build it. The product and skill set were very mature then. We also had enough resources and cash to pull it off.
steverb 14y ago
It may be that services were the wrong way to go for your organization. My experiences are almost completely opposite to yours. Bear in mind that I've done this mostly for larger organizations, so I think there may be an economy of scale effect going on. * Testing is fast. Rather than trying to test a monolithic application you can break your system into small reusable chunks that can be tested independently. * We implemented the basics once (or used a library) and reused them extensively. And then we created native libraries for others to use so they don't have to think about those pieces. * Security became more robust. Rather than accepting the built in security we actually thought about security and developed a plan to secure everything in a consistent manner. * Performance was about the same, although it required a bit more thought. Not only are we able to cache web pages, but now we cache data separately. Just because one piece of data on the page has expired there's no reason to go fetch everything from the db again, and in a large organization it is shocking how often the same data gets requested over and over again. * Reliability is rock solid. Yes, if your database server goes down you're screwed. If your site goes down, you're screwed. But these are known issues and aren't particular to SOA. Now we have separate, multiple instances of our site and services, we're more fault tolerant. I'm still trying to convince management that geographic tolerance should be considered too. * We re-invent fewer wheels. We have a very solid separation of concerns. The services have the business logic, and the UI doesn't matter. You want an IOS app? No problem, we create a UI that calls the service. You want a web app? No problem, we create a UI that calls the service. Having said all of that, I do not like the term SOA. I think it puts the emphasis in the wrong place. It's not about writing services, it's about solving problems. I prefer to think of it as service enabled architecture, and then I try to remind myself that just because I have this awesome hammer that I love, it doesn't magically turn every problem into a nail.

eckyptang 14y ago

The point is really that SOA is probably for larger established organisations, not simple web apps etc. Your experience suggests that the organisations were not quite ready for SOA or chose the wrong tooling. I'm only making this point because I work on a successful SOA architecture which exhibits none of these problems. The difference is that we moved to this architecure when the product was 10 years old and used AppFabric+WCF to build it. The product and skill set were very mature then. We also had enough resources and cash to pull it off.

steverb 14y ago

It may be that services were the wrong way to go for your organization. My experiences are almost completely opposite to yours. Bear in mind that I've done this mostly for larger organizations, so I think there may be an economy of scale effect going on. * Testing is fast. Rather than trying to test a monolithic application you can break your system into small reusable chunks that can be tested independently. * We implemented the basics once (or used a library) and reused them extensively. And then we created native libraries for others to use so they don't have to think about those pieces. * Security became more robust. Rather than accepting the built in security we actually thought about security and developed a plan to secure everything in a consistent manner. * Performance was about the same, although it required a bit more thought. Not only are we able to cache web pages, but now we cache data separately. Just because one piece of data on the page has expired there's no reason to go fetch everything from the db again, and in a large organization it is shocking how often the same data gets requested over and over again. * Reliability is rock solid. Yes, if your database server goes down you're screwed. If your site goes down, you're screwed. But these are known issues and aren't particular to SOA. Now we have separate, multiple instances of our site and services, we're more fault tolerant. I'm still trying to convince management that geographic tolerance should be considered too. * We re-invent fewer wheels. We have a very solid separation of concerns. The services have the business logic, and the UI doesn't matter. You want an IOS app? No problem, we create a UI that calls the service. You want a web app? No problem, we create a UI that calls the service. Having said all of that, I do not like the term SOA. I think it puts the emphasis in the wrong place. It's not about writing services, it's about solving problems. I prefer to think of it as service enabled architecture, and then I try to remind myself that just because I have this awesome hammer that I love, it doesn't magically turn every problem into a nail.