
Service Oriented Problems - kenneth_reitz
http://rdegges.com/service-oriented-problems
======
pydanny
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.

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

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

------
alook
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?

~~~
cmwelsh
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...](http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-
requests/)

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

~~~
steverb
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.

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

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

~~~
rdegges
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.

