My experience with the Microservices approach


So it was like a few months ago when a friend and co-worker first told me of the microservices approach. As you might or might not know I’m part of a Site Operation team where we provide service to a sometimes complicated client in terms of bureaucracy, which means that we have to adapt to their policy changes and permissions all the time making most of our work complexity quite arbitrary. It was then when we thought that a service-oriented approach might save us some time on the day to day tasks. Before telling you my experience I invite you to read about what service-oriented modeling (SOM) is.

My experience

The idea of making our daily work more service-oriented was already rumbling in our heads when we first set a meeting with our manager and told him what we have in mind. A few words with him and one or two rough drafts opened our way to a more formal meeting with the whole team in order to present what was going to be “The future of Sitetops”, a “New way of working”, “A game changer”, “The microservices approach”. The SAAS (SiteOps as a Service) project.

We had one week to prepare some slides and think how we were going to convince the rest of the team that this was the way to go. After a long meeting with quite a lot of arguments and motivational quotes on how this would be a great solution to our problems the meeting got to an end. It was a fact, from that moment until now, our job was to think in a more service-oriented way.

Along with the now urgent need to make everything-as-a-service me and my friend got assigned a new development project. We had two months to develops a fully MVP that would interact with our client’s ticket manager in order to easily and quickly manage all the incidents on the site. The aim of the tool was to somehow centralize all the ways our client had to report and incident over the different communication software with just a few clicks. So after a quick analysis we realized our app would have to communicate with at least 3 of our client services/tools. It was the perfect excuse not to leave our idea of Microservices die along with all the words said in that meeting. Now let’s make a list of the problems we had by that time.

Problems to solve

Our main difficulty was that we had quite a lot of scripts that interacts in very different ways with the different applications the client has. Whenever anything changes on their side, most of our monitoring failed. Debugging where the error was coming from was a pain in the ass. And the worst of all were those critical alerts that are supposed to be triggered on very specific occasions but when they do you know the thing’s fucked up, well, those always failed silently and we rarely realized on time .
Another big issue was that a significant amount of code we had running was kind of legacy, and legacy is polite way of saying it was written in Perl [* Takes a deep Breath… continue writting. *]. And as you might know Perl doesn’t have that magic from problem import solution Python does. Making easier to manage this kind these complex and large lines of code was something that needed to be solved.
Even if we got the opportunity to do the thing in a language of preference, some of their APIs were quite difficult to work with and the lack of consistency between them was something we needed to get rid of. Oh! they also expected us to hand in a fully functional MVP in two month.

How we faced the problem

After telling everyone how we were planing to solve this stack of problems with a single .pop() the most heard and trendy tech to use was Serverless. Since we didn’t have a clue what Serverless was we decided go for it. And we did, we established that if we couldn’t manage to have a simple serverless API up and running by the end of the week we would evaluate doing it with containers or just common web servers. The POC was a success and by a day or two we got our first AWS Lambda function up and running on the cloud, completely serverless.
In something like two months or so we had a single app that consumes 3 independent services (also developed and deployed along the development of the app) which were able to quickly escalate and could be reused by the whole team for there daily operations.Of course as each service is context agnostic, they have their own repo and they are independently deployed.

Our app infrastructure looked something like this:

App Infrastructure + 3 microservices
By the end of the project we got a the MVP ready and with it an application fully composable that can be selected and assembled in various combinations to provide its functionality to a broad variety task to solve a wide variety of problems.

I’m proud to say that at least three problems were addressed:

1. Abstract away complexity of the apps and tools that don’t depend on us. Making them consumable from literally anywhere.
2. Centralize the problem of the unexpected mutability of our clients apps making it easier to solve and debug.
3. Handing a fully scalable and high reliable system which is the running prove that a service-oriented modeling approach can prevent quite a lot of headaches in the future.


Sometimes working with new technologies can mean getting out of our comfort zone leaving us in an insecure place in a field we might have short or not knowledge at all. But we have to take into account that we are not alone, we rarely pioneers in what we are doing and if you are lucky you can find people who have written some good documentation addressing the same problem you are going through right now. Then, it’s just a matter of learning the new and convince ourselves that it’s better to solve the problem the way is meant to solved rather than the way we would like to solved it.

If you got up to here, thank you very much for reading if you have any questions/opinions or you’ve found any mistake on the text please feel free to write me, my contact details can be found in the /about section.

Bibliography and technology used in this project

Author: Lucas Contreras

Leave a comment: Join the Reddit discussion