The wild SRE on the night quest

Is 03:15 a.m. the wild SRE is sleeping…

The phone rings!

The SRE is on call, and there is an incident.

In the cold of the night, he gets up, opens his computer, and starts to work.

He has a problem with a service. The error rate is too high, and there are four more micro-services involved…

The first is a Java service with SpringBoot.

The second is a Java service with Wildfly Swarm.

The third is a Java EE application.

And the fourth is a service written with a company’s framework that was made by a very creative guy…

But now at 03:30 a.m. the wild SRE has a problem, every service has a lot of abstractions, a chain of inheritance, many interfaces implementations, so many interceptors, and all those kind of stuff. He needs to figure out how the things should work together and why they are not working together.

He needs to check the logs and found an error in a class.

The repository is open and he starts to search for that class…

And his search founds nothing!

The error rate continues too high and now some services starts to fail…

He wastes almost an hour trying to understand what’s happening, a post-mortem was created because of the unavailability.

Like a police hero in the middle of a gunshot, in his last bullet, he decided to search through all the repositories…

And he found a library, with an interceptor that is auto-loaded on application startup.

This library is used an all the four services.

The auto-loader register the interceptor at the service, the developer just needs to declare the dependency. Looks amazing, not?

Now the wild SRE discover a new thing at software engineering. The hidden effect.

The hidden effect is that. Things happening in your service. A part of the business logic that is out of code, hidden in an auto-loaded dependency.

Now let’s say that the SRE is you! Yep, you, who are reading this post.

Do you prefer a software with a lot of abstractions or a simple one?

The answer is simple, as the micro-services should be.

A simple code is not less code! A simple code is one that tells you the truth, you can read and clearly understand what is going on.

Think about that in the next time when you have an idea for an abstraction.

Are you sure about this abstraction?

Think again.

OK, is it really necessary?

Simple code is easy to maintain, easier to understand what’s going on, and why the things have some behavior. As a software engineer, you should think about the next buddy who will read your code and try to figure out what you were thinking when wrote that.