Welcome to the final part of our microservices series. If you’ve missed a previous post you can read it here:

I) Architecture
II) Caching
III) Security
IV) Continuous Integration
V) Lessons Learned

Lessons Learned

Respect for Stumbling Blocks

Hopefully you have enjoyed our blog posts and have learned a lot. We answered following questions in our last four posts

• How to build a microservices architecture?
• How to use the advantages of caching with microservices?
• How to secure microservices and handle authentication between them?
• How to set up a seamless Continuous Integration workflow for microservices combining Jenkins, Git and Docker?

Our aim wasn’t to replace wikipedia or howto-articles. We wanted to provide an insight into different topics which occupied us during the semester – especially focused on our lessons learned. Therefore, we will present you the top stumbling blocks in the following. Why we do that? We want to avoid that someone else will fall over them.

#1 Smaller services, but higher costs

Costs for infrastructure will increase when multiple services are in use. To enable a high scalability, presuppose that the necessary resources are available. We build each service in a separate docker container which requires a lot of memory. We made the experience that a suitable server requires also an outlook to the future. We’ve started with Amazon AWS and must unfortunately note that our requirements are linked to high prices. Moreover, we didn’t use a configuration management tool like Ansible which made the server movement very time-consuming.

#2 Setbacks preprogrammed

A microservices architecture requires a lot of time in the conception phase and several architectural changes at least for our project. Therefore, we recommend to respect long-winded architecture meetings before starting with development. “Think big!” captures it well. One big setback was the database change from MySQL to MongoDB for reasons of security. We had implemented some basic functions with a MySQL ORM mapper which did not protect against SQL injection attacks. The switch to Mongoose, which is a mapper npm module for MongoDB with security protection support, had cost us lots of days of development.

#3 Microservices? – Not as easy as you think!

“Let’s do microservices” is said easily. We felt its impact first hand. No one of our group had previous knowledge about this topic. Therefore, it was quite difficult to split the business logic into separate independent services and simultaneously avoid a single point of failure. The main advantages are a higher scalability and an easier replaceability. Only the interfaces need to be updated to the newest versions.

#4 Simplifying everything

A good decision was to implement a service template which didn’t only save time, but also ensured uniformity for all microservices. Uniformity to a certain degree is very important because each developer has its own style. Thus, we achieved on the one side that everyone is able to contribute to each microservice and on the other we have got a homogeneous microservices landscape.

So, bottom line: Who would win a comparison between monolith and microservice architectures? Well, we would love to give you a clear answer, but unfortunately we will have to stick with: it depends. Or to put it more precisely, it depends on several factors like budget, knowledge, requirements, time, environment, infrastructure, scope and others. For our use case, after a longer initial warm-up phase, we experienced lots of benefits. These include small and easy to understand code bases, the ability to use different technology stacks and a great overall scalability, portability and deployability. So for us microservices proofed to be small parts with big advantages. At the end of the day, we would still go down the same road and choose this approach without hesitation. And if you think a microservice architecture could fit the needs of your next project – you should definitely give it a try!

Kost, Christof [ck154@hdm-stuttgart.de]
Kuhn, Korbinian [kk129@hdm-stuttgart.de]
Schelling, Marc [ms467@hdm-stuttgart.de]
Mauser, Steffen [sm182@hdm-stuttgart.de]
Varatharajah, Calieston [cv015@hdm-stuttgart.de]