From monolith to microservices

This project was part of the masters course Distributed Information Systems at the University of Applied Sciences (Karlsruhe) with the task to split a monolithic web shop application running on Tomcat into microservices with the Spring Cloud Netflix stack and exchanging the authentication and authorization to OAuth2.

The final implementation can be found here.

Reason

The reason why I put this project on my portfolio is that I decided to go the little extra mile with this project. I chose the take a Master’s course in Computer Science after an almost 3 years working period to specialize in specific fields and to use the freedom the studies allow me to go some extra miles and go beyond one’s own nose.

I wanted to dive deep into Docker and all this container environment. I wanted an answer to questions like

• what are the benefits of those container technologies?
• how does it work and how can it make my life easier, especially on different platforms?

Furthermore, I am a fan of automating things, especially when it comes to not so pleasing tasks like documentation. Testing, of course, was also one of my concerns, so I found this lovely package called Spring rest docs, which combines both approaches: creating the documentation from successful running tests.

As the last step I wanted to ensure a seamless migration from the old frontend to the new one. This means basically being able to run the new microservice approach along with the old monolith at the same time.

Byproducts

During the first steps of the course, I saw a lot of students struggling setting up their environment for the legacy service, which needed a MySQL database and Tomcat web server. Whereas setting up the database was the easier task, the struggles started when the web server had to be set up:

• Which XML file has to be put where to get access to the admin console?
• In which folder does the war or ear have to put in?
• How does the database connection to be established and so on?

As I already started in an early stage to set up the Docker environment, I got to know the benefits of having, e.g. a database within a container. Directly mount a folder into the container and the contents are written on your disk, but on the other hand, you do not have to care about the whole setup and native installation. Well, only the native Docker installation in the beginning. As a by-product, I wrapped to native installation into a Docker setup which abstracts the initial ramp into a script and lets the student focus on the main task: what’s the best way to split this monolith into microservices.

So, the vis-legacy setup was born. It abstracts the following tasks

• Creates the tables in the database and insert the admin user data
• Builds the ear
• Sets ups preconfigured Tomcat application server with an admin user
• Copies the ear into the web server
• Wires both containers together.

UPDATE (2018-08-02): As Docker and Docker compose have evolved on the meantime the setup does not need a native maven installation anymore. Still is now all handled by the stage-build. Furthermore, all ADD commands have been replaced with the favored COPY command.

FROM maven:3.5.4-jdk-8-alpine as builder

COPY ./pom.xml ./pom.xml
COPY ./src ./src
RUN mvn clean package

FROM tomcat:8.0
COPY --from=builder /target/EShop-1.0.0.war /usr/local/tomcat/webapps/
COPY ./conf/tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml

EXPOSE 8080

Setup

Docker and Docker Compose wrapped into a script make the set up fairly easy and straightforward:

$ git clone git@github.com:mavogel/vis-lab.git
$ cd vis-lab
$ sh run_microservices.sh

Conclusion

Going beyond one’s own nose helped me a lot in this case because in the end after all the wiring was done, logging and debugging was way easier and faster. Every service was simply wrapped into a container. Furthermore, IMHO those container technologies are the future and the way I would like to develop software.