Microservice Architecture is the common choice these days for modern engineering teams. While it is scalable, resilient and future-proof, it poses significant challenges for testing and managing the architecture.

Managing a small microservice is theoretically easier than managing a large monolith. However, the picture isn't as obvious when discussing dozens or even hundreds of microservices. It becomes impossible to manage that many services individually or manually, hence the popularity of orchestration software platforms like Kubernetes, Docker Compose, Docker Swarm, Amazon ECS and others. Those tools were born from the need to manage a growing number of microservices. Oftentimes, these tools are even tough to manage themselves, causing developers to use managed solutions such as Amazon EKS, Microsoft AKS, or Google’s GKE to name a few.

Microservices Testability

Monolith

Monolith is a mature architecture that has been used for close to 30 years. It has many available testing strategies, the leading strategy being end-to-end testing that usually automates browsers to test a system end-to-end, focusing on user flows.

End-to-end solutions work best when the entire system can be tested as a blackbox to potentially surface most problems.

Microservices

Microservice architecture is relatively new and complex, especially when combined with tools such as Kubernetes and Docker that have great influence on the system's behavior.

While testing a single service in a Microservice architecture is easy in theory, it often isn’t easy in reality. This is because services are usually part of a larger business-logic dependent on other services to complete the logic. There are practices to support service-testing (e.g. mocks, API-contract testing), however, they are very complex and costly to implement.

If you look at modern Continuous Integration (CI) pipelines, services often become inaccessible, due to residingunder many layers of network and security operated by an external orchestrating software such as Kubernetes. Overall what was meant to be a federation of lightweight, de-coupled, and testable services becomes very challenging to test and prevent faults from reaching production.

Managing Microservices (manageability)

Monolith

Monoliths can be managed by their developers with minimum overhead for deployments.

Microservices

Microservices require management, otherwise it becomes impossible to grow the number of services and reap the benefits. While one can build their own management solution, it is more likely that they will adopt one of the available orchestration solutions such as Kubernetes or Docker, or opt to use a managed service such as ECS, EKS, GKE, AKS, Openshift or others. In any event, Microservice Manageability is not only an overhead expense, it also requires a ‘devops’ skill-set different from a pure developer skill-set. Hence, at the early days of the life cycle, the scarcity of the skill set and the overhead of implementation can inhibit necessary velocity.

Conclusion

The benefits of a Microservice architecture are quite obvious, however this architecture also provides its challenges. Due to the popularity of this architecture, the open source community as well as commercial vendors have come up with solutions to overcome the challenges and reap only benefit from transitioning to a Microservice architecture. Open source tools like Kubernetes and Docker, vendors Like Microsoft, Amazon, Google, Rehat and others have come up with a managed solution to ease the management of Microservices. There are also companies that have come up with a solution to make Microservices testable. UP9 is such a company.