Chapter 5. Conclusion

In many respects, the advent of cloud native is marked by the introduction of Docker. The popularization of containers brought the need for orchestrators. In turn, containers and orchestrators, coupled with the popularity of microservice architecture for their speed of development, smaller surface area to reason over, and decoupling of development teams, lead to service sprawl. The ability to run a number of distributed services brought the need for empowering developers, operators, and service owners with a service mesh.

Service meshes are one layer of your infrastructure and don’t bring all that you need. They do give you the ability to bridge the divide between your infrastructure and your application in ways most people have not previously seen, however. Service meshes and where they layer into the infrastructure makes them ripe with possibility beyond what they are being used for today. We will see growth in the following areas of service mesh usage and see how they change how developers write applications and how product owners manage their services:

  • Refine developer experiences by:

    • Offering distributed debugging.

    • Allowing developers to skip past building in many user/tenancy segregation considerations and instead rely on the service mesh to provide enforcement based on configuration, not application code.

  • Provide compelling topology and dependency graphs that allow you to not only visualize the service mesh and its workloads but design them as well.

  • Participate in application life-cycle management but would benefit from shifting left to incorporate:

    • Deeper automated canary support with integration into continuous integration systems, which would improve the deployment pipelines of many software projects.

    • Automatic API documentation, perhaps, integrating with toolkits like Swagger or ReadMe.io.

    • API function and interface discovery.

  • Participate in service and product management by enabling service owners to offload any number of examples of application logic to the service mesh, allowing developers to hand off “application infrastructure logic” to the layer just below the application—Layer 5:

    • Perform A/B testing directly with service users without the need for developer or operator intervention.

    • Control service pricing based on the accounting of service request traffic in the context that the tenant/user is making these requests.

    • Forgo requesting specific application logic changes from the development team and instead deploy a network traffic filter to reason over and control user and service behavior.

  • Deeper observability to move beyond distributed tracing alone and into full application performance monitoring leverage deep packet inspection for business layer insights.

  • Multitenancy to allow multiple control planes running on the same platform.

  • Multicluster and cross-cluster such that each certificate authority shares the same root certificate and workloads can authenticate each other across clusters within the same mesh.

  • Cross-mesh to allow interoperability between heterogeneous types of service meshes.

  • Improve on the integration of performance management tools like Meshery to identify ideal mesh resiliency configurations by facilitating load testing of your services’ response times so that you can tune queue sizes, timeouts, retry budgets, and so on, accordingly. Meshes provide fault and delay injection. What are appropriate deadlines for your services under different loads?

  • Advanced circuit breaking with fallback paths, identifying alternate services to respond as opposed to 503 Service Unavailable errors.

  • Pluggable certificate authorities component so that external CAs can be integrated.

Adopting a Service Mesh

There are many service meshes to choose from, as well as a variety of deployment models. Which is right for you and your organization depends on where you are in your maturity curve (cloud-native skill set), number of services, underlying infrastructure, and how centric technology is to your business.

So, should you deploy a service mesh? More and more, the answer is “yes.” Service meshes are quickly becoming a ubiquitous layer in modern infrastructures. Table 5-1 shows the factors to consider.

Table 5-1. Factors in considering how strongly you need a service mesh
Concern Begin considering a service mesh Strongly consider a service mesh Consider that..

Service communication

Low interservice communication.

High interservice communication.

The higher the volume of requests to internal and external services, the more insight and control you will need and the higher the return on investment your service mesh will deliver.

Observability

Edge focus: metrics and usage are for response time to clients and request failure rates.

Uniform and ubiquitous: observability is key for understanding service behavior.

You can bring much insight immediately with little effort.

Perspective from which you think of your APIs

Strong separation of external and internal users. Focused on external API experience. APIs are used primarily for client-facing interaction. APIs are for clients only.

Equal and undifferentiated experience for internal and external users. APIs are treated as a product; APIs are how your application exposes its capabilities.

Service meshes are infusing API gateway and API management functionality. Deploy a mesh early to have your architecture ready for scaling.

Security model

Security at perimeter. Subnet zoning (firewalling). Trusted internal networks.

Zero-trust mindset. authN and authZ between all services. Encryption between all services.

The security characteristics are desirable qualities of any deployment. Apply defense-in-depth. Why not pull these into a single layer of control?

# of services

A couple of services.

A few services or more.

Deploy a service mesh early. Doing so lowers risk and affords you time to become confident with the operations of a service mesh.

Service reliability

Either don’t need or are willing to hand code or bring in other infrastructure to provide resiliency guarantees.

Need strong controls over the resiliency properties of your services and to granularly control ingress, between, and egress service request traffic.

Resilient infrastructure and highly available services are ideal in any environment. Let the service mesh do the heavy lifting for you.

I recommend starting small, with the lowest-risk deployment model. I consider the lowest-risk deployment model to be one focused on observability, primarily because gathering additional telemetric signals is more about observing service and system behavior than it is about augmenting them. As you roll out your service mesh, understand that failures in the environment can misplace blame on the service mesh. Understand what service meshes do and what they don’t. Prepare for failures by removing a culture of blame. Learn from failures and outages. Familiarize yourself well with service mesh troubleshooting tools and built-in diagnostics of your service mesh, for example:

  • Use Meshery to identify antipatterns and also to analyze the state and configuration of your service mesh against known best practices.

  • Inspect service request headers with your service mesh and annotate when requests fail to help you identify whether the failure is in your workloads or the service mesh.

Show immediate value. Observability signals are a great way of doing so, and Linkerd makes this simple:

$ linkerd stat deploy --from web
NAMESPACE  NAME   MESHED  SUCCESS RPS    LATENCY_P50 _P95 _P99
emojivoto  emoji     1/1  100.00% 2.0rps 1ms         2ms  2ms
emojivoto  voting    1/1   72.88% 1.0rps 1ms         1ms  1ms

When choosing a path, I recommend embracing an open platform that is adaptable to existing infrastructure investments and the technology expertise you already have. Choose a project that embraces open standards and is API-driven to allow for automated configuration. Given that not all open source software is created equally, consider its community, including project governance, number and diversity of maintainers, and velocity. Recognize your comfort in having or not having a support contract. Understand where OSS functionality stops and “enterprise” begins. Embrace diversity in your technology stack so that you’re open to selecting best-fit technology and can experiment when needed. Realize the democratization of technology selection afforded by microservices and the high degree of control afforded by a service mesh. Don’t leave value on the service mesh table when you can expect more from your infrastructure. Account for whether your organization has different skill sets with potentially differing subcultures. Understand that technology evolves and will change. Ensure you have the ability to change as all architectures are in a state of evolution.

What if you only have one service? A lightweight service mesh with an ingress gateway and a service proxy can provide you with a high degree of control that you otherwise will have to deploy separate infrastructure for. Consider how likely it is that your deployment will grow beyond a single service. Having a service mesh present from the start means that you can avoid embedded infrastructure logic into your application code from the very beginning. It also means that you don’t have to tear down other temporary infrastructure during your deployment in the interim until you arrive at a more painful inflection point when you inevitably deploy a service mesh.

Generally speaking, my advice is to deploy a service mesh even in environments with only a couple of services and with only a few engineers and whether you are working on a homogenous application stack or not. Especially deploy a service mesh if you are not confident in the observability, not confident in the reliability, and not confident in the security of your application. Understand that the consideration of the size of your organization is orthogonal to the consideration of your need for a service mesh. Whether you run a service mesh yourself or seek a managed service solution is a consideration more heavily weighted by the size of your organization. Expertise and experience with successfully adopting open source infrastructure projects is another example of an orthogonal consideration as to whether you and your workloads will benefit from a service mesh. Again, this is more of a factor of whether to deploy and run a service mesh yourself or seek assistance from a vendor.

The fifth layer of distributed systems is here. There are plenty of options to choose from. It’s time to expect more from your infrastructure. Take the third step in your cloud-native journey and deploy a service mesh. The untapped power of the service mesh might surprise you.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.135.207.129