Deep systems, with multiple layers of microservices, have special challenges, and handling them requires the right mindset and tools.
When using microservices architecture to build a successful product, a product that needs to rapidly grow, sooner or later, you realize that your system becomes "deep."
The depth of a system can be considered as the number of microservices layers in the application stack.
Today’s forefront cloud technologies, such as Service Mesh, Containers, and Serverless computing, enable teams to easily add many microservices layers to their system.
NGINX Plus is the complete application delivery platform for the modern web. **[Start your 30 day free trial.**](https://www.infoq.com/infoq/url.action?i=18207&t=f)
A microservice within such a system is not actually independent - it relies on other microservices and vice versa.
When microservices communication grows deep, it complicates the company’s ability to quickly diagnose errors or performance bottlenecks.
Therefore, deep systems are a serious challenge for R&D teams who want to sustain resilience, fault-tolerance, and performance.
Without the right mindset and the right tooling, the product and it’s customers will be jeopardized.
It’s possible to build complex systems, with deep chains of microservices, without compromising on resilience.
Here are 3 ingredients that can help you nourish resilience in deep systems.
When designing complex applications using microservice architecture, we’re looking to define a set of cohesive and loosely-coupled services. One of the biggest questions in that regard is, how will we break down our application into microservices?
Because microservices architecture essentially follows the Unix philosophy of "Do one thing and do it well," you could simply say that each atomic function should be a microservice (i.e. the hype). While in theory it sounds perfect, simply following that philosophy can create an enormous amount of microservices. Are you going to be successful in maintaining that many services effectively?
I’m going to provision the "integer" service in us-west-1
Said once a hyped developer
In reality, we found that defining microservices that correspond to a real business capability will result in a sane amount of self-contained pieces of business functionality. Those pieces can still be very cohesive, loosely coupled, scale well, be testable, built, and owned by a small enough team. All of which are the pillars of microservices.
Moreover, it’s a common practice to avoid code duplications in multiple microservices by creating a shared library, i.e. DRY (Don’t Repeat Yourself). DRY is an important concept. Yet, sometimes too hyped. In reality, we found that sometimes shared libraries couple our microservices to each other, reducing the effectiveness of the isolation and independence between the microservices. It also slows down teams from making changes, since they are not always fully aware of the usage patterns of other teams. In fact, balancing microservices granularity goes hand in hand with balancing the right amount of shared libraries. Both shared libraries and code duplication are a burden in hyper-granular microservices architecture. But when keeping a balanced microservice granularity, the price of code duplication can pay off as increased independence.
Design systems are interdisciplinary by nature. They are built and consumed by designers and developers, therefore it is important for common terminologies to exist to support the communication between these two disciplines and other related actors.
In this article, take a look at the service mesh in the microservices world. The software industry has come a long journey and throughout this journey, Software Architecture has evolved a lot. Starting with 1-tier (Single-node), 2-tier (Client/ Server), 3-tier, and Distributed are some of the Software Architectural patterns we saw in this journey.
Companies need to be thinking long-term before even starting a software development project. These needs are solved at the level of architecture: business owners want to assure agility, scalability, and performance.
For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility.
Microservices is one the hottest buzz word in the Software Industry, but what exactly is a microservice and what are the ways in which it can be designed, this will be discussed in this article with diagrams and explanation.