You can just call us +4 143 508 0794

QAREA BLOG

home / blog / Using Microservices Architecture to Break Your Vendor Lock-in

Microservices — please, do

August 2, 2018

Leveraging the Internet of Things to drive improvements in logistics industry

August 9, 2018

Using Microservices Architecture to Break Your Vendor Lock-in

August 6, 2018
Microservices Architecture
Internet of things in logistics and transportation
Using Microservices Architecture to Break Your Vendor Lock-in

Complex projects become messy so quickly that companies end up being completely dependent on their development vendors. Once you chose a team, your hands are tied (seemingly forever).

Anyway, that’s how it usually works, and here is why.

Most applications are built with a standard approach.

This approach is usually called “monolithic”.

Monolithic Architecture

This is how monolithic architecture looks like. Well, at the beginning of development.

It’s simple to deploy, easy to build, to support…

…until it becomes a monster whose whims are frequently beyond your immediate control.

 

Broken Monolith Software Architecture

A broken monolithic architecture. Doesn’t look good, doesn’t work well.

It all works out, but suddenly you notice your monster deploys much slower, backups are not so fast anymore, and you can’t scale the product just by moving it to a more robust server. Something is wrong.

Your Vendor, the outsourcing development company you trust, creates more bugs than it resolves. The team is good, but you both made a mistake developing your project as a monolith. The team knows that you can’t go to another company, because a new vendor will need months of learning, and they know you know that. It’s something called the vendor lock-in.

It seems like there is no way out. Luckily, there is a chance you may find a vendor that will propose to build, or rebuild the project in a microservices architecture.

Microservices is a software development technique — a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services.

Wikipedia

Microservices Best Practices

When supporting your project, your previous, or new vendor, will start by delimiting independent parts of business logic into microservices.

Breaking up a Monolith

 

Now you can perform acceptance testing to ensure each service has its own small and scalable database which can be transmitted to other server, with much simpler and understandable API documentation. The added bonus—no vendor lock anymore!

 

Our example of microservices: Recently we developed DueFocus, an application for time and resource management for efficient project management. We chose to go with Golang microservices primarily because of freedom it gives. We can quickly test and modify any function without affecting the rest or being dependent on a particular team while Go for backend gives us great speed.

Continuing your decoupling process, you will get multiple microservices. At QArea, we prefer to do this using Golang as it’s a fast, lightweight, easy to write and read programming language. Also, we love Golang’s server performance.

Database Scaling

The scheme of database scaling in microservice development

 

Every microservice now can be deployed on separate server. Database of each one may also be scaled to separate server. They even can be written with different languages: we do Golang projects, for example, but other teams are free to choose their own solutions. Each microservice can be supported by different vendor and you get rid of that annoying vendor lock.

Monitoring microservices is a piece of cake

Every vendor can deploy every microservice independently, so you can assess high performance and skills separately. You will be playing completely different role rewarding successful vendor by adding more microservices to support, or in case of low performance, moving microservices to other, more skilled vendor.

Microservices VS Vendor Lock-in

Instead of that messy monolith you get a beautiful architecture of well-functioning microservices

 

Surely, it’s not the only reason microservices are loved for. They are also easy to test and modify, fast to run and comply. The main thing, the essential reason why microservices appeared in the first place is that they give freedom. That’s why we at QArea prefer building microservices instead of traditional monoliths. If you’d like us to take a look at your existing project or develop a new one, drop us a line.