Service Oriented Problems | Hacker News Reader

Service Oriented Problems

rdegges.com

40 pointskenneth_reitz16 comments

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.

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

That's what I love the most about it. You can't not have excellent documentation. Forces you to do it right :)

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.

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?

I do this via HTTP Basic auth + ssl. On Heroku you get SSL for free (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.

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-ser...

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.

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.

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.

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.

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.

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 to offer Authentication as a service. One less component that devs need to design/build themselves.

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.

Reply on news.ycombinator.com