When a Kubernetes Operator Makes Sense

Beyond YAML: Real-World Lessons from Managing Complex Infrastructure

There are plenty of ways to deploy applications onto Kubernetes:

• raw kubectl apply
• Kustomize overlays
• Helm charts
• sidecars and init containers
• and, at the far end of the spectrum, fully-fledged operators

Most teams start at the simple end and stay there. And they should, most applications don’t need anything more complicated than a Deployment, a few ConfigMaps, and a kubectl apply -k.

About 19 years ago, I set up a blog on Google’s Blogger platform to track my adventures learning Java: https://javaadventure.blogspot.com/

The platform has changed a lot since then, and not always for the better. Many posts no longer render the way they used to, and a few images have disappeared entirely.

One feature I really loved, which is now broken, was the ability to email a special address and have the message automatically turned into a post. It made publishing effortless… though that was also before I discovered what was then X (née Twitter).

Another interesting tidbit:

@Benchmark
public void debug1Arg_date(Blackhole blackhole) {
    LOGGER.debug("Started at %s", new Date(time));
    time++;
    blackhole.consume(time);
}

@Benchmark
public void guardedDebug1Arg_date(Blackhole blackhole) {
    if (LOGGER.isDebugEnabled()) {
        LOGGER.debug("Started at %s", new Date(time));
    }
    time++;
    blackhole.consume(time);
}

Gives the following benchmark results:

Benchmark                            Mode  Cnt          Score         Error  Units
Log4jBenchmark.debug1Arg_date         thrpt   20  179653191.248 ± 2731044.349  ops/s
Log4jBenchmark.guardedDebug1Arg_date  thrpt   20  207001790.376 ± 2074020.617  ops/s

We can also compare guarding with SLF4J over logback

One of my colleagues had a question:

Now for some context, when the Jenkins project started off, Kohsuke was working for Sun and felt it would be wrong, as a Sun employee, to use a logging framework other than that provided by the JVM as using a different logging framework could be seen as being implication that the built in Java Utils Logging framework was a steaming pile of excrement.

You asked for it.

Logback:

@Benchmark
public void debug1Arg_date(Blackhole blackhole) {
    LOGGER.debug("Started at {}", new Date(time));
    time++;
    blackhole.consume(time);
}
@Benchmark
public void debug2Arg_date(Blackhole blackhole) {

    LOGGER.debug("Started at {}", new Date(time), null);
    time++;
    blackhole.consume(time);
}
@Benchmark
public void debugNArg_date(Blackhole blackhole) {
    LOGGER.debug("Started at {}", new Date(time), null, null);
    time++;
    blackhole.consume(time);
}
static {

    ch.qos.logback.classic.Logger root = (ch.qos.logback.classic.Logger)LoggerFactory.getLogger(org.slf4j.Logger.ROOT_LOGGER_NAME);
    root.setLevel(ch.qos.logback.classic.Level.INFO);
}

And the benchmarks

Benchmark                     Mode  Cnt          Score         Error  Units 
LogbackBenchmark.debug1Arg_date  thrpt   20  221056534.656 ± 8549233.826  ops/s
LogbackBenchmark.debug2Arg_date  thrpt   20  220576341.742 ± 3778270.898  ops/s
LogbackBenchmark.debugNArg_date  thrpt   20  134887126.088 ± 2973182.812  ops/s

JUL over SLF4J (same benchmark code but different dependency)

If there are two only things guaranteed to cause all out war between developers, my vote is that those two things are:

Code formatting conventions

Version number conventions

The first is resolved trivially (just shoot anyone suggesting the use of TABs). Until recently most people thought the second was resolved by semver… at least until the developer of one of the more commonly used JavaScript libraries threw the cat amongst the pigeons.

One of the headline grabbing things that people seem to be raving about over Log4J 2.0 is async loggers.

Now do not get me wrong, they are great… as long as you know what you are doing.

If you are using async loggers you had better make sure you are only passing immutable objects to your loggers, because otherwise you may end up logging the state of your objects at the time of the log record being written and not the time you called log.

We have all had the bad technical managers… the ones who tell you to go and do something… and then micromanage the task they have “delegated” to you.

They are a pain to work for.

One of the qualities of a good manager is to tailor their delegation to the people they are delegating to.

So they task Gillian, a senior engineer, with “writing some smoke tests to verify that the application works when deployed to the app server” and they are happy to let Gillian work within that scope because they trust that Gillian will come back to seek clarification if the description is lacking, or if there are issues down the road.

There are two ways to build a Maven project with Jenkins*

Use a free-style project with a Maven build step

Use a Maven-style project

The first way runs the build as Maven intended. The second way adds a whole lot of hooks and can even modify the build in ways that Maven did not intend.

The first way requires that you configure stuff yourself. The second way tries to “guess” what you want and auto-configure it.

I was given a link to yet another article preaching about how 100% code coverage is the only goal (the article is preaching, not Tatu BTW)

There is an issue I have with how the 100% coverage advocates present their argument, but we’ll get to that later.

The case for 100% coverage is put quite simply:

Anything less than 100% coverage means that there are some lines in your code that are untested, and are you seriously willing to let code be released without being tested?