Microservices architecture principle #1: Each Microservice delivers a single complete business capability

This post is the first in a six-part series on Microservices Principles. Other parts are: Autonomy, Small bounded context, Asynchronous Communication, Best Technology and One Team.


Microservices are a hot topic. Because of that a lot of people are saying a lot of things. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture.
This blog explains why a Microservice should deliver a complete business capability.
Read more →

The End of Common-off-the-Shelf Software

Large Common-of-the-Shelf Software (COTS for short) packages are difficult to implement and integrate. Buying a large software package is not a good idea. Below I will explain how Agile methods and services on light weight containers will help implement minimal, focused solutions.
Read more →

Installing Oracle on Docker (Part 1)

I’ve spent Xebia’s Innovation Day last August experimenting with Docker in a team with two of my colleagues and a guest. We thought Docker sounds really cool, especially if your goal is to run software that doesn’t require lots of infrastructure and can be easily installed, e.g. because it runs from a jar file. We wondered however what would happen if we tried to run enterprise-software, like an Oracle database. Software that is notoriously difficult to install and choosy about the infrastructure it runs on. Hence our aim for the day: install an Oracle database on CoreOS and Docker.
Read more →

Xebia IT Architects Innovation Day

Friday August 22nd was Xebia’s first Innovation Day. We spent a full day experimenting with technology. I helped organizing the day for XITA, Xebia’s IT Architects department (Hmm. Department doesn’t feel quite right to describe what we are, but anyway). Innovation days are intended to inspire as well as educate. We split up in small teams and focused on a particular technology. Below is as list of project teams:

Installing Oracle on Docker
• Run a web application high-available across multiple CoreOS nodes using Kubernetes
• Application architecture (team 1)
• Application architecture (team 2)
Getting started with Salt
• Scale “infinitely” with Apache Mesos

In the coming weeks we will publish what we learned in separate blogs.

Read more →

Concordion without the JUnit Code

Concordion is a framework to support Behaviour Driven Design. It is based on JUnit to run tests and HTML enriched with a little Concordion syntax to call fixture methods and make assertions on test outcome. I won’t describe Concordion because it is well documented here: http://concordion.org/.
Instead I’ll describe a small utility class I’ve created to avoid code duplication. Concordion requires a JUnit class for each test. The utility I’ll describe below allows you to run all Concordion tests without having a utility class for each test.
Read more →

End of an era in my garage

This weekend I was forced to throw away a cardboard box. So what, I hear you think and I agree, but it being Sunday and me being in a hazy reflective Sunday afternoon state of mind (nono, no alcohol yet) and the box being the specific cardboard box it is (or rather was), I started thinking of the box’s significance for the future.
Read more →

On averages, history and predicting the short term future

Suppose you know a teams average velocity in story points to be 6 per two week sprint over the last year. Nothing interesting has changed (same team, same problem domain, out of holiday season…), what do you think is the correct answer to the following questions:

1) How many story points will be completed during the next half year?
2) How many story points will be completed in the next 4 sprints?
3) We estimate the final story to be 6 points, should we invite the Fortune-100 CEO’s for the crucial product launch next month?
Read more →

Scripting Deployit, Part 2

Like all software, Deployit plugins should be build automatically, deployed and tested whenever possible. Below I will explain how to setup continuous integration and testing for Deployit plugins. The general idea is that if you’re creating a larger set of plugins for Deployit, it makes sense to try to build and deploy them as often as possible so you can catch errors early. We found that it is really easy to create plugins that work fine in isolation but fail when they are deployed together. Luckily it is also easy to catch these kinds of errors as I will show below.
Read more →

Scripting Deployit

All I wanted to do was create a number of plugins and examples for Deployit using the different techniques available. While working on examples I was frustrated by having to clean up remainders of previous attempts, so following in the footsteps of greater men than my humble self (most notably professor Knuth who created TeX so he could finish writing a series of books on computer science) I first wrote a script to create junk in the Deployit repository and then get rid of it in one sweeping go.
Read more →