A while ago at Xebia we tried to streamline our microservices effort. In a kick-off session, we got quite badly side tracked (as is often the case) by a meta discussion about what would be the appropriate context and process to develop microservices. After an hour of back-and-forth, we reached consensus that might be helpful to place a topic like microservices in a larger perspective. Below I’ll summarize my views on how to design robust microservices: start with the bigger picture, take time designing a solution, then code your services.
Or... has Nomad made the Consul-template tool obsolete?
If you employ Consul or Vault to provide service discovery or secrets management to your applications you will love the freshly released 0.5 version of the Nomad workload scheduler: it includes a new 'template' feature to dynamically generate configuration files from Consul and Vault data for the jobs it runs. Bundling Consul-template as a sidecar to your application is no longer necessary.
Nomad, Consul and Consul-template
A year ago Nomad 0.2 added support for automatic registration of jobs in Consul via a service configuration block. However the applications themselves still had to handle reading data from Consul. For this you had the following three options: Read more
A while ago I described the first part of our journey to refactor a monolith to microservices (see here). While this was a useful first step, a lot can be improved. I was inspired by Greg Young's course at Skills Matter, see CQRS/DDD course. Because I think it’s useful to reflect on the steps you take when changing software architecture, I’ve set a couple of milestones and will report on each when I get there. The first goal is to introduce process in our domain and see what happens.
We’re running a few (virtual) servers, nothing special. It is rather easy to turn those machines into snowflakes. To counter this we introduced Salt. Salt does a nice job in deploying software to servers and upgrading them when run regularly. But how do we counter issues when changing the Salt configuration itself? The solution is simple: Test!
You got into the Docker Universal Control Plane beta and you are ready to get going, and then you see a list of manual commands to set it up. As you don't want to do anything manually, this guide will help you setup DUCP in a few minutes by using just a couple of variables. If you don't know what DUCP is, you can read the post I made earlier. The setup is based on one controller, and a configurable amount of replicas which will automatically join the controller to form a cluster. There a few requirements we need to address to make this work, like setting the external (public) IP while running the installer and passing the controller's certificate fingerprint to the replicas during setup. We will use Terraform to spin up the instances, and Ansible to provision the instances and let them connect to each other. Read more
Security is probably one of the biggest subjects when it comes to containers. Developers love containers, some ops do as well. But it most of the time boils down to the security aspects of containers. Is it safe to use, what if someone breaks out? The characteristics of containers which we love, could also be a weak spot when it comes to security. In this blog I want to show some common methods to establish a defence in depth around your containers. This is container-specific, so I won't be talking about locking down the host nodes or reducing the attack surface i.e. by disabling Linux daemons.
Specifically for the Dutch Docker Day on the 20th of November, HashiCorp released version 0.2.0 of Nomad which has some awesome features such as service discovery by integrating with Consul, the system scheduler and restart policies. HashiCorp worked hard to release version 0.2.0 on 18th of November and we pushed ourselves to release a self-paced, hands-on workshop. If you would like to explore and play with these latest features of Nomad, go check out the workshop over at http://workshops.nauts.io.
In this blog post (or as I experienced it: roller coaster ride), you will catch a glimpse of the work that went into creating the workshop.
Imagine two football fans planning to attend a match 60 miles away. One of them paid for a ticket in advance; the other was just about to buy a ticket when he got one from a friend for free. The night of the game, a blizzard hits. Which fan do you think is more likely to drive through a blizzard to see the game?
You probably (correctly) guessed that the fan who paid for his ticket is more likely to drive through the blizzard. What you may not have realized, though, is that this is an irrational decision, at least economically speaking.
During the second day at Dockercon EU 2015 in Barcelona, Docker introduced the missing glue which they call "Containers as a Service Platform". With both focus on public cloud and on-premise, this is a great addition to the eco system. For this blogpost I would like to focus on the Run part of the "Build-Ship-Run" thought of Docker, and with the focus on on-premise. To realize this, Docker launched the Docker Universal Control Plane which was the project formerly known as Orca.
For a training on Microservices that is currently under development at Xebia, we've created implementations of a web shop in both a monolithic and Microservices architecture. We then used these examples in a couple of workshops to explain a number of Microservices concepts (see here and here). In this post we will describe the process we followed to move from a monolith to services, and what we learned along the way.