Microservices. Demystified


BY Bogdan Kulbida / ON Dec 17, 2018

The central idea of building Microservices architecture is to split functionality into cohesive verticals which aim to solve specific issue in the domain. Microservices architectures are driven by the domain problem and not by the technology it uses. As such it might be challenging to split your monolith application because it requires complete rethinking of the architecture and the domains that are involved.

Architectural Complexity needs to first be addressed. For Microservices, architectural complexity comes into play when it comes to interactions between individual services that implement specific domain. For instance, dealing with async communications, cascading failures, data consistency problems, service discovery or authentication of services. All of those are crucial for successful and hassle-free Microservices operation.

Here are some benefits of Microservices.

  • Agility - embraces the change and minimizes the cost of a mistake;

  • Innovation - responsibility and accountability foster a culture of ownership for services. The low cost of failure creates a culture of rapid change and speeds up a feedback from the experiments;

  • Quality - since it is possible to measure success or failure you can concentrate on quality and incremental development;

  • Scalability - scaling can be completely automated. Resilience of the application can be improved because failing components can be easily and automatically replaced.

  • Availability - It might be easier to implement failure isolation. Health-checks, caching allow you to reduce the radius of a failing component and to improve overall availability.

  • Delegation of Responsibilities - each Microservices can be outsourced to a different team.

Characteristics of Microservices or what distinguishes other monolith architectures from Microservices architectures are as following:

  • Decentralized units – they are distributed systems with decentralized data management, don’t rely on a unifying schema in a central database. Also each Microservices may have its own view on data models;

  • Independent units – can be changed, upgraded, or replaced independently;

  • Do one thing but do it well – designed for a set of capabilities and focuses on a specific domain;

  • Polyglot persistence and programming – built with any language or technology.

  • Black box units – encapsulates what it does inside a black box and hides all the details besides the public API;

  • You create it; you deploy it – DevOps approach is used throughout the development process.

Challenges of Microservices

Here are some of the challenges of using Microservices. It is not a silver bullet for sure, but, the challenges as we see them are:

  • Distributed systems - requires stable network communications and for newcomers it is easy to fall into thinking that networks are fast and connections are reliable with a zero latency and the bandwidth is infinite;

  • Migration - requires you to determine the right boundaries for the Microservices and requires it to disentangle code dependencies going down the dependency chain;

  • Versioning - requires you to establish versioning for your endpoints, such as routing based versioning, etc;

  • Organization - requires development and release team structures and require DevOps mindset within the team;

  • Cost - can become very expensive if not properly managed or organized.

Since standardization and automation are keys to building speed, consistency, repeatability and scalability - those must be adopted as early in your process as possible. Also if you can rely on Managed Services that your cloud provider provides - you may want to consider using them.

Since communication is vital between your Microservices, think about latencies and make sure your services are formed in a coherent group to avoid expensive roundtrips. Implement caching if needed or use CDN if that involves static files.

You may also want to have a well defined data migration strategy and support data update roll-backs. You probably may want to think about a single place to change your data schemas and make sure your services are notified with such data provision update.

Splitting your infrastructure into Microservices is not that hard. What is hard though is when it comes to managing and orchestrating your fleet of services. If you are a small team of developers or a start-up, our general suggestion is to find a very good Cloud provider that already has ways to mitigate all the challenges that you will definitely be faced with.

If you need help with your project and are thinking about moving your monolith platform into the Microservices world we can help.