Microservices Architecture: SFL Approach - SFL

During the last 2 years have grown largely in popularity, becoming a common architecture pattern for developing enterprise applications. There are lots of public resources and books on this topic, as well as success stories from different companies. One of the most successful ones, by the way, may be Michael Fowler’s “Guide to Microservices”.

However, microservices in general isn’t what we want to look at with you. Let’s look at an example of microservices specific implementation pattern that lead to a success story.

The first steps on the microservices path

When was  still “news” in the tech world, we took the challenge to try it out in one of our projects.So in 2014, while working on SFL’s Qlim project we decided to implemet Microservices architecture.

Qlim wasn’t initially written using Microservices architecture, but rather in a way that kept in mind the possible future conversion to microservices which would operate independently with all of the positive advantages that they bring along.

What do we mean by saying the architecture “kept in mind” the possible transitions? When you work on a project, it’s takes lots of effort to design your monolith application in a way so that it can be later converted to microservices with little effort and in a short time. This is why the team has to base its work and domain model design on some core principles called high cohesion and loose coupling.

The main idea of these principles is that entities close to each other by ideology should be kept connected and close to each other, and at the same time the coupling should be loosened for the entities with different ideology.

On top of that, the general business logic up to the services layer which is the business functionality representation was developed adhering to the high cohesion and loose coupling principles.

Advancing the use of microservices

These were the initial ideas that we had during the Qlim project. Then at some point in the development process we felt that some entities could be separated. What challenges does that hold for the team? Actually, transitioning to microservices holds quite a change for the team itself: it is restructured.

The team members have to take on responsibilities for different parts of the application and add routine code development that’s connected with time loss and is somehow boring by nature because you aren’t developing the logic of the application, but rather various communication layers intended at keeping up the communication between the main application and its parts.

But our main motivation was that it was the most modern and technologically advanced project we took up, and microservices were quite new in use, too, so there was room for lots of experimenting. So, as the design was created keeping in mind future possible changes, we were on the right “playground” to master new skills.

Our first “microservices experience” was connected with our analytics data module. We made it in a way so that i wasn’t a successive module within our monolith application but a separate microservice which would communicate with the main application and its parts through an HTTP protocol.

Why did we decide to do so? Because the analytics module would keep unstructured data so it didn’t make sense to enlarge the main database and store this data in it. Therefore, after looking at a couple of solutions we made the decision that the most suitable approach for storing, aggregating and analyzing this data would be using a noSQL document-based database, particularly MongoDB.

So, the factor of using a separate database became decisive in making up our minds and setting off to use microservices in our projects enjoying the advantages of a separate database, a separate logic and a separate deployment procedure.

As our first attempt in  microservices, we can say that overall it was a success story and without corrupting our existing application code, we created a separate part which was generic and as a sales analytics part could be used in any e-commerce project afterwards.

Microservices for reusable parts of the project

The microservices architecture gives a lot of flexibility and freedom in terms of reusing some parts from the existing project. In case of the sales analytics tool that we had in Qlim, we could use it in any application that is e-commerce by nature and contains a product purchase flow ranging from choosing the product, configuring it, ordering the necessary number of items and processing the payment.

So, along with keeping the code clean, reusability of different components of the project is another benefit weighing in for the use of microservices.

In the Qlim project our striving was that the main code base would contain code related to the application’s business logic. So whatever could be considered a utility– be it analytics, a payment flow or user authentication parts which are present in any other similar application, were separated for a possible use in the future.

Creating other modules

As the time went by, we also started working on separating modules rather than creating them separately.

The sales analytics tool wasn’t part of the main application, but was developed separately. However, later, we separated several other utility components of the application, such as the location management service and the payment processing routines. Though initially it demanded a time span of 2 month, it was necessary as a proof of concept that the idea actually worked.

It proved that in a new startup project it’s not necessary to implement the microservices approach from the very beginning, but the team can create a monolith application keeping some concepts in mind, saving lots of time and effort initially, so  later, with minimal time and effort the team can separate some parts of the core application.

Another motivation is that because in the future we want to have an enterprise application capable of handling a large number of users and requests. With microservices, our back-end ecosystem is much more flexible in terms of abilities to scale. This way, with the help of advanced monitoring tools we can identify  the most loaded microservices, and instead of scaling the whole application both horizontally and vertically, we receive access for scaling the microservices separately.

Implementation in new projects

As the initial experiment we performed with Microservices was actually successful, some of these microservices such as the location services part and the payment processing part found their place as the building blocks for other applications.  At the same time was working on improving the design and adding containerization management tools like Kubernetes.

Staying flexible and agile

We chose “Microservices architecture agile methodology” for introducing microservices into the company. We didn’t emphasize having microservices-rich applications, spending lots of time effort without it proving successful, but the team rather started with the basics, little by little propagating microservices, tuning them, and finally arriving at an acceptable pattern for the team that would allow building microservices quicker and more efficiently.


Mher Sargsyan is a Senior Software Designer & Engineer

with a passion for machine learning

Leave a Reply