Decoupling
into the Microservice Architecture

Our teams will successfully migrate your system or monolithic applications into a microservice architecture with minimum system downtime.

alexey-kovsh

Alex Kovsh

Senior Solution Architect

“We have tons of expertise in the microservices architecture and deep domain knowledge in different spheres. I'm ready to have a quick talk with you to check whether our developers could help.”

Decoupling Options

There are several major steps in every decoupling project to get the most efficient microservices architecture:

  1. Existing state analysis — we research the current monolithic architecture to identify the first microservice candidates, refine and approve the new microservice architecture.

  2. Building the infrastructure — the team adopts and prepares the virtualization infrastructure, the container orchestration system, CI/CD tooling, and internal artifact repository.

  3. Development phase — we implement different microservices according to the defined roadmap and put them into the new infrastructure.

  4. Deployment — our DevOps engineers deploy the new system with the microservice architecture into the pre-prod and production stage.

  5. Maintenance and support of the microservice infrastructure.

We use different models when migrating to microservices, depending on the specifics of the project.

One-Time Migration (SADT)

It starts with a solution architect who defines subsystems and their interfaces, prepares the vision of the infrastructure for the microservices architecture, and creates the skeleton for the future system. Other team members join only after the full picture is clear. This is one-time migration — the new system won’t start until it’s fully ready to replace the old one.

This approach to the microservices architecture allows for better analysis of the future project and lower project costs (due to optimization of team resources). Also, it requires fewer developers at the start and lower qualifications from engineers during the implementation phase (costs).

One-by-One Migration

A nice option for the systems under active development requiring fast deployment. New microservices replace the old system parts one by one.

This is a typical "quick win" approach to service decomposition of the monolithic architecture. We do not spend a lot of time on detailed analysis of the monolithic application and upfront design of the architectural style. Instead, we start with 1-2 loosely coupled individual services and move them into the microservices architecture, creating the infrastructure for this. The decoupling process looks like one-by-one migration to microservices.

This option is the most typical for monolithic software where the implementation of new features/functionality is in progress (most product development projects).

Please, do not hesitate to contact us if you have any questions regarding your vision of the microservice architecture.

How to Start Decoupling

Service Team (Micro-team) – group of engineers who already worked together and know how to do certain task/project.Service Team (Micro-team) – group of engineers who already worked together and know how to do certain task/project.

Ky-ky, я дропдаун

Ky-ky, я дропдаун

Ky-ky, я дропдаун

Our teams use the following criteria to define the first blocks for decoupling into the microservice architecture:

Cutting off stateless components

The system consists of stateless and stateful components. Stateless services that are relatively independent of each other are cut off from the system to become part of the microservice architecture.

Functional decoupling

- Services which work with external systems (gateways, payment modules)
- Authentication server
- Notification module

Then we start decoupling other services: approve a set of functional services, draw a services dependency graph and prepare a decoupling plan. We prioritize individual services by business value and external dependencies and split the leaf services first.

Logical Architecture Diagram

Intermediate state (after decoupling of 1-2 services)

The same microservice architecture with the communication layer

If the existing code fits for the purposes of the microservices, we reuse it to the fullest extent possible. In this case, you save some dollars on development and testing.

Our Teams

No need for individual staffing. We have already assembled and balanced engineering teams ready for onboarding and focused on microservice-based projects with good experience in monolithic application decoupling.

Established team process – task management, quality control, delivery of results, and so on

Service Team (Micro-team) – group of engineers who already worked together and know how to do certain task/project.Service Team (Micro-team) – group of engineers who already worked together and know how to do certain task/project.

At least 2 projects in common for every team member

Ky-ky, я дропдаун

Team specialization and focus on microservice-based projects

Ky-ky, я дропдаун

Existing business expertise for
certain domains

Ky-ky, я дропдаун

Project Team Structure

Decoupling projects usually require quite a typical team structure (however, some variations may occur from project to project).

The team may include both back-end and front-end developers and in some cases full-stack developers. And for bigger projects, we create project teams based on a set of service teams thus making the whole staffing process easily scalable.

We may send you a couple of available team profiles within 3 business hours from your request time.

Technical Expertise

Decoupling is impossible without starting an infrastructure project. Basically, microservices need a special environment to run properly and to provide all related benefits when deployed independently. You should give a think to and establish:

Orchestration
(Kub8s, Docker, etc.)

DevOps and CI/CD
processes

API gateway

Health monitoring

Communication between microservices

Our team can do the infrastructural project for you to guarantee seamless migration to microservices.

Technology

We have deep experience with a set of related tools & new technologies which we professionally use.

Please note: Our solution architect may define the technology stack after an initial review of the application architecture. Check here our reference architecture for decoupling projects.

Cloud

MS Azure, AWS (Amazon Web Services), GCP (Google Cloud Platform)

API Gateways

Ocelot, Tyk, Nginx; cloud: AWS API Gateway, Azure API Management, GCP API Gateway

DevOps Tools

Ansible, Helm

CI/CD Tools

Jenkins, Thoughtworks GoCD, TeamCity; cloud: Azure DevOps

Health Monitoring, Logging

Prometheus/Grafana, Elastic Stack (Elasticsearch + Kibana), Zabbix, Logstash

Containers (Orchestration)

Kubernetes, Docker Swarm, MS Service Fabric; cloud analogs: Azure AKS, Azure Service Fabric, AWS EKS, Google GKE, etc.

Messaging

Apache Kafka, Rabbit MQ, Active MQ, MS SQL SSBS; cloud analogs: AWS SQS, Azure Service Bus, GCP Pub/Sub, etc.

Reference Architecture

Qulix offers you to follow our well-tested practices in building the best microservice architecture for your project. See our reference architecture to find what technologies we use for the best results.

Single Microservice Structure

The following high-level architecture is used for a typical single microservice.

We Need This for the Assessment of Your Project

Current system architecture and technical design description

Technical documents depicting the software architecture including logical & deployment views, the list of technologies, UML/DFD/Network diagrams (if available)

Functional modules and requirements

Software Requirement Specifications (SRS) or at least some high-level hierarchical view on functional modules and features

Non-functional requirements for the current and decoupled systems

Technical requirements for both the current and new systems, such as Service Level Agreement (SLA), performance, accessibility, reliability, scalability (horizontal, vertical), data integrity, etc.

Access to source code
(optional)

Access to the source code during the assessment phase is not a must, but a nice-to-have option that will also ensure a more accurate estimation.

No worry in case you do not have the listed information. Our software architects will be able to define how to deal with it.

Additional Points to Consider

Shorter Time-to-Market

Splitting a monolithic architecture allows making each service highly testable and easy to use. It enables rapid development and frequent independent deployments through the CI/CD process.

Parallel Implementation

In the microservices architecture, each service is loosely coupled with others. It enables us to build an independent small team to deploy, change, and redeploy one service without affecting the other.

Easy Regression Testing

No need for complex regression testing of the entire system when any change is made to the code — only the changed service shall be tested (assuming the API is consistent).

Higher Fault Isolation

If a single module fails, it does not affect the performance and stability of the application as a whole. Thus, the microservice architecture is protected from a complete shutdown.

Of course, there are certain difficulties and issues we need to deal with when working with the microservice architecture. Contact us and we will send you the list of our technical best practices regarding microservice architecture implementation.

Contacts

Thank you, !

Thank you for contacting us!
We'll be in touch shortly.

Go back to the home page

Feel free to get in touch with us! Use this contact form for an ASAP response.

Call us at +44 151 528 8015
E-mail us at request@qulix.com

Thank you!

Thank you for contacting us!
We'll be in touch shortly.

Go back to the home page

Feel free to get in touch with us! Use this contact form for an ASAP response.

Call us at +44 151 528 8015
E-mail us at request@qulix.com