A popular approach is packaging by technical concerns. But this approach has some drawbacks. Instead, we can package by feature and create self-contained and independent packages. The result is a codebase that is easier to understand and less error-prone.

The term Microservices is quite vague as it leaves many questions unanswered. Contrarily, a Self-Contained Systems subsumes concrete recommendations and best practices that can guide you to create an application which is resilient and independent. But how can we implement such a system? At Spreadshirt, we build an application following the recommendations of a Self-Contained System. In this post, I’ll show you which technologies we used and which challenges we faced.

Extracting common code to a library seems to be developer’s best practice. Reuse boosts the development, doesn’t it? However, in a microservice architecture shared libraries tightly couples microservices together. You lose a huge benefit of microservices: independence. In this post I like to point out why shared libraries are not a good idea and present alternatives.

When we apply Model-Driven Software Development (MDSD) we write a generator which produces code out of a model. The promise is that among others, we can reduce the boilerplate code and accelerate the development. However, MDSD is not a cure-all and should be applied with sound judgment. In this post I cover some drawbacks of the generator approach, anti-patterns and present an alternative to generators: frameworks.

Docker allows us to easily create reproducible environments for our application. We automate the setup of the environment and eliminate manual error-prone tasks. This way we reduce the risks and the reliability of the deployment process. But there are also challenges and domains, where the usage of Docker can be difficult. This post discusses several advantages of Docker and points out some drawbacks.

Dropwizard produces a fat jar containing every dependency your microservice needs to run. This includes a web server. This way, no web server needs to be installed and configured on the target machine. However, there is some infrastructure left (like the JRE) which still has to be installed before the deployment. That’s where Docker enters the stage. With Docker we can produce an artifact containing really everything we need to run our microservice. In this post, we take a look at how we can integrate Docker into our Maven build, run our tests against the container and push the image to a repository.

Relational Databases seem to be the universal hammer in the toolbox of every developer. There is the notion that you can solve every problem with it – you just have to smash hard enough. However, if you use relational databases out of habit, you can easily run into troubles when it comes to schema evolution, scalability, performance or certain domains. This post discusses the strength and weaknesses of relational databases and points out alternatives.

Microservices are an interesting approach for achieving modularization of an application. An application is built as a set of services. These services can be independently developed, tested, built, deployed and scaled. However, microservices are not suitable for every use case. This post discusses the benefits and drawbacks of microservices.

Vaadin is a mature web framework for developing rich internet applications. Building web-based GUIs with Vaadin feels like developing a desktop application, which is great, comfortable and fast. However, there are situations where Vaadin is not suitable. In this article, we take a look at the architecture of Vaadin and point out its strengths and weaknesses. Let’s start.