iseff

I'd also love to hear from others who have had luck with other techniques!

For instance, we have a user service (which controls accounts, sessions, etc and has its own database), a metadata service (which controls what files we know about, what tags they have, etc and has its own database), a file service (which controls the actual binary data of the files and has its own database), etc (we have a few others, but that gets the point across). They talk to each other through REST -- though it could be anything, of course -- to get anything done they might need.

This allows us to scale each service independently, which is great. I'm always surprised at how long it takes folks to move to a SOA.

But, perhaps, the coolest part from an always-hungry-to-try-new-things development team is that having a service based architecture means that we are free from programming language constraints. As long as the language can speak HTTP, we can try it out for a new service or a new client. There's nothing like the feeling you get when mastering a new language. And there's no better way to master a language than write something tens of thousands of people will be using.

So, we have an old front-end built in C#/Mono, we have a couple Rails services, a Java service, our new APIv2.0 (http://api.openomy.com) is written in Haskell/HAppS (which I'm particularly proud of), and now we're writing a client in Scala. And, besides that, we use Perl for some offline scripting tasks.

I think it's pretty unconventional-- but it shouldn't be! I highly recommend going this route.

And, on tumblr, http://featureorbug.com (recently became a Tumblr staff pick!).

The thing to note here, in my opinion, is to not implement it as they have. Do not store the credit card numbers on your own system. Instead, read through the comments. A few people talk up TrustCommerce (http://trustcommerce.com/), and it looks pretty good .

Note: I've never used it, just pointing out what others said. I do plan on using it sometime, however.

The best way I've found to be productive is to put long hours in on the weekend, at a coffee shop. Fewer distractions, and once you're in the zone, you can stay in it longer.

Our goal is to provide a place where people can store and access all their online files. We want to be the Online File System. We're heading to the "cloud" already and it's becoming increasingly difficult for us to manage our own files. My photos are locked in Flickr, my docs in Zoho, etc.

We want to break down the "data silos" and provide a single interface to all your "cloud storage" as well as provide a single API for developers to code against to access user's data in meaningful and interesting ways.

We're taking a multi-pronged approach to this. One prong (currently launched) is to allow you to upload your files through our API or our web interface and we'll store it (using Amazon's S3 for reliability and scalability). You can access the files and their metadata through the UI or through the API. You can tag them, share them, make them public, etc.

Our next step is to provide many backing-stores. That is, import your files from Flickr/Zoho, etc. We'll keep things sync'd up, so that Openomy becomes your Online File System; storing the metadata of everything you do online. Then, the UI becomes the equivalent of Windows Explorer or Finder, and the API becomes the equivalent of the single file system API provided to you as a desktop developer.

We think it's going to be, at the very least, extremely fun to build. :)

Ian