Wake up time

WFH: 7.30 AM

Office: 7.00 AM

My usual routine is to wake up, shower, get dressed, and maybe fix my hair or do my makeup. However, that depends on my time and or my mood. Since I’m located in Berlin, and most of my team works in Lithuania, I’ve chosen to work different hours from 8.00 AM to 5.00 PM from the rest of the company (9.00 AM to 6.00 PM). It allows me to be more in sync and have more free time in the afternoon.

Breakfast o’clock

WFH: 8.00 AM

Office: 7.30 AM

I usually have German bread with cheese and ham for breakfast during the week since it’s fast and easy to prepare. And, of course, a nice liter of tea. I would say a cup, but I like to drink lots of tea. Not a fan of coffee, unlike most of the developers that I know.

 

Head to work

7.40 AM

When I go to the office, I usually take public transport because it’s better for the environment, and we have a monthly ticket compensation as a benefit.

It usually takes 20 minutes to reach the office with the U-Bahn.

 

Welcome to the office

8.00 AM

Two things that I do when I get to the office – wash my hands (crucial after the public transport) and get another cup of tea (also crucial for a productive day ahead).

 

First work portion

WFH: 8.00 AM – 2.00 PM

Office: 8.00 AM – 12.00 PM

Daily standup: 9.30 AM (5-10 minutes)

NordPass Update/Meeting: 10.00 AM – 11.00 AM

Normally I don’t have a lot of meetings. I know – the dream of every developer. I usually have my daily standup, and on Mondays, we have an update about what’s going on in the company or any other relevant theme.

Guild meetings happen once a month, where all the front-end developers from NordPass get together and talk about things: from cool tech we just read about to important information about upcoming changes.

 

So I usually check my emails and some merge requests before my first meeting. And afterward, I just work completely on any task or bug I choose from our sprint board.

 

WFH: 2.00 PM

Office: 12.00 PM

My lunchtime normally changes a lot when I work from home because I like to cook and eat with my husband. Therefore, we must agree on a time that suits both of us. We take turns preparing the food, but it normally happens after 1.00 PM.

We like to eat Mexican food because we’re from Mexico, so we try to include tacos and other foods with lime and chili on our menus.

 

WFH: 3.00 PM – 5.00 PM

Office: 1.00 PM – 5.00 PM

After lunchtime, I prefer to finish up my tasks and start testing and fixing anything that’s not working properly. If I haven’t finished my tasks, then I continue working on them, maybe pausing for a couple of minutes to stretch out and eat a snack. Especially if I’m at the office, where I get the chance to talk with people from other teams.

 

Getting my sweat on

My ideal schedule would include going to the gym after work every day. However, currently, I go only once a week or less. But it’s good to have a goal for improvement.

Sprechen sie deutsch?

I’m learning German because I want to be able to communicate better in Berlin. Even though almost everyone here speaks English or even Spanish, I still think it’s important to know the local language.

The classes are held online on Tuesday, Wednesday, and Thursday from 6.30 PM until 8.00 PM. At the moment, I’m learning B1 level – so not a complete beginner.

 

Family bonding

Both my and my husband’s family live in Mexico. Therefore, we have to wait until they have some free time to talk with us. We aim to have long video calls with everyone at least once a week.

Light dinner (mostly)

I usually have dinner around 8.00 or 9.00 PM while talking with our families. It makes me feel as if we’re sitting down together for a meal. I prefer something light for dinner, like cereal, but sometimes we spice it up with pizza or some Korean chicken.

Night night

I mostly go to bed around 11.00 PM after washing the dinner dishes and making all the preparations for the next day ahead.

 

Which one do you prefer, working from the office or home? Why?

I prefer working from home because I like cooking my own lunch. However, sometimes taking a break and going for lunch with people from the office is also nice.

At what time of the day do you feel most productive, and what tasks do you do then?

I think the time after my daily stand-up and before lunch is my most productive time – I do most of my work then. After lunch is more for testing, fixing, and other pending things.

Things that you like most about being a front-end developer at Nord Security?

My teammates, hands down. They are supporting me at all times and encourage me to learn more and be better.

Things you wouldn’t miss being a front-end developer?

The fun issues with CSS.

What are the front-end stereotypes that you’d like to break?

That we don’t know anything about the back-end. In fact, I worked as a full-stack developer before. And, of course, we need to know how the back-end works to do our jobs better.

What challenges are you currently working on, and what have been the most interesting ones you had to deal with at Nord Security?

Developing new features is always challenging, but it’s the most interesting part of the job. So figuring out how to implement new stuff while ensuring everything else still works fine is the most stimulating thing about being a developer.

Also, migrating to newer versions of libraries and other tools is always a way to keep learning while suffering a bit. However, when everything works in the end – it’s truly awesome.

Please, briefly describe your team? What kind of people work there, and how do you collaborate?

My team is the best. Everyone is always eager to help. We always have the best team buildings. And even if we’re located in different countries, we still keep in touch and are close to each other.

Monitoring vs. Observability

“Monitoring” and “observability” are often used interchangeably, but these concepts have a few fundamental differences.

Monitoring is the process of using telemetry data to understand the health and performance of your application. Monitoring telemetry data is preconfigured, implying that the user has detailed information on their system’s possible failure scenarios and wants to detect them as soon as they happen.

In the classical approach to monitoring, we define a set of metrics, collect them from our software system, and react to any changes in the values of these metrics that are of interest to us.

For example:

Excessive CPU usage can indicate that we need to scale it up to compensate for increasing system loads;

A drop in successfully served requests after a fresh release can indicate that the newly released version of the API is malfunctioning;

Health checks process binary metrics that represent whether the system is alive at all or not.

Observability extends this approach. Observability is the ability to understand the state of the system by performing continuous real time analysis of the data it outputs.

Instead of just collecting and watching predefined metrics, we continuously collect different output signals. The most common types of signals – the three pillars of observability – are:

• Metrics: Numeric data aggregates representing software system performance;

• Logs: Time-stamped messages gathered by the software system and its components while working;

• Traces: Maps of the paths taken by requests as they move through the software system.

The development of complex distributed microservice architectures has led to complex failure scenarios that can be hard or even impossible to predict. Simple monitoring is not enough to catch them. Observability helps by improving our understanding of the internal state of the system.

Metrics

Choosing the right metrics to collect is key to establishing an observability layer for our software system. Here are a few different popular approaches that define a unified framework of must-have metrics in any software system.

USE

Originally described by Brendan Gregg, this approach focuses more on white-box monitoring – monitoring of the infrastructure itself. Here’s the framework:

• Utilization – resource utilization.

  • % of CPU / RAM / Network I/O being utilized.

• Saturation – how much remaining work hasn’t been processed yet.

  • CPU run queue length;

  • Storage wait queue length;

• Errors – errors per second

  • CPU cache miss;

  • Storage system fail events;

Note: Defining “saturation” in this approach can be a tricky task and may not be possible in specific cases.

Four Golden signals

Originally described in the Google SRE Handbook, the Four Golden signals framework is defined as follows:

• Latency – time to process requests;

• Traffic – requests per second;

• Errors – errors per second;

• Saturation – resource utilization.

RED

Originally described by Tom Wilkie, this approach focuses on black-box monitoring – monitoring the microservices themselves. This simplified subset of the Four Golden Signals uses the following framework:

• Rate – requests per second;

• Errors – errors per second;

• Duration – time to process requests.

Choosing and following one of these approaches allows you to unify your monitoring concept throughout the whole system and make it easier to understand what is happening. They complement one another, and your choice may depend on which part of a system we want to monitor. These approaches also don´t exclude additional business-related metrics that vary from one component of the software system to another.

Logs

System logs are a useful source of additional context when investigating what is going on inside a system. They are immutable, time-stamped text records that provide context to your metrics.

Logs should be kept in a unified structured format like JSON. Use additional log storage/visualization tools to simplify interaction with the massive amount of text data the software system provides. One very well-known and popular solution for log storage is ElasticSearch.

Traces

Traces help us better understand the request flow in our system by representing the full path any given request takes through a distributed software system. This is very helpful in identifying failing nodes and bottlenecks.

Traces themselves are hierarchical structures of spans, where each span is a structure representing the request and its context in every node in its path. Most common tracing visualization tools like Jaeger or Grafana display traces as waterfall diagrams showing the parent and child spans caused by the request.

Building an observable software system lets you identify failure scenarios and possible risks during the whole system life cycle. A combination of metrics, extensive log collection, and traces helps us understand what’s happening inside our system at any moment and speeds up investigations of abnormal behavior.

This article was just the first step. We’ve covered the standard approaches to metrics and briefly discussed traces and logs. But to implement an observable software system, we need to set up its components correctly to supply us with the signals we need. In part 2, we’ll discuss instrumentation approaches and modern standards in this field.