6 ms·

Service Oriented Problems

40 points by kenneth_reitz 14y ago

pydanny 14y ago
Honest, the issue with documentation is the killer. Not on just how to build SOA, but on what parts of it to document (AS MUCH AS YOU CAN is the right answer). Nothing is worse then coming into an SOA project and discovering that you have to explore the code of many repos to figure out the logic behind the components that make up a project. Or that you have to explore Word/Google documents. Part of SOA is the contract between applications. If you don't document the API contract then you've got an abstracted mess often built with conflicting coding styles. And, unfortunately, this seems to be the majority of SOA implementations I've seen for the past umpteen years.
- rdegges 14y ago
  Totally. In general though, developers need to write better documentation for any application--not just SOA stuff. There are tons of private applications running in production that are obfuscated as hell, and have no supporting documentation :( Thanks for the comment! :D
- deleted 14y ago
  [deleted]
- kenneth_reitz 14y ago
  That's what I love the most about it. You can't not have excellent documentation. Forces you to do it right :)
  - deleted 14y ago
    [deleted]
    - kenneth_reitz 14y ago
      This has nothing to do with Heroku.
  - deleted 14y ago
    [deleted]
oinksoft 14y ago
There is a technology uniquely suited to make service-oriented application programming brain-dead simple: Erlang/OTP. A well-designed Erlang program consists of many discrete services, even if they are running on the same machine. This makes it trivial to later on distribute these services over multiple machines to meet demand. As long as you keep the Fallacies of Distributed Computing in mind and don't expect using Erlang to be some magic salve, following the OTP design principles will seriously simplify your SOA challenges.
- deleted 14y ago
  [deleted]
  - oinksoft 14y ago
    You're absolutely right, SOA patterns may be implemented anywhere. What's nice about Erlang is you get a seriously battle-tested platform designed specifically for this purpose, and good language support to boot. I will of course refer you to Virding's First Rule: Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang. https://groups.google.com/forum/?fromgroups=#!msg/erlang-programming/yiGXcWdnzMo/ekT-SZHCq28J https://groups.google.com/forum/?fromgroups=#!msg/erlang-pro... Update: I wish you hadn't deleted your comment because it was insightful.
cookingrobot 14y ago
Great to see you called out the Authentication work so prominently. This is a bigger chunk of work than many people realize. We building http://www.dailycred.com http://www.dailycred.com to offer Authentication as a service. One less component that devs need to design/build themselves.
- rdegges 14y ago
  This looks pretty sweet. I was actually thinking of doing something similar myself after rolling my own auth app several times in python / flask for my web services. A nice CRUD API for handling users (+ emailing users / registration) would be nice.
alook 14y ago
I've been mulling the idea of SOA-on-heroku lately - I'm used to working with SOA where the web service is publicly exposed, and the services are all available only on the intranet. This brings up bigger questions with regards to authentication - how does the 'api' service know that a request is coming from a correctly authenticated user? Since on heroku, the 'api' service would be externally exposed, I'm trying to decide if there's a good way to correctly authenticate/authorize in such a way that the 'api' service understands. Thoughts?
- rdegges 14y ago
  I do this via HTTP Basic auth + ssl. On Heroku you get SSL for free (https://myapp.herokuapp.com https://myapp.herokuapp.com), so that + basicauth works pretty well. EDIT: Wanted to add that I love doing it on Heroku as you get the automatic load balancing so you can easily add web dynos.
- cmwelsh 14y ago
  You can sign your messages using HMAC[1]. That's what Facebook does when it makes HTTP requests to your application. [1] http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests/ http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-ser...
jacques_chester 14y ago
One of really serious the problems with SOAs is that you need to reinvent cross-database joins. The promise is that you will decouple the logical components of the application; but in practice some secret-handshake, outside-of-view coupling actually occurs so that you can meaningfully do ad hoc queries across the different services. Similarly, for languages with strong typing, you partially give that facility up.
coopdog 14y ago
I feel like he makes some serious assumptions in this article. One that you need to put each service on a different server, and two that you need to connect each service to a different database. For a small/medium/large/whatever app you can definitely host services on the same server and database. Just update the code/configurations as necessary if you one day move them.
zacharyvoase 14y ago
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.

40 points by kenneth_reitz 14y ago

Honest, the issue with documentation is the killer. Not on just how to build SOA, but on what parts of it to document (AS MUCH AS YOU CAN is the right answer). Nothing is worse then coming into an SOA project and discovering that you have to explore the code of many repos to figure out the logic behind the components that make up a project. Or that you have to explore Word/Google documents. Part of SOA is the contract between applications. If you don't document the API contract then you've got an abstracted mess often built with conflicting coding styles. And, unfortunately, this seems to be the majority of SOA implementations I've seen for the past umpteen years.

rdegges 14y ago
Totally. In general though, developers need to write better documentation for any application--not just SOA stuff. There are tons of private applications running in production that are obfuscated as hell, and have no supporting documentation :( Thanks for the comment! :D
deleted 14y ago
[deleted]
kenneth_reitz 14y ago
That's what I love the most about it. You can't not have excellent documentation. Forces you to do it right :)
- deleted 14y ago
  [deleted]
  - kenneth_reitz 14y ago
    This has nothing to do with Heroku.
- deleted 14y ago
  [deleted]

oinksoft 14y ago

There is a technology uniquely suited to make service-oriented application programming brain-dead simple: Erlang/OTP. A well-designed Erlang program consists of many discrete services, even if they are running on the same machine. This makes it trivial to later on distribute these services over multiple machines to meet demand. As long as you keep the Fallacies of Distributed Computing in mind and don't expect using Erlang to be some magic salve, following the OTP design principles will seriously simplify your SOA challenges.

deleted 14y ago
[deleted]
- oinksoft 14y ago
  You're absolutely right, SOA patterns may be implemented anywhere. What's nice about Erlang is you get a seriously battle-tested platform designed specifically for this purpose, and good language support to boot. I will of course refer you to Virding's First Rule: Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang. https://groups.google.com/forum/?fromgroups=#!msg/erlang-programming/yiGXcWdnzMo/ekT-SZHCq28J https://groups.google.com/forum/?fromgroups=#!msg/erlang-pro... Update: I wish you hadn't deleted your comment because it was insightful.

cookingrobot 14y ago

Great to see you called out the Authentication work so prominently. This is a bigger chunk of work than many people realize. We building http://www.dailycred.com http://www.dailycred.com to offer Authentication as a service. One less component that devs need to design/build themselves.

rdegges 14y ago
This looks pretty sweet. I was actually thinking of doing something similar myself after rolling my own auth app several times in python / flask for my web services. A nice CRUD API for handling users (+ emailing users / registration) would be nice.

alook 14y ago

I've been mulling the idea of SOA-on-heroku lately - I'm used to working with SOA where the web service is publicly exposed, and the services are all available only on the intranet. This brings up bigger questions with regards to authentication - how does the 'api' service know that a request is coming from a correctly authenticated user? Since on heroku, the 'api' service would be externally exposed, I'm trying to decide if there's a good way to correctly authenticate/authorize in such a way that the 'api' service understands. Thoughts?

rdegges 14y ago
I do this via HTTP Basic auth + ssl. On Heroku you get SSL for free (https://myapp.herokuapp.com https://myapp.herokuapp.com), so that + basicauth works pretty well. EDIT: Wanted to add that I love doing it on Heroku as you get the automatic load balancing so you can easily add web dynos.
cmwelsh 14y ago
You can sign your messages using HMAC[1]. That's what Facebook does when it makes HTTP requests to your application. [1] http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests/ http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-ser...

jacques_chester 14y ago

One of really serious the problems with SOAs is that you need to reinvent cross-database joins. The promise is that you will decouple the logical components of the application; but in practice some secret-handshake, outside-of-view coupling actually occurs so that you can meaningfully do ad hoc queries across the different services. Similarly, for languages with strong typing, you partially give that facility up.

coopdog 14y ago

I feel like he makes some serious assumptions in this article. One that you need to put each service on a different server, and two that you need to connect each service to a different database. For a small/medium/large/whatever app you can definitely host services on the same server and database. Just update the code/configurations as necessary if you one day move them.

zacharyvoase 14y ago

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.