IDlight Launched!

I'm super excited to announce the launch of IDlight, my very first SaaS. I'll promote it further after the week-end, but I wanted my blog readers to be the first to know :)

IDlight is an API that allows applications to retrieve public profile information. Among other things, it uses established and emerging standards like Webfinger, XRD and hCard to retrieve and parse public profiles.

It unifies all the retrieved data under a unique schema, which makes it easy for applications to consume in a consistent manner.

Please give it a try and share your feedback directly on idlight.net.

QCon San Francisco - Day 3

QCon San Francisco 2011 is a wrap. I have mixed feelings about the conference and I believe I'm not the only one. Feedback forms will speak... Here are the last tweets that I favorited and that represent the ideas I grabbed from the sessions I attended. Thank you to all the twitter users I've shamelessly re-used :)

QCon San Francisco - Day 2

My second-hand conference tweeting continues...

QCon San Francisco - Day 1

As I'm getting old and lazy, I've decided to cover QCon by favoriting other people's tweets on sessions I attended and post the result as a daily chunk...

API-First Development

A while back, REST advocate Juergen Brendel twitted:

API-first development: Modern dev. must consider multiple clients. Think about your REST API first, then add front end.

I retwited him because I can't agree more. In fact, even if there is a single client I'm convinced API-First development is a winning approach.


I've been involved in two three API-first projects, all very different in term of domain, size and technology. But in all cases, things turned out pretty well, and, in fact, way better than with traditional approaches to web development.


Clear responsibility delineation - When an API gets defined, client and server responsibilities become easier to define. The API becomes the guardian of this separation of concerns, as any temptation to make concerns of one side permeate to the other will either be impossible or at least extremely cumbersome. The API will resist almost naturally to desires to pervert it.


Better maintainability - Server-side front-end generation usually ends up in a pretty ugly mess where presentation concerns get mixed with service concerns. Even when following the MVC pattern, the sheer fact all artifacts are contained within the same project space opens the door to nasty transfers of responsibility between layers. An API is a contract around which clients and server can evolve harmoniously.


Client liberated - Front-end developers can use rich internet application frameworks and work on a clear interface with the back-end instead of getting constrained by a particular technology and having to deal with data transfer objects they don't fully control and which may change unexpectedly.


Test what matters most - This revolves around my previous rants about what's really important to test. When you expose an API, you can fully test your system as it is experienced by its different clients. There is no need for in-browser testing gimmicks. A simple HTTP client allows you to guarantee that the back-end is performing its duty and offering the front-end the features it needs. And that's what matters most.


Ninjas only - This point is a little harsh but here we go: API-first tolls the bell of tag soup developers. This category of developers, not skilled (or experienced) enough to be doing pure server-side development nor pure front-end one, is not needed anymore. Developers building clients for a server API are experts in their domain, be it HTML5, JavaScript, Flex, Android, iOS, Phonegap or whatnot. They can't rely on "the back-end guys" to pre-chew their job and are fully in charge of what they do.


In API-First development, the time you reach the point of trying a first connection between an actual client and the server is an exhilarating moment. Sure you've been testing the back-end for a while with a simulated front-end, but when they both connect for the first time, it's party time! And amazingly, things work very well right away, all thanks to a well defined API.


Before closing I should mention a downside for which I haven't found a satisfactory answer yet: against what back-end should client developers work? It is sure easy enough to expose a development-grade server to use while developing the front-end. But it's not always practical. A local server is an option, a client-specific stub is another one. Or maybe a state machine simulating the server API and allowing the front-end developer to change its state at will to easily simulate test scenarios?


So, what's your experience with API-first development? Any blazing success or horror story to share?

Service Oriented Organizations

Earlier this year, I twitted this:

and that:

Though seemingly disconnected these tweets are actually related. So here we are, in the blink of an eye, almost five months later and I can finally find some time to circle back to these ideas and expand them a little.

Both these tweets are related to the problem of growth and the pains a software company goes through when it expands.

At the beginning of a company, life is good, sharing code is easy. Whether everybody sits in the same room or not, the number of people involved in coding the product is so limited that synchronization is easy. Friction is limited, things go fast. Conflicts can be resolved with beer and pizza.

If by accident (!) the company ends up being successful, things change, sometimes very quickly and most of the time not for the best. So the team grows, divides into groups, and once the 150 persons mark gets passed, people start losing track of who's who.

The traditional path to a graceful handling of growth consists in adding layers of management. Whether the control this approach brings is actual or illusionary, the fact of the matter is that it increases the distance between teams. Here I'm not talking about physical distance, though it may be the case, but really about the perceived distance, the kind of distance from which the "us versus them" mindset stems.

Independently of all that, code still gets written. As the business has grown, so did the code base. Teams are sharing code. But now any code change must go through several layers of management, both up and down for each team. Fluidity has been lost in favor of process, which protects the business stability by doing what process does best: slowing things down, if possible to the point nothing happens thus preventing anything bad to happen.

At this point, the sheer fact of sharing code becomes a heavy burden. In software companies, shared code doesn't typically consist of pure libraries, like Apache Commons. Shared code more often than not involves shared dependencies on enterprise resources, like databases. High level of coupling, if not tangling, exists in the shared codebase. The mismatch between the boundaries that have been cut across teams and the actual software artifacts' delineation becomes an impediment to progress.

This is where the idea for a Service Oriented Organization comes from (notice how I avoided Service Oriented Business for obvious "acronymistic" reasons). It is not about getting rid of management or meetings. It is about organizing teams around tangible boundaries that fit the needs of sustainable software development.

In a Service Oriented Organization teams interact around well defined contracts: APIs and SLAs are the promises teams make to each other. And they fully define the actual extent of their commitments to each other. Teams do not share code but services.

Having clear objectives in order to achieve common goals without exposing any gory details is beneficial both for people management and software development. Whether APIs expose fine-grained technical methods or coarse-grained business ones, teams will have the rabid desire to provide the best service possible for what they're responsible of, and this for functional and non-functional qualities.

Of course, all this sounds nice and rosy and quite possibly the wishful thinking of an utopian. The quest that many people have embarked upon is to find ways for corporates not to succumb to the illusion of control and grow themselves into dumbness.

Service Oriented Organizations have been discussed before. This is just my two cents about the concept. Please share yours.

SNMP Monitoring for Scout

Half a year ago, I created a JMX plug-in for the Scout monitoring platform in the cloud. This time, I've created a plug-in for reading values from SNMP-enabled applications or systems.

The plug-in is available on GitHub.

It's capable of reading multiple values or walking the tree and gather all read values.

Let me know what you think of it: post bugs or feature requests here or directly in GitHub.

RSB (R Service Bus) at the Vancouver R Users Group

R Service Bus

View more presentations from David Dossot

The loggr Erlang Client is out!

I've just released the very first version of loggErL, my Erlang client for loggr. In case you do not know, loggr is a sweet piece of SaaS that offers a great deal of compelling log-related features wrapped in beautiful UI.

loggErL offers direct API calls to the loggr API, including support for optional fields:

loggErL comes complete with a Log4Erl appender that allows sending log events to loggr, again optionally supporting extra fields:

Feel free to fork this project on GitHub: https://github.com/ddossot/loggErL.

Mounting Resque Web Server in Ruby on Rails 3

If you want to load Resque's web server on a URL path alongside your main Ruby on Rails 3 application, no need to mess with config.ru or Rack::URLMap, as shown in different places.

The solution is way simpler and consists in using the RoR3's capacity to mount Rack applications directly in the routes table, as shown here:



Yep, it's that simple. Enjoy!

Erlang Monads FTW!

A few days ago, the big brains at RabbitMQ have released Erlando, a nifty pair of parse transformers that add support for cuts and do-syntax monads in Erlang. Like many others I'm sure, I've quickly started to use these new language constructs.

Here is a quick demonstration of how the Maybe monad and the do keyword can simplify the chaining of methods. The following shows a succession of condition evaluations which must all succeed for the final function (process_json_entities) to be called:

For those of you who wonder, yes I know that WebMachine could do most of this stuff for me: using this awesome REST framework is not an option for my project.

Without the help of the maybe monad, I would have add to either nest case clauses (yuck!) or chain methods, each of them calling the next one in case of success of its condition.

There are two problems with the latter approach:

• the most obvious problem is that the overall sequence of calls would not be in one place but buried deeper and deeper in the succession of functions,
• the least obvious problem pertains to the classic issue of naming things: finding good names for a chain of methods, each of them testing a condition and calling the next one is very hard.

So what's inside each of these method? Let's look into the first, which is basically a blueprint for most of them:

Notice on line 4 and 7 how the return/1 and fail/1 method of the Maybe monad are used to influence the flow of the sequence in the encapsulating do. The values I'm passing to these two functions are purely arbitrary but it is not always the case. In the first example above, on line 5 the value passed to return/1 in extract_json_entities is assigned to JsonEntities, eventually passed to the actual processing function.

To make this work, besides a Rebar dependency, not much is needed besides the following directives:

Hopefully, this will whet your appetite and decide you to give Erlando a try!

JMX Monitoring for Scout

Scout is a very convenient monitoring platform in the cloud that I have started to use recently. I needed to monitor JMX data point, something that Scout doesn't do by default.

One of the many shiny things about Scout is its extensibility: it is super trivial to write a Ruby plug-in and have start use it to report custom data points.

Therefore, I've created a JMX plug-in which, after some QA from the awesome team at Scout, just ended up in their repository of supported plug-ins.

Read more about this here.

Put a rabbit in your HTTP

I'm pleased to announce the release of http-safe, a store-and-forward HTTP gateway plugin for RabbitMQ.

Its goal is to simplify the integration and communication of services over HTTP by relieving systems from the chore of resending requests when something went wrong with "the other side".

http-safe goes beyond the fire and forget paradigm as it supports the notion of delivery callback in order to inform the originating system of the success or failure of its dispatch request.

Read more on GitHub: https://github.com/ddossot/rabbitmq-http-safe

Listen to Your Applications

Applications have lots to say. Here's how I've learned to listen to them.

I have recently been involved in the development of a highly distributed cloud application. We were a small team and wanted to remain agile all the way through. We had extensive testing and continuous integration in place from day one giving us plenty of feedback during development, a feedback that is essential for building the right thing and building it well.

But what about production time?

We wanted to get feedback from this part of the application life cycle too, therefore we've decided to build and configure many different feedback sources so our application could speak to us.

And speaking it did. It actually provided us precious feedback on three very different aspects of itself: user experience, design and implementation.

I have tried to represent the different feedback sources we've baked into our application and to what domain they belong to on this lovely triangular diagram:

Let me detail each feedback source:

• Activity Log - This is a detailed audit trail of each and every user action you can capture. It provides detailed feedback on your features and how you've made them usable or not. Storing this data in a PostgreSQL partitioned table did well for us. With higher volumes, you may want to go NoSQL.
• Error Log - An embarrassing stack festival that may or may not have direct impact on the end user. No need to mention that this log is best kept empty. A service like Hoptoad can help you with that by putting errors in your face until you resolve them.
• Trace Log - This is where you take the true measure of what your application is actually doing, which is less than obvious in highly distributed applications. Logging correlation IDs and aggregating logs in a central place via syslog or Scribe is a good approach. You'll need searching capacities in these logs: think Clarity or Splunk, depending on your constraints and budget.
• Response Time - This is an obvious metric that will shed some light on your design and implementation. Just be sure you're logging it and paying attention to it.
• DB TPS - Though outside of the pure realm of your application feedback loop, this metric gives you a good measure on how DB intensive is your application and if it needs some redesign, like for example some low hanging fruits where caching could help.
• Cache Hit/Miss - Caching brings as much problems as it solves: a cache-happy application doesn't come for free, especially if it is distributed. Measuring the hit/miss ratio on each cache can help validate their usefulness or lack thereof.
• MQ Throughput - Monitoring of queues for high watermark thresholds is commonly done outside of the application's realm. An interesting MQ-related data an application can log is the time a message has been in-flight, including, or not, the processing time of the message after it's been consumed.
• Activity Intensity - This last one is a fun one: by representing the number of active application sessions and the current database activity, you can get a great idea of how active (or bored) are your users.

Let me mention a single benefit of this approach: thanks to the detailed activity log, we've been able to spot design issues that were preventing users to make full use of some features. And we've been able to fix these issues not based on assumptions or wild guesses but on measured data.

Your applications want to talk to you: do you listen to them? How do you do it?

Shamelessly Plugged: cferl & Mule Erlang Transport

Vancouver Erlang Meetup cferl & Mule Transport Plug

View more presentations from David Dossot.

DevOps: Time for Agile Operations!

I've made a little xtranormal movie to introduce DevOps on the blog of AgilePartner.


Go check it out!

Erlang + Cloud Files = cferl

To celebrate the return of CloudCamp in Vancouver, I'm happy to announce the very first release of cferl, the Erlang API for Rackspace Cloud Files.

cferl fully implements the current version of the Cloud Files API. With it, you can very easily create and manage storage containers and the data objects they contain. You also have full control over the publication of your data objects on Rackspace's CDN.

Here is a short example that demonstrates a few operations using cferl:

That's all it takes to create a container, add an XML document into it and make it available to the rest of the world over CDN!

To probe further, you can:

• Browse the readme document that contains many more syntax examples.
• Download cferl 1.0.
• Fork the project or report issues on github.

Enjoy cferl!

Recently Reviewed: Patterns-Based Engineering

From time to time, I participate in technical book reviews. Here is my account for a book I've recently reviewed.

Pattern galore, a term that aptly describes one of the worst nightmare of software craftsmen. No-one wants to come close to a system that has been dragged into a design hell created by pattern-overenthusiastic programmers. A craftsman wants his design to be constrained by requirements and his code to be written by hand.

Alas not all code is born equal. Some languages and platforms insist on the creation of tedious scaffolding code before starting to tackle the real meat of the problem. And large projects imply the repetition of this code ad nauseam. Moreover, many have been lost in the quest for the long sought holy grail of code re-use.

Not deterred by this difficult context and heavy history, Ackerman and Gonzalez have decided to present a pragmatic approach to using patterns in software engineering. And they did great. In truth, Patterns-Based Engineering is faithful to its tagline: Successfully Delivering Solutions via Patterns.

Rest assured that snake-oil is not in the catalog of the authors: the book is as concrete as possible, organized as a manual for kick-starting a rational approach to using patterns. The authors took time to debunk pattern-related misconceptions and, this, for a reason: there is a lot to do to polish the image of design patterns. I believe this book is an essential first step in the right direction.

Watch These Threads

You've been warned...

Data Interaction Patterns

Throughout my experience with working on back-end systems for anything from big governmental to online gaming, I have came to develop a particular appreciation of the interactions that happen between data consumers and data producers. The following is a non-exhaustive and non-authoritative review of the different data interaction patterns that I've came up to play with. These are mostly unstructured notes from my experience in the field that I hope may turn useful to others.

As you know, when data is involved caching comes into play when performance and scalability are sought. In the coming diagrams, cache is represented as a vertical rectangle. The persistent storage is represented as a vertical blue cylinder, while horizontal cylinders represent some form of reliable and asynchronous message delivery channels. The data interactions are represented with curvy arrows: they can represent reading or writing.

Direct [R/W]

Besides the obvious drawbacks coming from the temporal coupling with the persistent storage mechanism, the interesting thing to note in such a trivial data access pattern is that there is often some form of request-scoped caching happening without the need to explicitly do anything. This first level of cache you get from data access layers help in optimizing operations provided they occur in the same request (to which is bound the transaction, if one exists).

Being short lived, this kind of caching is free from the problem of expired cache entries eviction: it can kick in transparently without the application being aware of it.

Through Cache [R/W]

Reading through cache is a simple and powerful mechanism where an application tries first to read from a long lived cache (a very cheap operation) and, if the requested data can't be found, proceeds with a read in the persistent storage (a way more expensive operation).

It's interesting to note that write operations don't necessarily happen the same way, ie. it is well possible that a write to the persistent storage doesn't perform a similar write in the cache. Why is that? Cached data is often a specific representation of the data available in the storage: it can be for example an aggregation of different data points that correspond to a particular cache key. The same persistent data can lead to the creation of several different cache entries. In the case, a write can simply lead to an immediate cache flush, waiting for subsequent read operations to repopulate these entries with new data.

Conversely, it's possible to have write operations update the cache, which opens the interesting problem of consistency. In the current scenario, the persistent storage remains the absolute truth of consistency: the application must handle the case when the cache was inconsistent and led to an invalid data operation in the persistent storage. I've found that localized cache evictions work well: the system goes through a little hiccup but quickly restores its data sanity.

Though some data access technologies allow the automatic management of this kind of second level of caching, I personally prefer that my applications have an explicit interaction with the caching technology they use, and this at the service layer. This is especially true when considering distributed caching and the need to address the inherent idiosyncrasies of such a caching model.

Cache distribution or clustering is not compulsory though: you can reap the benefits of reading through cache with localized caches but at the expense of needing to establish some form of stickiness between the data consumers and the providers (for example, by keeping a user sticky to a particular server based on its IP or session ID).

This said, stickiness skews load balancing and doesn't play well when you alter a pool of servers: I've really became convinced that you get better applications by preventing stickiness and letting requests hit any server. In that case, cache distribution or clustering becomes necessary: the former presents some challenges (like getting stale data after a repartition of the caching continuum) but scales better than the latter.

Write Behind [W]

Writing behind consists in updating the data cache synchronously and then defer the writing to the persistent storage to an asynchronous process, through a reliable messaging channel.

This is possible with regular caching technologies if there is no strong integrity constraints or if it's acceptable to present temporarily wrong data to the data consumer. In case the application has strong integrity constraints, the caching technology must be able to become the primary source of integrity truth: consistent distributed cached that supports some form of transactional data manipulation becomes necessary.

In this scenario, the persistent storage doesn't enforce any form of data constraint, mostly because it is too hard to propagate violation issues back to the upstream layers in any meaningful form. One could wonder what is the point of using such a persistent storage if it is dumbed down to such a mundane role: if this storage is an RDBMS, there is still value in writing to it because external systems like a back-office or business intelligence tools often require to access a standard data store.

Cache Push [R]

Pushing to cache is very useful for data whose lifecycle is not related to the interactions with its consumers. This is valid for feeds or the result of expensive computations not triggered by client requests.

The mechanism that pushes to cache can be something like a scheduled task or a process consuming asynchronous message channels.

Future Read [R]

In this scenario, the data producers synchronously answers the consumers with the promise of the future delivery of the requested data. When available, this data is delivered to the client via some sort of server push mechanism (see next section).

This approach works very well for expensive computations triggered by client requests.

Server Push [R]

Server push can be used to complement any of the previous interactions: in that case, a process prepares some data and delivers it directly to the consumer. There are many well known technological approaches for this, including HTTP long-polling, AJAX/CometD, web sockets or AMQP. Enabling server push in an application opens the door to very interesting data interactions as it allows to decouple the activities of the data consumers and producers.