Here’s a real life tale of how we used Application Monitoring, Observability and Graceful Degradation to be able to ship
fast but also catch and fix mistakes without letting our users down.
In it we take a look at safe failure states and complementing metrics with supporting data and how we use them to solve real issues.
Looking for a library that helps you to serve up dynamic forms based on your own schemas?
Tes engineers recently open-sourced rolling-fields, a simple library that dynamically generates fields for your form on-the-fly.
Observing what happens when your users interact with your software keep you from disaster, allowing your users to keep working and you to keep shipping.
At Tes we capture what happens when our users interact with our services. We set expectations on outcomes. This means we know when our users can’t reach their goals. It also means we can act fast to fix problems.
In this blog post I’ll show how alerts help with this and how we make this a team-focused activity.
This May I was lucky enough to attend the J on the Beach conference, in Marbella, Spain. The event is able to (just about truthfully) advertise itself as ‘on the beach’, but given the proliferation of ‘data’ and ‘DevOps’ conferences, did it stand out? Did it succeed in its aim of unifying us all around Big Data? And, most importantly, what does the ‘J’ stand for?
A sense of separation has sometimes existed between Security and Development, as though the two are not inherently connected. Security considerations have always fed into the way we work at Tes, but without the right connections it can be easy to end up viewing security as an impediment to speedy delivery or vice versa.
We started a Security Engineering team (‘SecEng’ if you like) to bridge this gap and ensure our engineering teams see strong security in data handling as critical, and crucially, something firmly within reach.
Before introducing async-define, I’d like to give some context to explain what problem it solves and why we have to deal with these kind of problems at Tes.
micro-services integration One of the most important decisions we had to take when designing our micro-service architecture, is how to make micro-services work together. This is a particularly tricky choice, because you should choose a pattern that allows micro-services to be shipped independently and create the least amount of friction between services (and teams as per Conway’s law).
You’ve all heard the old adage:
There’s no ‘I’ in ‘Team’.
Teamwork would be much easier if we were working with clones! But we are all unique so we have to find a way to figure out how to work with other people who don’t think like us. Remember, we travelled different paths to reach the current point in our career and picked up different skills along the way.
Our working culture at Tes emphasises a “remote first” approach.
This means that any team member can work from any location.
It’s awesome and it allows us to work with lots of lovely colleagues based around the world.
It also means that if you want to go off and travel while working, you can go - no questions asked.
Or if you want to come to our London office every day, that’s totally fine too.