Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
This is an article from DZone's 2022 DevOps Trend Report.
For more:
Read the Report
Enterprises are embracing cloud-native technologies to migrate their monolithic services to a microservices architecture. Containers, microservices, container orchestration, automated deployments, and real-time monitoring enable you to take advantage of cloud-native capabilities. However, the infrastructure required to run cloud-native applications differs from traditional ones.
This is an article from DZone's 2021 Kubernetes and the Enterprise Trend Report.
For more:
Read the Report
Kubernetes is the industry-standard technology used by enterprises to deliver microservices-based container orchestration platforms. The Kubernetes ecosystem is growing rapidly and has a vibrant community that has built several free open-source tools and extensions to make it easier to run your workloads. This article will explain some of the more popular open-source Kubernetes tools used for development, monitoring, and deployment purposes that can improve your cloud-native experience.
Microservices communicate significantly over the network. As the number of services grows in your architecture, the risks due to an unreliable network grows too. Handling the service to service communication within a microservices architecture is challenging. Hence the recommended solution has been to build services that have dumb pipes and smart endpoints.
The first fallacy from the comprehensive list of ' Eight Fallacies of Distributed Computing ' is that the 'Network is reliable.'
Kiali lets you monitor, visualize, and configure the Istio Service Mesh from within a single user interface. Kiali lets you view configurations, monitor traffic flow between services, and analyze traces. It provides visibility into features likes service health, request routing, circuit breakers, request rate, traffic flow, error rates, and more.
Once you have a number of services deployed inside the service mesh, you will have a number of questions around Istio observability:
In a dynamic cloud environment, there can be scenarios when there are intermittent network connectivity errors causing your service to be unavailable. These issues are generally self-correcting and if you retry the operation after a small delay its most probably going to succeed. You need to design your microservice architecture to handle such transient errors gracefully.
The Retry Design Pattern states that you can retry a connection automatically which has failed earlier due to an exception. This is very handy in case of temporary or one-off issues with your services. A lot of times a simple retry might fix the issue. The load balancer might point you to a different healthy server on the retry, and your call might be successful.
As enterprises transition from a monolithic to microservices architecture, they have found it difficult to manage the service to service communication and handle functionalities such as security, traffic control, resiliency, monitoring, metrics, and logging. More requirements like A/B testing, canary releases, rate limiting, policy enforcement, access control, and end-to-end authentication become another burden. Istio solves such complex requirements while not requiring changes to application code.
A service mesh allows applications to offload these capabilities from application-level libraries to a separate infrastructure layer and allow developers to focus on the business logic itself. Istio is one of the best implementations of a service mesh.
The Timeout Design Pattern states that you should not wait for a service response for an indefinite amount of time — you should rather throw an exception instead of waiting for too long. This will ensure that you are not stuck in a limbo state while continuing to consume application resources.
In my earlier blog post, I discussed the fallacies of Distributed Computing and how service calls made over the network are not reliable and might fail.