Isolate Change in Microservices

I’m finally seeing the “microservice” trend starting to fade a bit. An excellent article came through my Twitter feed the other day, Sean Kelly’s “Microservices, please don’t.” His stuff is remarkable for how he draws the connection between coding practices in a monolith and their equivalent in a microservices architecture. It seems obvious but I haven’t seen too many people pay attention to it.

A solid SOA approach begins in the code itself and moves out into the physical topology of the stack as time moves on.

One of the issues that should be addressed in SOA is how to avoid shackling services together. A simple change in one of them shouldn’t create a cascading set of changes across multiple services. Likewise code in a monolith should be architected to isolate change and prevent cascading updates across classes or packages.

Domain-Driven Design addresses this issue for the single application and some of its rules apply equally well. For example, don’t pass the same object around inside the application that you pass across externally. There’s always a layer in true DDD applications that takes any DTO from an external source (like a web service or database) and keeps it external to the application by translating it to another object in the language of the domain inside the application. There’s a huge temptation to skip this step but every time I’ve seen it done it creates huge problems at some point.

Likewise in a microservices world, the requests and responses chattering between the services should never be a reverse dependency that force all of the services to change whenever they do, whether the specific service cares about the change or not. There should be a good fencing strategy going on that allows them to change with a minimum of pain. And that’s really no different than all of the classic object-oriented design advice. Keep in mind that Uncle Bob’s definition of “single responsibility” is “one reason to change”–not some of the other common misunderstandings passed around.

Anyway, the bottom line point in this is what software luminaries have always known and said: there’s no architecture, no ceremony or formula that you can follow which will not crumble when divorced from the context of good underlying engineering principles .


Proof that it is easier to write bugs in Java than in Scala, at least in for-loops

This SO is extremely informative. The questioner shows two functionally identical blocks of code (or so it seems)–one in Java and one in Scala. Somehow the Java one executes in 6ms. Meanwhile the Scala one takes over 1000ms.

The surprise wears off once you read the first answer. Instead we get a new surprise: the blocks of code were not identical. Instead, the Java code contains a bug. The author had quite accidentally swapped “i” for “j” in a for-loop.

The answerer rightly points out the advantage of Scala for loops: by dispensing with explicit index manipulation and providing direct syntax to express the loop bounds, this whole class of bugs is eliminated. The scala version below is both more clear and less error-prone.

Java (can you spot the bug):

for (int i = 0;i < N;i++) {
        float score = 0.0f;
        for (int j = 0; i < R;i++) { //oops!
            score += u[j] * t[i][j];
        if (score > maxScore) {
            maxScore = score;



for ( i <- 0 until N) {
  var score = 0.0f
  for (j <- 0 until R) {
    score += u(j) * t(i)(j)
  if (score > maxScore) {
    maxScore = score


I still added yet another comment: it is better not to use i and j as loop indices either way, because the human eye is not very good at distinguishing the two. It would still be very easy here to swap i and j in line 4 and not notice. Changing the names to x and y is probably best.

Play Framework 2.5.x JSON / REST API Hello World

There used to be a good tutorial on the Play website for the equivalent to Spring’s tutorial here but I can’t find it.

Considering that’s the case, here’s one for you.

  1. Visit
  2. Click download
  3. Usually downloads go to a Downloads folder. You probably want to unzip the download and then copy the activator folder that results into a directory somewhere that makes sense to you.
  4. Add the activator/bin folder to your path. On Mac OS X this usually means adding something to the /Users/[username]/.bash_profile file. Mine is similar to this:
    export PATH=$PATH:/Users/sshipp/dev/tools/activator-1.3.10-minimal/bin

    If you’re having trouble check out this OS X Daily article for more info or comment below. Windows users can read this article.

  5. Open a terminal / command prompt. (If you already have one open you will want to close and reopen Terminal so it picks up the path change.)
  6. Type “activator new” at your terminal prompt. If the path was correctly added, then this will show similar output to:
    [ dev ]> activator new
    Fetching the latest list of templates...
    Browse the list of templates:
    Choose from these featured templates or enter a template name:
      1) minimal-akka-java-seed
      2) minimal-akka-scala-seed
      3) minimal-java
      4) minimal-scala
      5) play-java
      6) play-scala
    (hit tab to see a list of all templates)

    If you get some message like “-bash: activator: command not found” your path is wrong.

  7. Choose play-java
  8. Enter the name of the app – I suggest “hello-world”. This will create a hello-world directory.
  9. cd to hello-world directory (or whatever you named it)
  10. Open app/controllers/ in a text editor.
  11. Change it to look like this…highlighted code shows new or updated areas:
  12. package controllers;
    import play.mvc.*;
    import play.libs.Json;
    import com.fasterxml.jackson.databind.JsonNode;
    import views.html.*;
     * This controller contains an action to handle HTTP requests
     * to the application's home page.
    public class HomeController extends Controller {
        public static class HelloWorld {
          int id;
          String content;
          HelloWorld(int id, String content) {
   = id;
            this.content = content;
          public int getId() {
            return id;
          public String getContent() {
            return content;
        public Result index() {
          HelloWorld hi = new HelloWorld(1, "Hello World!");
          JsonNode json = Json.toJson(hi);
          return ok(json);
  13. Save it and exit
  14. In the terminal, in the hello-world directory, type ‘activator run’
  15. Visit http://localhost:9000 in your browser

You should see:

{"id":1,"content":"Hello World!"}

Read more about JSON in Play here.

If you are curious why we would use Play and not something like Spring or another servlet-based framework, read the “When to use Play” section at the Lightbend guide. To sum it up, servlet-based frameworks like Spring are outdated technology based on a ‘one request per thread’ model that can’t scale as easily to today’s mobile and web demands. Companies like LinkedIn and Walmart are even finding that once they move to Play they can retire whole server farms that were needed for applications on servlet-based frameworks.