Using Microservices Architecture to Break Your Vendor Lock-inby QArea Expert on August 6, 2018
Complex projects become messy so quickly that companies end up being completely dependent on their development vendors. Once you chose a dedicated development 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”.
It’s simple to deploy, easy to build, to support…
…until it becomes a monster whose whims are frequently beyond your immediate control.
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.
Microservices Best Practices
When supporting your project, your previous, or new vendor, will start by delimiting independent parts of business logic into microservices.
Now you can perform acceptance testing to ensure each service has its own small and scalable database which can be transmitted to another 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.
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.
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.