For this article, “service” means over TCP/IP with marshaling, and “component” means same language family (hopefully via dependency injection). Conway’s Law features in this article too, as service vs component is mulled for a real case.

Google’s phone-number library

Libphonenumber is on GoogleCode (Subversion). It is a 300K library that you link into your app when you need international phone number verification and intelligence. The committers (mostly Googlers) are maintaining Java, JavaScript, C++ ports within that one repo. Others have ported what’s happening there to C#, Objective-C, Ruby, Python and PHP. The Googlers look to be pushing about two releases a month. I guess that’s changes made by telecos world-wide, as well as regulators and government bodies. There are also fixes and increased understanding of existing phone number designs that require releases.

I initially thought that the core library was written in C++ with wrappers for Java, but that’s not how it has been done. They’ve made a language-neutral data format, and have idiomatically correct libraries maintained for each language. Besides, the JavaScript deliverable can’t wrap C++ if it needs to work in the browser. Perhaps Node.js was the intended target for the JavaScript binding, making that moot.

Conway’s law

Conway’s law is mentioned because your production architecture might be a consequence of your organizational separations:

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

This could have been a service. Developers using it could have invoked it RESTfully, and still consider it fast at less than 0.5ms per invocation. I’ll reuse two diagrams from my Cookie Cutter Scaling article from a few years ago…

Embracing SOA

It could be that a production architecture is designed like so:

If you were making available a libphonenumber service like that, it would be something like the “P” or “Q” nodes below “W”. Not quite as represented there or as many because it’s inherently fast (and doesn’t use a database), but still requiring a design that considers redundancy and scaling. If it is a separate node, the it could re-deploy it separately, when upgrades are available. You could mount both old and new versions of the service (notwithstanding endpoint considerations).

As it happens the libphonenumber team has made a demo web-app, which could easily serve as a RESTful service. If you’re happy to use regex to parse HTML, you could serve it as is. Adding a to-XML capability for more RESTful output is about half a days work. If you have Maven installed, here’s how to quickly play with that on your local machine:

svn co http://libphonenumber.googlecode.com/svn/tags/libphonenumber-7.0/
cd libphonenumber-7.0/
mvn gae:unpack
mvn package
mvn war:war
mvn gae:run
# point your browser to http://locahost:8080

You could deploy libphonenumber as Java process as they’ve made it, and consume it from any other process regardless of language. SOA gives you that heterogeneous possibility.

Avoiding SOA

It could be that a production architecture is designed like so:

Horizontal scaling is “cookie cutter” in this design. Libphonenumber is now available for use in every node as a component, that necessitates the same language family.

Many companies are pushing towards Continuous Delivery these days. If you’re able to deploy frequently, you would be able to keep up with the releases of libphonenumber and not sweat the fact that the whole app is being redeployed. That deployment simplicity is very attractive, especially while considering non-live environments too (particularly microcosm deployments under CI running Selenium functional tests). In production, you might even save that half-millisecond on response times, but there is a high probability that nobody notices that.

Question to the reader: What would you do for this - a service or a component? Were there any pros or cons that I didn’t list?

Updates

11th November 2014: Play with an online PHP port here (credits to Joshua Gigg).