W1siziisimnvbxbpbgvkx3rozw1lx2fzc2v0cy9hzhzhbmnllwlulwl0l2pwzy9iyw5uzxitzgvmyxvsdc5qcgcixv0

From traditional to microservices

W1siziisijiwmtkvmdgvmjevmtmvmjavmtgvndi3l0xpz2h0ynvsyibtb21lbnqgkdeplnbuzyjdlfsiccisinrodw1iiiwiodawedy1mfx1mdazyyjdxq

Shelli Gafan Software, Products

Guest blog post by Hans van den Elsen

 

You have a great PHP application for bookkeeping. It’s a well-used product and downtime is highly undesirable. After a few sprints, the new version is ready. All the test engineers, software engineers, product owners and scrum masters have worked their ass off the last week. All is well and right on time, the new version is ready to deploy. You log in to your server, you use a git pull for the last tag (because who’s using FTP anymore?). Pull succeeded. You open the website. Your custom error page is visible. What the F*-#?! Total panic and you check the error logs. Apparently you’re missing a PHP module that was installed by default on development machines. Luckily this was an easy fix and within 5 minutes the application was running smoothly again. But it makes you think… what else is different? And how can I prevent this in the future.

This sort of situation happened to me a year ago. I have a product of which I’m very proud of - It’s called SOSvolaris for who’s curious – and this product grew into small, manageable applications, but I just did not have any guarantee of the performance on the production server. Since I grew up to be a big fan of JavaScript, I installed PM2 for managing NodeJS applications. There was an AngularJS front-end, two PHP backends and database of course. This was all installed on the OS. I’m getting goose bumps looking back at the situation. Something had to change.

I just did not have any guarantee of the performance on the production server

I have heard of containerization and I have successfully built applications in containers. This was awesome but I also knew there was a thing like container orchestration. I knew what it was, but had no idea on how to implement this. I asked Advance in IT for some references to experts on the topic. I found out I had 2 options.

Create a Kubernetes (or alternative) cluster or use Docker Swarm. I know the Kubernetes is the most logical/future proof choice. I really wanted to know the ins and outs, but came to the conclusion that this is where my expertise should stop. After all, I’m not an infrastructure engineer. Docker Swarm was a much more low-level way of getting this done. Same server, same IP and with only some docker-compose files I quickly realized a great swarm with, while writing this, is already about 10 containers. It works great for me. So we now have a fancy new environment where we are using:

  • Continuous Integration for building Docker containers
  • The same Docker Swarm in production and staging
  • docker-compose for our dev environment
  • Tags for version management and injected in the container at build-time

This is for us the stepping stone to a new, fancy environment where we can easily upgrade to Kubernetes when necessary.

I would really advise product owners to take a look at their infrastructure. As a product owner myself, I know there is a choice to make. Listen to the engineers (whom will probably tell you that Kubernetes is the most scalable option), but also listen to management. They will probably try to postpone extra costs for something that already works. – “It has never gone wrong up until now right? And it was only 5 minutes.” – Both are very valid arguments but see for yourself where your company profits most. Maybe it’s like us where we took this stepping stone.