I work in a project that is in continuous growth. It started with a bunch of files in Visual Sourcesafe. For that time it was enough and worked fine. It was a thick client Application, a monolithic project with all the code centralized in only one place. The application was growing and was getting more complex to maintain. Also, the business was increasing and more people were using the application. The performance was affected. The application was migrated to a web project.

So, a solution to improve it was to install the application in more servers and put a load balancer to manage the traffic in different servers.

Time passed and the company migrated from VSS to Team Foundation Server and started using new technologies. For all this evolution a Continuous Integration process was needed.

The CI process was not so automatic. There were many manual steps needed to keep “the wheel moving”. In all these years the team I am part of (we are called “the Build Engineering Team”) were improving the continuous integration using Jenkins to deploy applications in many servers and using Microsoft Azure Pipelines to build a lot of code, among other things.

Now, we are taking a new step: splitting a few huge Build Definitions into small ones, to have more control on them. Having many small build definitions, allows us to have a continuous compilation for each project, and we can involve, resolve or let the developers know about the problem as soon as possible.

All these changes that the developers and we are doing, are to enter the new era of Microservices. Teams are gradually splitting the projects into small services. These microservices allow the company more scalability, also if some change is done on one service, it does not affect the rest of the applications. Another advantage is that each service can be developed using a different technology.

One of the main challenges is that the changes that we are making to implement these new microservices, don´t have to break any other functionality, unlike with the monolithic methodology, where if you change something, it can break the complete application.

Microservices give us many benefits, but also we have to be careful with the maintenance of them. We have to develop a good pipeline to have CI/CD working fast.

Other things that we are implementing together with microservices are Docker containers. They can bring an isolated environment for the software and ensure that it operates smoothly.

Currently we are in an early phase of our Docker implementation. We are testing a couple of microservices working under containers. We are getting issues related with connectivity between the container and other applications; and issues in Windows containers, Linux containers work better. Besides all the issues and the hard work, it’s going to be worth it. We are able to encapsulate a whole application in a single container with all the prerequisites and configurations that the application need to work. Dev team creates the docker compose file and then we build it using Azure Build definition. The image is created and uploaded to a repository. After the Build, a Azure Release deploy the image in a Linux server.

Last and one of the most important things about microservices is that the developers are more involved in all the pipeline, from the coding until its deploy of it in a container.

Would you like to know more? Do you need our help? Contact Us!
www.quadiontech.com

Moving from a Monolithic to Microservices Architecture was originally published in Quadion Technologies on Medium, where people are continuing the conversation by highlighting and responding to this story.