Why metrics? Since I joined 7digital I've seen the API grow from a brand new feature side by side with the (then abundant) websites to be the main focus of the company. The traffic grew and grew and keeps on growing in an accelerated pace and that brings us new challenges. We've brought the agile perspective into play which has made us adapt faster and make fewer errors but:

  • We can do unit tests but they don't bring out the behaviour.
  • We can do integration tests but they won't show the whole flow.
  • We can do smoke tests but they won't show us realistic usage.
  • We can do load test but they won't have realistic weighting.

Even when we do acceptance criteria we are actually being driven by assumptions, even with an experienced developer he is really just sampling all his previous work and as we move to a larger number of servers and applications it's not humanly possible to take all variables into consideration. It is common to hear statements like 'keep an eye on the error log/server log/payments log when releasing this new feature' but when something breaks it's all about 'what was released/when was it released/is it a specific server?'. As the data grows it becomes harder to sample and deduce from it quickly enough to feedback without causing issues, especially when agile tends to implement intermediary solutions which might have different behaviours from the final solution that have not been studied. The truth is that nothing replaces real life data and statistics – including developers opinions – if it the issue is a black swan then we need to churn out usable information fast!



Taken from @gregyoung This has been seen before by other companies; for example, Flickr on their Counting and Timing blog post. See also Building Scalable Websites by Flickr's Cal Henderson. This advice has been followed by other companies like Etsy on their Measure Anything Measure Everything blog post or Shopify on their StatsD blog post. How to do it? Decided to start with a winning horse I picked up the tools used by these companies: StatsD is described as “a network daemon for aggregating statistics (counters and timers), rolling them up, then sending them to graphite”. Graphite is described as “a highly scalable real-time graphing system. As a user, you write an application that collects numeric time-series data that you are interested i[...]. The data can then be visualized through graphite's web interfaces.” The way to implement these is available in several tutorials and I used StatsD own example C# client to poll our own API request log for API users, endpoints used, caching and errors. In the future it would be ideal for the application to access StatsD itself instead of running a polling daemon. There are a lot of usable features on Graphite. The ones I've used so far include Moving Average which will smooth out spikes in the graphs making it easier to see behaviour trends in a short time range and Sort by Maxima. There are even tools to forecast future behaviour and growth using Holt Winters Forecasting Statistics and this is used by companies to understand future scalability and performance requirements based on data from previous weeks, months or years (seen in this Etsy presentation on Metrics) How it looks and some findings Right away I got some usable results. An API client had a bug in their implementation which meant they required a specific endpoint more often than they would use it – this data can help out with debugging and also prevent abuse.

Sampled and smoothed usage per endpoint per API user...

Another useful graph is error rates, which might be linked with abuse, deploying new features or other causes.

 Error chart smoothed with a few spikes but even those are on the 0.001 % rate

Here is some useful caching information per endpoint to know how to tune up TTLs or look for stampede behaviour.

Sampled and smoothed Cache Miss per Endpoint

Opinion After you start using live data to provide feedback for your work there is no going back. It is my opinion that analysis of short and long term live results of any type of work should be mandatory as we move out of an environment that is small enough to be maintained exclusively by a team's knowledge.

Tag: 
Agile Development
anna.siegel@7digital.com
Wednesday, May 11, 2016 - 04:20

Today marks the beginning of the Technical Academy Tour as Academy Coordinator, Miles Pool, VP Technology, Paul Shannon and later, former apprentice, Mia Filisch head out across the UK to talk about our Technical Academy.

 

Continuous learning has always been part of the culture at 7digital and the Technical Academy allowed us to focus those ideas and start hiring apprentices. Changing the team entry requirements and providing a defined period of training allowed us to attract people from more diverse backgrounds and has increased the proportion of female developers in our team; it’s also strengthened the culture of learning and knowledge sharing at every level.

Emma-Ashley Liles
Monday, April 4, 2016 - 13:48

Since I started at 7digital I’ve loved our belief in continuous improvement. Throughout our history as a company we have had a number of influential women working in various parts of organisation yet I knew there was more we could do to improve the diversity of our tech team.

 

Anonymous
Tuesday, February 16, 2016 - 18:30

Here at 7digital, we see the relationship between the customer and the developer as one of the most important aspects of software development. We treat software development as more of a craft than an engineering discipline. Craftsmen back in the day would have constant communication with their customers, receiving regular visits from their customer to discuss progress and alterations as the item takes shape.

 

Over the last twenty years, the agile software movement and extreme programming in particular has championed this with its short iterations, customer showcases and active customer participation in the creation of features.

 

Mia.Filisch
Tuesday, December 1, 2015 - 20:10

7digital software developer Mia Filisch attended the October 28th Velocity conference in Amsterdam. She was kind enough to share her account of the core takeaways here with us. She found that the core recurring theme around security was enough to inspire some internal knowledge sharing sessions she has already started scheming on. The diversity of insights led to a productive and informative conference. See below for her notes.

 

Key takeaways from specific sessions: