Refactoring to Microservices – Introducing Docker Swarm

In my [previous blog] I used local images wired together with a docker-compose.yml file. This was an improvement over stand alone containers. Networking is now more robust because code in images uses names instead of IP addresses to access services. This time my goal is to introduce Swarm so I can distribute components over multiple hosts and run more instances if necessary. Next, I'll describe step one: migrate the docker-compose-single-host setup to a Docker Swarm multi-host version. [More].

An Ubiquitous Domain language throughout testing

One of the biggest challenges as engineers is to write working software and also keep an extensive documentation. Most engineers hate writing documentation, and after they published documentation on a wiki it will die a lonely death. We want to strive for writing a Living Documentation in an Ubiquitous Language. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help you achieve this. Especially when we start writing code, it is really important for the quality of our software to start with tests describing what your application does. We want to write software with empathy in mind, software that is understandable for peers. While software developers are beginning to use the language of the domain (business language) more in their application code, most tests still contain a lot of technical language.

Read more →

Refactoring to Microservices – Using Docker Compose

In the previous version of the shop landscape (see tag 'document_v2' in this [repository]) services were started with a shell script. Each depended on Rabbit MQ to run, so there was a URL with an IP address that depended on whatever address the host it runs on got from its DHCP server. This was brittle, so I decided to introduce docker-compose. Actually, I should say 're-introduce' because my colleague Pavel Goultiaev built a previous version using compose. In this version, I copied and finished his code.

read more

This blog is part of my Trying-to-understand-Microservices-Quest, you can find the previous [installment here].

Avoiding deeply nested component trees

By passing child components down instead of data you can avoid passing data down through many levels of components. It also makes your components more reusable. Even multibrand components become much easier to build. Overall it is a pattern which improves your frontend code a lot!

The Problem

When building frontends you will pass data from a parent component to a child component. Often the child component renders this data, but not the component passing it along. The child components have different data requirements than your current component.

Then you add a new component, somewhere down your component tree. It has new data requirements, so you have to pass its data through all its parent components. On top of data, it might also need callbacks to provide interactivity. You also pass these through all parent components. You change a lot of files to add new functionality. With all the data passing the readability of your code also decreases. Overall the maintainability of codebase decreases.

Code samples and more at Medium.com

Property-based testing in Java with JUnit-Quickcheck - Part 1: The basics

To be able to show you what Property-based testing (PBT) is, let's start by grasping the concept of a property in programming languages. Since this is a Java tutorial, I will start with Oracle and their definition of a property in their glossary:

Characteristics of an object that users can set, such as the color of a window.

Property is neither a variable/field or a method; it is something in between which is always true in your context. An example is weight in a postal parcel: this always is greater than zero.  In Java the following example implementation would follow:

Read more →

Refactoring to Microservices – Using a Document as State

In a previous installment of our Microservice refactoring effort, I’ve introduced a ShopManager and a Clerk to implement the shopping process (see this blog). I ended up with a JSON document transferred between services. To make life easy for myself I just parsed all of the document using Spring magic. This time I will discuss the downside of this strategy and show an alternative.

read more

Why microservices fail

Gianna has joined Avidoo Inc., a productivity platform, as a senior software engineer. In a kick-off meeting with the rest of her team, she brings up the subject of microservices and whether the team has adopted them in any way. She immediately gets a strong reaction.
“We have tried adopting microservices, but they don’t work”, Byron offers.
“It became a terrible mess!”, Kary adds.
Gianna blinked her eyes three times expecting some kind of elaboration, but none followed.
After an uncomfortable silence, Gianna asks: “So what happened?”
“At first it was great. Every time we were asked to create something new we had the opportunity to add a service and use whatever languages and frameworks we wanted to experiment with. We exposed REST APIs on systems it needed to collaborate with or worked on their databases directly. But after a while, things started to break more and more often and development slowed to a crawl.”
Gianna sighs. It sounds to her like her team had been building a distributed monolith, while what they had meant to build were microservices.
Read more →