Microservice design has a direct impact on the network resilience of modern architectures. When organizations build microservices (whether in hybrid cloud, multi-cloud, or on-prem environments), it’s important to develop them, so they efficiently and effectively operate over the network, without causing excess latency, packet loss, and bandwidth consumption.
The impact of microservices on network performance
Microservices can be very chatty; consuming bandwidth and causing network congestion that can slow network performance and cause distributed applications to fail. When one microservice calls another, and the response isn’t happening fast enough, serious problems can result. This is what caused the GitHub outage last March, resulting in their system crashing for 8 hours. Essentially, the communications between databases created resource contention at a time when the network was at a peak load.
Resource contention is a lack of aligning microservices with network resources. For that matter, this misalignment can impact the computer memory, CPU, and disk, as well. As requests accumulate, the load on the network can reach the maximum number of connections it can handle. If communications between microservices becomes excessive, the resulting network, server, and database failures can be a cascading domino effect.
Microservices are dependent upon the network, and the network must be deployed to support the microservices architecture. It’s a highly symbiotic relationship. Services need to be optimized, as does the network which acts like glue to keep the services working together.
Leveraging a domain-driven microservices architecture
Deploying microservices to run efficiently over a resilient network requires collaborative communication between the microservice stakeholders. On the technology side, the domain experts can be developer, network, and operation teams. A domain-driven design approach is also where developers model complex software and business logic to meet the requirement inputs from the business domain experts in finance, sales, customer support, HR, and other departments. In addition to network benchmarking and testing the microservices, this collaborative practice pays performance dividends by reducing the communications between microservices.
Service discovery with optimized performance
When a microservice is published, how does the network (e.g., LANs, private WANs, public WANs, and cloud networks) know the microservice is there, and how is the microservice reached by the networks? The networking platform communicates with the container orchestration system (which automates software deployment, dynamic scaling, and management, etc.) to register the service and secure access. It tells the network where the services are, providing a single point of truth to where a microservice has been published. Using a networking tool that supports a variety of service discovery backends, like Kubernetes or Docker Swarm, is helpful here.
Once the orchestration is in place, there are tools and platforms that work with its information to make a service successful, meaning highly scalable and accessible with resilience. They accomplish this by automatically optimizing microservice chat flows, adding circuit breakers and rate limits to control resource allocation. There is a broad array of tools, like reverse proxy and ingress control, to integrate existing infrastructure with automatic and dynamic configurations. Enterprise-grade solutions, like Traefik Enterprise, also include a service mesh for enhancing visibility and management of traffic flows inside orchestrators.
Best practice recommendations for migrating to a microservices architecture
Following these best practices will make the most of your microservices migration and tap into all the benefits a distributed system has to offer.
1. Try event storming
Playing off the practices of domain-driven design, event storming is a group activity that helps improve understanding of the various user activities, information, what their needs might be, and how the service responds. This can dramatically streamline microservices communications using a simple approach that includes all stakeholders.
2. Implement scenario mapping
Scenario mapping helps the design team think about how various personas might approach a service and imagine the type of experience they want them to have. The persona experiences are run against service concepts with the workflow steps mapped, and then the successful ones are applied to the production environment.
3. Prioritize the network from the beginning
Prioritizing the network is one of the most important parts of a microservices architecture. Choosing the right tools and processes and aligning them with the network will ensure network resilience is a fundamental part of the microservice developments.
4. Automate as much as possible
Without automation, you have no chance of deploying and operating services at scale. Establish communication protocols among stakeholders with the right processes and workflow steps to ensure automated functions meet all business requirements. Some networking tools, like Traefik Enterprise, can be automated with practices such as GitOps or CI/CD to promote efficiency and save time.
5. Know why you are migrating to microservices
Is it for scalability, cost-efficiency, security, or resilience? Whatever your primary reason, align your migration strategy around it.
6. Ensure interoperability
Make sure your tools (e.g., orchestration, ingress controller, engineering tools, monitoring, service mesh, API gateway, etc.) and processes work together to prevent the architecture from becoming too complex and fragmented. Traefik Enterprise supports a variety of installations, infrastructure types, service discovery providers, and observability backends. It consolidates various networking functions into one easy-to-use interface.
7. Build in resilience
Defining microservices should involve an architecture that supports domain-driven design. This approach, together with the right technology and processes, will help you migrate and deploy a highly available, scalable, and resilient microservices platform. Choosing a solution that is resilient by default, like Traefik Enterprise, coming with redundant ingress proxies will make this step easy.
9. Consider Chaos Engineering
When developing a microservices-based architecture, and designing the network to support the services, consider Chaos Engineering. It tests distributed systems and the network through random disruptions. Chaos Engineering stress tests the network to discover problems and prepare it against failures using a toolset that deliberately tries to break it. You should chaos engineer various parts of your network, including your ingress solution. This will result in you learning more about your microservices and network and resolving problems before going into production.
It is not easy to maintain a resilient network in microservices-based architectures. With so many services communicating with each other across such a broad surface, there are many things that can go wrong. Build resilience into the network by optimizing your architecture from the beginning with these best practices. Choose the technology stack that will fill the gaps and is right for your use case. Doing so will set you up for long-term success.
If you’re interested in a microservice-ready networking solution that has built-in resilience and can facilitate other practices, look to Traefik Enterprise. It brings together ingress control, API gateway, and service mesh in one simple control plane. Try it for free, or watch a demo to learn more.Secure, manage, & scale all your APIs. Want to simplify API management and security? Request a demo today and see Traefik Enterprise in action.Request a demo
This is a companion discussion topic for the original entry at https://traefik.io/blog/9-best-practices-for-designing-microservice-architectures/