Ok, this the first time I've ever heard a developer defend SOA: https://plus.google.com/112678702228711889851/posts/eVeouesvaVX . It's written by a Google developer who intended to send it out just to other Googlers, but it unintentionally went public. It's critical of Google's architecture choice, yet Google allowed it to remain up. Applause to Google for their openness.
The Googler, Steve Yegge, was formerly from Amazon, and says one thing that Amazon did better than Google is to enforce that all systems communicate with each other solely through service interfaces, and that these interfaces should be ready to be exposed to the public. This has allowed Amazon to successfully offer its Amazon Web Services products.
Most developers I know, though, hate SOA, and most companies I know that have adopted SOA have ended up with a slow, buggy, unmaintainable, inextensible, opaque architecture, and they curse the day they decided to adopt it. Even Amazon, with some of the best developers in the world, spent years transitioning to SOA, and it was a slow and painful process, and very difficult to get right, according to Steve Yegge.
To me, if you don't see the need for your software to be exposed to outside parties as a platform, forget about SOA. YAGNI, DTSTTCPW. Go down the SOA route and you may never get done, as what's happened to so many thousands of companies.
But if you see that your product needs to be a platform to be competitive, and it's at the scale where it has multiple subsystems, do as Yegge says and start dog-fooding. It's going to be 10X the effort though, and you might not have the talent pool that Amazon has. You should probably start with the system that's most likely to be externalized and put your best people there, or hire talent externally, then make sure to properly document and codify your learnings so that they can be applied when it's time to SOA-ize other systems.
No comments:
Post a Comment