We at ICANS believe that we can only deliver high performance continuously, by working in a passionate team of very smart, skilled and result-oriented individuals.

You may have already read this quote somewhere else on our home page. And although the above is the truth, the whole truth and nothing but the truth, I always feel kind of uncomfortable in writing such things, as it potentially sounds like ordinary marketing bs. Additionally it is bound to be very subjective, which makes such a statement even more questionable.

Probably giving real world examples is one good way to make such statements more tangible.

So today I’ll try to make this statement more tangible by giving you an example – I just experienced last night – what “being passionate” means to me:

Bjoern (Team Leader R&D) had a neat idea on how to make a request better observable throughout all (sub)-systems of our platform services. So far nothing too spectacular, as we are a team of very smart and skilled individuals, having neat ideas all the time ;)
But even though Bjoern didn’t expect this idea to be implemented in the near future, he went the extra mile after a hard working day, drafting his idea in a way someone else could easily catch up at some appropriate time in the future. That’s passion to me!

 

Still not interested in my marketing bs? Maybe Bjoern’s draft concept is of interest to you:

Brain Dump: The Request Pulse

The Idea

The Request Pulse is a concept, which allows us to observe how a request spreads within our system. The request does not necessarily have to be a HTTP request, it could also be the execution of a cron job or something like that.

The subsystem that receives the initial request generates the Pulse. It then attaches this Pulse to all sub-requests it makes to other systems.
All subsequent subsystems will have to do the same.

Since the Pulse propagates to all subsystems, we can add the Pulse to log events or messages as well.

Some possible applications of this concept would be

• Trace an error that occurred in a remote subsystem back to its initial HTTP request on the reverse proxy
• Group subsequent HTTP requests of AJAX calls together with their main request
• Detect unexpected behavior changes in a running system (“Usually the processing of this kind of request results in these event, but now it doesn’t”)

Some Scenarios

An Error Occurs

The following scenario shows a setup where all components also reside on a dedicated machine.
The client requests article X, which he may not access.
This should lead in displaying the fallback article Y, but actually leads to an error.
Which gets bubbled up to the client as a 404.
Some interesting events (including all errors) are sent to the Logging Service.

 

Since all subsystems “know” the Pulse, they can include it in the events, which are passed to the Logging Service. This allows us to observe:

• that the error in Content Repository while fetching Article Y was preceded by access denial, while trying to access Article X
• all events occurred while processing “GET /article/X” in combination with all the information, we have about the client
• etc.

AJAX calls

In the following scenario

• the client requests a page X
• the response includes
  • an element, which gets filled with some additional big data by an AJAX call onLoad
  • an element, which calls some statistics service, which includes some data about the users mouse movement in the first X seconds
  • the Pulse ID
• the browser then requests the additional data Z including the PulseID
• and makes the statistics call including the PulseID
  Again, the interesting events get sent to the Logging Service.

 

In addition to the observations above, we can group the requests for X and Z and the statistics call as one logical request by using the PulseID.

Some additional words

While both examples are not necessarily designed as one might design it in real life, they show how this method can be used to trace back errors and observe such flows without the need to pass down all information about the various clients to the subsystem where the point of interest resides.

Some notes (work in progress)

The Pulse consists of

• id := a (very probably) unique id, e.g. uuid
• timestamp := now in nanos
• trace := a list of the subsystems the Pulse has passed

Implementation note to self: It could be registered as a “global”/Singleton/registered object in the scope of the request and has to actually be passed as parameter only when doing subsequent requests (in HTTP header or whatever).

Note to self: It must be possible to disable / enable the Pulse. A missing Pulse must not lead to erroneous behavior.

…