Pulse and Cadence

Background

One of my University modules is called Project Management and Teamworking, and despite it being one of the more theoretical courses I take, one of the 'deliverables' was a fortnight project to write a server health app. I was very excited for this project as it's the first time we've had the opportunity for complete creative control over a product. As the module title suggests, we worked in a group for this task, so had a lot of manpower to hand. Planning started very early on, back in March, despite the two week period not starting until the 5th May 2014. The initial brief described a basic pinging application with either a website or android app to display whether the server was online or offline. Early on, I knew I wanted to go much further than those requirements. We had the opportunity to use whatever languages or resources we wanted and I started to look at relevant technologies we could use.

Data is everything

Knowing whether a server is up or down, whilst useful, is a little mundane for 2014. We wanted to report other data, data that we could graph, manipulate and most importantly would be relevant to the user. The fundamentals needed for each server were established: the server name, version, CPU Speed, total RAM and total disk space. But how would we store this data and interact with it?

Cadence

Using a custom API, means we can easily maintain the format, structure and types of data exposed. By creating 'Cadence', we designed a three pronged system centred around a primarily extensible API. Furthermore, it acts as an intermediary in between the server and client adding a layer of security. The two other parts of Cadence are the Server Host and the Availability Service. The host is installed on each server that is to be monitored and reports directly to the API via a 'Pulse' mechanism at a regular, pre-defined period. The availability service runs on a dedicated server and monitors all connected Cadence Server Hosts via a third party service called PubNub. PubNub uses persistent socket connections to stream data to subscribed channels. It's slick and with the company's extensive support, PubNub was simple to integrate into our product. The last Cadence product is the Availability Service which also uses PubNub, but more specifically it's Presence feature. This allows detection of subscriptions to all channels to check if the server has joined, gracefully disconnected or timed out (immediate shut down or power outage). We can listen for these events and notify users that are subscribed to SMS or voice call notifications using Twilio. This transforms Cadence from an on-demand, interaction-driven application into a complete, proactive solution that alerts users to problems as they happen.

Pulse

Pulse makes up the client side of the overall solution. Currently, Pulse exists as an Android app and a web panel that directly interfaces with Cadence. Cadence works on an opt-in user subscription model, users can choose via the web panel what server groups to subscribe to, and they'll show up on the Android app. The user's subscriptions are managed via Cadence authentication which supplies the client with an identifier for future API calls to other resource controllers.

I really enjoyed working on this project with a team of like-minded and driven people. I'm nearing the end of my second year of University now, before I start my internship at JP Morgan Chase & Co, and this was the first time we've had the creative freedom to design and shape a product from scratch.

All the code for the project is available on GitHub.

This article is my 4th oldest. It is 603 words long, and it’s got 0 comments for now.