I recently had the pleasure of speaking at AWS re:Invent 2016. I gave a presentation entitled ”Multi-Region Delivery Netflix Style” in which I elaborated how Netflix confidently delivers services on a global scale.

Back in September of last year, I had the pleasure of giving a talk about Netflix’s Continuous Delivery pipelines at Constant Contact’s 2nd annual Engineers4Engineers Conference in Waltham, MA. It’s a fabulous conference and definitely worth attending if you’re local to the Boston area.

In distributed systems, failure is inevitable. Eventually, some service will become bogged down and consequently won’t respond quickly enough or, worse, a service will simply die. Services relying on a degraded (or dead!) service will naturally become affected and potentially cascade instability throughout the system, unless all services are properly built with isolation and in mind.

Last fall, I had the distinct pleasure to keynote at Pivotal’s 2014 SpringOne2GX conference. My message was one of speed; that is, speed is the killer app. Indeed, Spring Boot has been a breath of fresh air and a boon to development velocity. Boot is the bedrock for developmental speed on the JVM.

“Continuous Integration is a hack!” said my friend Ben Rady years ago during a discussion on CI hosted by Stelligent. At the time, I was incredulous! How dare someone question the value of CI, especially when we had just finished writing a book about it! What’s more, our book had been nominated for a prestigious Jolt award; indeed, the following day, our CI book won it!

In retrospect, Ben’s point was poignant: CI is reactionary. You still have to wait some amount of time to ascertain correctness. That is, CI implicitly relies on a passive process to run a project’s build and any corresponding tests. If those tests fail, you are of course, notified. Nevertheless, that notification is somewhat delayed: by the time a CI process runs the tests and reports on their status, you’ve already moved on to the next task. So much for failing fast!

Dependency management is oftentimes a mundane subject. And it’s not much of a subject at all if you don’t depend on rapidly changing libraries. Of course, you might not always realize you’re depending on a rapidly changing library – especially, if you happen to take a rather liberal approach of depending on snapshots or latest versions, as I often do.

I recently found a nifty npm utility for Node applications that helped me avoid some rather annoying dependency related issues. It’s quite similar to Ruby Bundler’s Gemfile.lock files, but in the case of npm, you’ll need to actually run an additional command.

Do you need to create a Docker image from your Java web app? Are you using Gradle? If so, then you are only 4 steps away from Docker nivana.

For this example, I’m going to use a simple Spring Boot application. You can find all the source code in my Github repository dubbed galoshe.

If you haven’t had a chance to see Spring Boot in action, then you’re in for a treat, especially if the words simple and Java web app in the same sentence make you flinch. That was certainly my long standing reaction until I took a serious look at Boot.

Docker is a lightweight container for applications – think of a Docker as an app in a box, except that the box in this case isn’t an entire VM, but the bare necessities required to run a process. Consequently, you can run many Dockers in a VM. In essence, Docker replaces installation steps for a particular app. Rather than having to execute a series of steps to get, say, MongoDB running, you can simply fire up a Mongo Docker image.

Docker images can be created from a Dockerfile, which is similar to a Vagrantfile or even a build script – it’s a prescription for how to assemble an image. You don’t need to have a Dockerfile to create a Docker image, however, creating one makes image creation repeatable. It also provides a means for others to verify an image.

Years ago, a good friend of mine taught me an effective pair programming technique that results in universally covered code. What’s more, this manner of pairing ultimately made me a better developer as I learned myriad different coding skills from my coding partner, ranging from testing techniques, defensive coding, and encapsulation, just to name a few.

A lot of my coding practices today can be traced to tactics I learned from playing what’s known as ping pong.

I’m lazy and so I seek ways to reduce repetitious activities. For instance, I’ve spent a lot of time in a terminal typing Git commands. A few of the more common commands, I’ve aliased. If I want to see a list of branches, I used to type:

1

$> git branch -v -a

But after adding an alias to my bash profile, I simply type gb. I’ve done this for a few commands like git commit, which is gc and gca for the -a flag.