Instrumenting and Observing Micro-services Part 2: Are your micro-services working together?

If you want to be confident that your users are able to achieve their goals using your service there’s more to do than monitoring the health of individual micro-services. You need assurance that your set of micro-services are working well together, and when they aren’t, you need the information necessary to fix any problems as soon as you can. This blog follows one Tes team’s mission to better identify and diagnose problems, enabling them to move fast and ship with confidence.

Interview with Stefano Ceschi Berrini

I’m Stefano Ceschi Berrini, I’m from Padova (Italy, 30km from Venice) and I’ve been working remotely at TES since March 2017 as a node Software Engineer. I have a degree in Computer Science, obtained in 2007 at the University of Padova and since then I’ve been working with web technologies, from PHP to Java to Ruby to JavaScript. I’m married to Deborah and I have two daughters: Rebecca and Rachele. When I’m not coding and I’m not changing diapers and calming daughters’ crying I usually cook, I listen to Progressive Metal and sometimes I also play my Taylor acoustic guitar.

Instrumenting and Observing Micro-services Part 1: What do you expect from your micro-service?

A friend of mine tells a great story of a team avoiding a great deal of grief. All of their system health checks were green, but the live graph of purchases dropped to zero and stayed there. Despite the many positive system indicators, the team were able to see they had a problem and were able able to react quickly to find and to fix it. It turned out that user purchases was a key indicator of success.

TES Hack Days

Hack days are an interesting idea based on the 15% time from 3M in 1948. The fundamental goal for hack days is to empower engineers to solve problems that they see however they want to. Without the day-to-day delivery pressure they can solve problems that other people don’t even realize they have or in ways that are incredibly creative.

Interview with Rachel Newstead

Rachel is a full stack engineer at Tes and works from her home office in Scotland. When she is not working, you will find Rachel either training for a race (she loves to run!), or exploring the outdoors. Want to get her attention? Just say the word “challenge”.

Outage on 25th April - the impact of a misconfigured redis server

On Tuesday evening, post the launch of the new home page, we had a second set of performance problems that impacted the entire site around 6pm for 40 minutes, and then subsequently during two periods at 9pm and 12am. The root cause turned out to be a misconfigured Redis caching server that was moved to in response to the issues on the 24th of April. During the post-mortem of the issues the day before we had agreed that a key action was to upgrade and improve the monitoring of the part of our platform that does the composition of the shared fragments (e.g.

Outage on 24th April - how one inefficient piece of code impacted

We had a number of site related performance issues on Monday 24th April that impacted the entirety of The fix to which (as always) was deceptively simple, and resulted in response times on average dropping from 100ms to 10ms, and CPU usage on the server reduce by almost 400%. As part of the rebrand we have been rebuilding the services that supply shared assets to all parts of our platform, which include core styles, images and the fragments of HTML for the masthead, footer and left hand navigation rail.

Debugging with the MongoDB oplog

Debugging allows us developers to assume the role of detective, and like any good detective, we need to consult all of our sources to understand what’s going on. If your application uses MongoDB for persistence, one source you have available is the oplog. What is the oplog? The MongoDB oplog, or operations log, is a standard capped MongoDB collection. Each document in the collection is a record of a write operation (a delete, update or insertion) that has resulted in data being changed.

Interview with Denis Fernandez

Denis Fernandez joined Tes in April 2015 as a front end software developer and currently works from Barcelona, Spain. He grew up in Havana, Cuba and went to Higher Design Institute where he graduated as a Graphic Designer. As if designing and creating amazing visual experiences for our digital education platform is not enough, Denis also plays the bass guitar and is a member of two metal bands. Below are a few questions we asked Denis to get to know him better!

React, or no framework?

This post is personal opinion rather than representative of the Tes development team in general. If you asked three other developers at Tes you’ll most likely get three different answers (and maybe three more blog posts after this one!). React has been the JavaScript framework of choice at Tes for the last couple of years, recently paired with Redux. Dozens of apps have been built in a variety of styles. Opinion across the whole development team has varied, from ‘Reactify the world’ to ‘use only if strictly necessary’.