Getting the Most Out of Your Service Mesh

We know that there are multiple people within your organization who need to understand what a service mesh is and whether or not it’s right for you. Someone in Dev is going to have very different questions than someone in Ops. And an App Owner is going to want to better understand things like a service mesh’s impact on the bottom line. 

So we’ll begin in the same place, understanding the basics of a service mesh (what it is, what it does, and why someone might want it). And then we’ll split off into our own learning paths, having a more 1:1 conversation with each of you. At the end, we’ll come back together and see what a win/win/win could look like. 

Ready? Let’s dive in. 


What's a service mesh?Service Meshser-vice meshnoun
  1. a transparent infrastructure layer that sits between your network and application, improving communications between your microservices
  2. could be your next game changing decisions


Let’s get on the same page with some fundamentals.

A service mesh is designed to monitor, control and secure service-to-service communications in microservices applications. It ensures that communications are fast, reliable and secure. 

The mesh provides critical capabilities including: 

  • Service discovery 
  • Load balancing 
  • Encryption 
  • Observability 
  • Traceability 
  • Authentication and authorization 
  • Write-once, run anywhere policy for microservices in your Kubernetes clusters 

A service mesh also addresses challenges that arise when your application is being consumed by an end user—such as monitoring the health of services provided to the end user and then quickly tracing problems to the correct microservices. 

Now that you know what it is, why would you want it? 

We’ve been having lots of discussions with people spread across the microservices, Kubernetes and service mesh adoption curves. And while it’s clear that many enterprise organizations are at least considering microservices, many are still waiting to see best practices emerge before deciding on their own path forward. That means the landscape changes as needs are evolving. As an example, more organizations are looking to microservices for brownfield deployments, whereas even a couple of years ago microservices architectures were only considered for greenfield deployments. This tells us that as microservice technology and tooling continues to evolve, it’s becoming more feasible for non-unicorn companies to effectively and efficiently decompose the monolith into microservices.

Top three reasons to get a service mesh

In the past six months, the top three reasons we’ve heard people say they want to implement service mesh are: 

  1. Observability – to better understand the behavior of Kubernetes clusters 
  2. mTLS – to add cluster-wide service encryption 
  3. Distributed Tracing – to simplify debugging and speed up root cause analysis 

Gauging the current state of cloud-native infrastructure adoption, there’s no doubt that people are exploring and evaluating tools like Kubernetes and Istio. Leaders in the space are being closely watched – what are they implementing, how they are doing it, what challenges they are facing, and what benefits they are realizing. 

As more organizations successfully adopt these new technologies and benefit from outcomes around increased velocity, better resiliency and improved customer experience, laggards will be left behind. To remain competitive, organizations must actively map their path with microservices. 


Easing modern application management

More efficiently managing microservices 

  • Rapid development 
  • Easier testing and deployment 
  • Simpler to change and maintain applications 
  • Teams can make progress independently, loosely coupled by APIs 

Microservice-based applications come with some serious upside, but keeping track of every single service is a challenge – especially for the platform teams that can’t narrow their vision to a single microservice. If you’re operating or developing in a microservices architecture, there’s a good chance part of your days are spent wondering what your services are up to. It’s frustrating to move from service to service and have to relearn everything; how it’s configured, what telemetry you’ll have, how it manages certs and keys. 

With the adoption of microservices, problems also emerge due to the sheer number of services that exist in large systems. Issues like security, load balancing, monitoring and rate limiting, that had to be solved once for a monolith, now have to be handled separately for each service. 

Service mesh helps address many of these challenges so engineering teams – and businesses – can deliver applications more quickly and securely. Aspen Mesh adds observability, security and policy capabilities to Kubernetes. The resulting resiliency and uptime enables engineering teams to more effectively monitor, control and secure the modern application at runtime. And because the service mesh is a common layer, these tools are available at each microservice, providing the modern enterprise with a toolbox of features to address their challenges. 


Helping with your digital transformation

There are about a gazillion things to think about as companies embrace digital transformation by migrating from legacy or monolithic systems to microservices. Starting with, well, microservices. It’s easy to understand why microservice-based applications are becoming more and more common. Through microservice architectures, enterprises are seeing: 

  • Improved scalability 
  • Increased development velocity 
  • Easier debugging 
  • Rapid alignment between development and user requirements 

As companies build or migrate to more modern applications, they’re leveraging microservices to drive differentiation and market leadership. As a side effect, they realize that they are increasing complexity and decentralizing ownership and control. These new challenges require new solutions to effectively monitor, manage and control microservice-based applications at runtime. 

Keep in mind that Kubernetes has become the defacto method for enterprises to orchestrate containers. Kubernetes is a superb tool when it comes to deploying, scheduling and running containerized applications through a basic approach to networking that doesn’t provide rich service-to-service communication. 

That’s where service mesh comes in. 

A service mesh like Aspen Mesh adds observability, security and policy capabilities to Kubernetes. A service mesh helps to ensure resiliency and uptime – it provides solutions that enable engineering teams to more effectively monitor, control and secure the modern application at runtime. 

Companies are adopting service mesh as a way to enhance Kubernetes, as it provides a toolbox of features that address various microservices challenges that modern enterprises are facing. 


Choose your own adventure

When to use a service mesh depends on a lot of variables, including your role. While we know the decision to move to service mesh is rarely made in a silo, we thought we’d give you an opportunity to get the info you need – while helping others get the info they need – so you can all align on if and how service mesh can be the next game changer for your business. 

The next sections of content will be respectively targeted at Dev, Ops, and App Owner teams and individuals. 


For Dev

Welcome, Developers!

So, you want to know when you should use a service mesh? The best answer is of course, “it depends,” so we’ll do our best to help you think through the nuances that might be helpful given your unique situation.  

Want a shortcut? Reach out to our experts for 1:1 info tailored to your company. 

Integrating a service mesh into your current stack It’s time to start thinking about how a service mesh integrates with – and enhances – your current tech stack.

Let’s get started!

The service mesh landscape

service mesh graphic

Let’s start here. A service mesh overlaps, complements, and in some cases, replaces many tools that are commonly used to manage microservices. Many technologies are involved in the service mesh landscape. Here’s a view of how service mesh fits with other commonly used container tools. 

  1. API Gateway – Internal Routing, Billing
    Routes requests to the appropriate service or services to enable functionality such as billing.
    Examples: Kong, Apigee
  2. Global ADC – Global Load Balancing
    Efficiently distributes network traffic across multiple services.
    Examples: BIG-IP, NGINX
  3. Service Mesh – Configuration, Policy
    Allows you to dictate the way a system operates, and responds when something happens.
    Examples: Istio, Linkerd
  4. Ingress, Egress
    Allows you to monitor and control traffic entering and exiting Kubernetes clusters.
  5. TLS – Client and Server Side Verification
    Establishes mTLS to add end-to-end security to Kubernetes clusters.
  6. Service Proxy – Service Discovery, Health Checking
    Enables the finding of new pods and services, and surfaces the health status of services.
    Example: Envoy
  7. Credential Management – Authentication, Authorization
    Establishes identities which are at the core of RBAC and building a zero-trust network.
  8. APM – Logging, Metrics, Tracing
    Allows engineers to easily monitor and debug distributed systems.
    Examples: Datadog, Jaeger 

What are your specific needs?

Start by looking at which applications you are currently using that need to play nicely with a service mesh. In order to integrate a service mesh into your existing tech stack, you’ll need to take a close look at:

  • Which technologies you’re currently using for microservices and Kubernetes management
  • Which service mesh you’re thinking of adding into the mix – and what the requirements and tech are around that specific service mesh
  • What you’d like to get out of your service mesh so you can choose one that provides the features and functionalities that you need

Once you have these answers, talk to a service mesh expert to map out exactly how your unique service mesh implementation is going to work. They’ll also help you understand which, if any, technologies or processes you need to consider updating or changing before or after implementation in order to get the most out of your service mesh.

Understanding service mesh features and how to tell which you need

The service mesh toolbox provides a bunch of features that can address different microservices challenges, but enterprises have additional requirements in order to address policy, configuration, and a uniform view across large distributed teams. A service mesh becomes super helpful for enterprises as it adds observability, security and reliability to your Kubernetes cluster. Much of the capabilities provided by service mesh are achievable with other tools, but they are all more manual and lack uniformity. You should prefer a service mesh over a patchwork approach because a service mesh can provide these features consistently across all microservices. This consistency is crucial if you ever want to centralize responsibility (also known as “get it off my plate”) – it’s difficult to centralize a patchwork of inconsistent libraries.

  • Observability – If you have a service mesh, then you need to be able to easily see what’s going on in your cluster(s) in order to be successful. Observability is a requirement for anyone using a service mesh.
  • Security – We’re all concerned about security and a service mesh adds critical microservice security features. From incremental mTLS per service or namespace to fine-grained RBAC with secure default settings, end-to-end encryption and ingress/egress control, service mesh makes it easy to get to a zero-trust network.
  • Reliability – Service mesh features like dynamic request routing, fast retries, configuration vetters, circuit breaking and load balancing greatly increase the resiliency of microservice architectures. Support is also a feature that some enterprises will want to consider in light of whether service mesh expertise is a core in-house skill for the business. Having access to an expert support team can make a tremendous difference in your reliability and your end users’ experience.

Reasons you need these features

Even if these security features are not yet requirements for your company, they will be soon. Take advantage of these security features sooner rather than later and get ahead of the game.

Identify and mitigate risks

Because of the way microservices architectures are designed, there is increased surface area that can be attacked. A service mesh can help you identify those areas and mitigate any risks ahead of time.

Security and compliance

You can also think about this this way: What kind of company do you work for? Are you focused on security and compliance? Are you with an enterprise company or in an industry where you handle sensitive data? If yes to any of those, these security features are designed for you. Incremental mTLS allows you to control exactly what’s encrypted in your cluster at the service or namespace level, plus status at-a-glance can help you easily understand the security posture of every service in your cluster. And fine-grained RBAC lets you enforce the principle of least privilege to ensure your organization does not create a security concern.

Day-to-day differences a service mesh makes

How things work together with a service mesh

A service mesh should save you time and effort. Take a look at the chart to get ideas about how to measure success in a shareable, meaningful way. What takes the most time or effort? Has the highest/lowest success rates? Is the most complex? Could be automated? Isn’t your area of expertise?

Record how long it takes to do tasks without a service mesh, then check in again once your service mesh is up and running and take a look at what has changed.

Awesome benefits for you once your service mesh is up and running

  • Less time kicking bugs back and forth between teams because problems are rapidly root caused
  • Fewer outages when resilience converts catastrophic failures into graceful degradation
  • More time spent on doing what you’re best at – adding real value for your end users and your company (like adding that epic new feature you’ve been talking about but haven’t had time to develop)
  • An easier job – delegate crypto, authentication and other dev chores to experts that can give them the attention they deserve
  • Do a better job – a service mesh lets you connect, secure, control and observe your services from an easy to use UI
  • Fame, fortune, and glory? (At least, that’s the idea!)

Awesome benefits for your company once your service mesh is up and running

  • Better security and compliance
  • Increased business value
  • Improved scalability
  • Increased development velocity
  • Better alignment between development and user requirements
  • Better end user/customer experience

Measuring service mesh success

A service mesh should save you time and effort. Take a look at the chart to get ideas about how to measure success in a shareable, meaningful way. Approach this by thinking about what it is that takes the most time or effort, has the highest/lowest success rates, is the most complex, what could be automated, or what you’re not a specialist at. Record how long it takes to do tasks without a service mesh, then check in again once your service mesh is up and running and take a look at what has changed.

Ideas for what to measure Before service mesh With service mesh running
How much time do you spend figuring out which microservice is causing an issue? Lots – it can be a hassle to pinpoint which service is causing the problem and even harder to pinpoint why Much less time – metrics and tracing make it much easier to root cause problems
How successful are deployments to production? Successful most of the time, but a lot goes into them, and we struggle to limit the blast radius when things go awry Much more consistent now that we can use canary deploys to test experimental services before rolling them out to all users
How much effort does it take to manage SLOs for your microservice architecture? It’s very difficult to understand service availability and how that’s affecting end users Metrics generated by service mesh make it easy to understand service health and status

For Ops

Welcome, Ops!

So, you’re looking to understand when you should use a service mesh. The best answer is, of course, “it depends,” but allow us to be your guide as we figure this out together.

The best way to find out if it’s the right time for you is actually to reach out to our experts for 1:1 info tailored to your company. But if you’re not ready for that yet, we get it. Here’s some information to help you determine if service mesh makes sense for your company’s digital transformation.

Service mesh for DevOps

As you know, DevOps is a term used to describe the business relationship between development and IT operations. Mostly, people use the term when they’re talking about improving communication and collaboration between the two teams. But while Dev is responsible for creating new functionality to drive business, Ops is often the unsung – but extremely important – hero behind the scenes. In IT Ops, you’re on the hook for strategy development, system design and performance, quality control, direction and coordination of your team all while collaborating with the Dev team and other internal stakeholders to achieve your business’s goals and drive profitability. That means it’s your responsibility to ensure teams are communicating effectively, systems are monitored correctly, high customer satisfaction is achieved and projects and issue resolution are completed on time. Sound familiar? That’s a lot. But a service mesh can help you.

Your company's digital transformation

It’s happening everywhere, and it’s happening fast. We’ve seen many companies embrace digital transformation over the past few years. Netflix, Home Depot, Porsche, Amazon…

In order to meet consumers head on in the best, most secure ways, enterprises are jumping on the digital transformation train (check out this Forrester report). Here’s the big thing to understand: digital transformation is more of a culture change than a one-off project.

Want some examples? Okay – how about, using computers instead of typewriters? Or email instead of letters? There’s also ATMs instead of checks. First Netflix replaced Blockbuster, then they disrupted the way you build cloud apps with approaches like Chaos Testing, the list goes on. And service mesh is another great example of this.

Several years ago, digital transformation saw companies moving from monoliths towards microservices and Kubernetes, but service mesh was in its infancy. No one knew they’d need something to manage service-to-service communication when they’re just getting started standing up their first service. Now, with increasing complexity and demands coupled with resources stretched thin or teams without service mesh expertise, supported service mesh is becoming a good solution for many. And it’s time to consider it for your company!

The good news? Service mesh is for Dev AND for Ops. You know: DevOps.

Approaching the process of integrating a service mesh

Aligning with business objectives

As you think about adopting a service mesh, keep in mind that your success over time is largely dependent on aligning with your company’s business objectives. Sharing business objectives like these with your team will help to ensure you get–and keep–the features and capabilities that you really need, when you need them, and that they stay relevant.

What are your company’s business objectives? Here are three common business objectives a service mesh can address:

  • Automating more process – (i.e. removing toil) Automating processes frees up your team from mundane tasks so they can focus on more important projects. Automation can save you time and money.
  • Increasing infrastructure performance – Building and maintaining a battle-tested environment is key to your end users’ experience, and therefore churn or customer retention rates and your company’s bottom line. In addition, much of your time is spent developing strategies to monitor your systems and working through issue resolution as quickly as possible – whether issues pop up during the workday, or in the middle of the night. Fortunately, because service mesh comes with observability, security, and resilience features, it can help alleviate these responsibilities, decreasing MTTD and MTTR.
  • Delivering customer value more quickly – Reducing friction in the user experience is the name of the game these days, so UX and reliability are key to keeping your end users happy. If you’re looking at a service mesh, you’re already using a microservices architecture, and you’re likely using Kubernetes clusters. But once those become too complex in production – or don’t have all the features you need – it’s time to add a service mesh into the mix. Service mesh’s observability features like cluster health monitoring, service traffic monitoring, easy debugging and root cause identification with distributed tracing help with this. In addition, an intuitive UI is key to surfacing these features in a way that is easy to understand and manipulate, so make sure you’re looking at a service mesh that’s easy for your Dev team to use. This will help provide a more seamless (and secure) experience for your end users.

Evolution; not revolution

So, how do you actually go about approaching the process of integrating a service mesh? What will drive success is agility and stability. But that can be a tall order, so it can be helpful to approach integrating a service mesh as evolution, rather than revolution.

Three key areas to consider while you’re evaluating a service mesh:

  • Mitigating risk – Risk can be terrifying, so it’s imperative to take steps to ensure that risk is mitigated as much as possible. The only time your company should be making headlines is because of good news. So how do you make that a reality? Being secure and compliant and ensuring data integrity is the way to go – and it’s key to your company’s success. With security and compliance at top of mind for many, it’s important to address security head on. And you guessed it; a service mesh can help. With a well-designed enterprise service mesh, you can expect a plethora of security, compliance and security features so it’s easy for your company to get a zero-trust network. Features can include anything from ensuring the principle of least privilege and secure default settings to technical features such as fine-grained RBAC and incremental mTLS.
  • Policy frameworks – While configuration is useful for setting up how a system operates, policy is useful in dictating how a system responds when something happens. With a service mesh, the power of policy and configuration combined provides capabilities that can drive outcome-based behavior from your applications. A policy catalog can accelerate this behavior, while analytics examines policy violations and understands the best actions to take. This improves developer productivity with canary, authorization, secure ingress and service isolation policies.
  • Production readiness – Your applications are ready to be used by your end users, and your technology stack needs to be ready too. What makes a big impact here is reliability. Service mesh features like dynamic request routing, fast retries, configuration vetters, circuit breaking and load balancing greatly increase the resiliency of microservice architectures. Support is also a. feature that some enterprises will want to consider in light of whether service mesh expertise is a core in-house skill for the business. Having access to an expert support team can make a tremendous difference in your production readiness and your end users’ experience.

Still have questions about this?

Here are some helpful FAQs:

Do I have to change my applications to use a service mesh?

In most situations, you don’t need to change your applications to get the benefits of service mesh. However, there are a few scenarios in which you might need to change your applications when using a service mesh. For example, with Istio in order to enable mTLS between all the services in your cluster, you need to offload encryption responsibility to the sidecar. Distributed tracing requires propagating correlation headers; this is required for all distributed tracing service mesh or not (and some app frameworks do it for you).

Can I integrate a service mesh with my current stack?

Many service mesh providers can help you effectively integrate with any legacy applications. Every stack is different, but we’ve integrated Istio with all kinds of different application architectures, from cloud-provided authenticators to legacy bare metal databases.

Where does a service mesh fit into my organization?

If you have a platform team, it makes the most sense for them to own your service mesh. However, with many teams shifting from traditional to dev only teams, it makes sense for you to have a conversation about this with your stakeholders in order to find the best solution. The maximum benefit from service mesh comes when all the microservices are using it consistently, like other platform aspects. Of course, we’re here to help you work through questions like this as well, so feel free to reach out with any concerns about getting the most out of your service mesh – for your team and your end users.

If you want to know how to make service mesh work with your application specifics, schedule some time with an Aspen Mesh expert.

Service mesh success measurements

No plan is complete without a way to measure, iterate and improve your success over time. How do you go about measuring the success of your service mesh? There are a lot of factors to take into consideration, so it’s a good idea to talk to your service mesh provider in order to leverage their expertise. But in the meantime, we’ve put together a few things that you can think about watching in order to get a sense of how well your service mesh is working for you.

Take a look at the example table to get an idea:

  Questions to ask State before service mesh State with service mesh
Security & Compliance Is our cluster secure by default? No – we must enable secure settings Yes – service mesh provides automatic mTLS
Can we enforce principle of least privilege? We have a strategy – but it’s managed manually Service mesh RBAC capability make this easy to manage
How do we meet security and compliance requirements? With a lot of one-off dev work – don’t make me think about the work involved if we ever get audited Service mesh provides complete audit logs, fine-grained RBAC and mTLS to help us easily enforce
Reducing Downtime How is east/west traffic managed? Haphazardly In a repeatable fashion that provides encryption and observability
Do we have dynamic request routing? No Yes
How’s our load balancing? Basic L4 balancing works well Even better – we automatically eject poor performers even if Kubernetes thinks they are healthy
Increasing Efficiency How much time is spent responding to compliance audits? Weeks (maybe months depending on complexity of audit) Hours
How do we manage polyglot challenges? We try to standardize on languages and frameworks, but devs aren’t a huge fan of that Service mesh provides uniformity so it no longer matters what languages or frameworks we use to develop microservices

For App Owners

Greetings, App Owners – we’re glad that you’re here!

So, you’re wondering how service mesh can benefit your applications? We’re guessing you’ve heard all the buzz about “service mesh” and are wondering if it’s something that would be worthwhile for your company. We can help with that! Keep reading for more info regarding business outcomes, how to better manage your microservices and measurements of success to think about when you’re considering or using service mesh.

To start, here are five key considerations for someone in your role who’s evaluating service mesh:

  1. Consider how a service mesh supports your organization’s strategic vision and objectives
  2. Have someone in your organization take inventory of your technical requirements and your current systems
  3. Identify resources needed (internal or external) for implementation – all the way through to running your service mesh
  4. Consider how timing, cost and expertise will impact the success of your service mesh implementation
  5. Design a plan to implement, run, measure and improve over time

If you’d like additional support in thinking through any of these pieces, we can help with that.

What do you get out of a service mesh?

What do you want out of a service mesh? Since you’re reading this, there’s a good chance you’re responsible for making sure that your end users get the most out of your applications. That’s probably why you started down the microservices path in the first place.

If that’s true, then you’ve probably realized that microservices come with their own unique challenges, such as:

  • Increased surface area that can be attacked
  • Polyglot challenges
  • Controlling access for distributed teams developing towards a single application

That’s where a service mesh comes in. Service meshes are great at solving operational challenges and issues when running containers and microservices because they provide a uniform way to secure, connect and monitor microservices.

TLDR; a good service mesh keeps your company’s services running they way they should, giving you observability, security and traffic management capabilities you need to effectively manage and control containerized applications so you can focus on adding the most value to your business.

Business outcomes you can expect from a service mesh

Ultimately, you’re on the hook for business outcomes at your company. So, consider your strategies. What do you plan to accomplish, and how do you intend to make those accomplishments become a reality?

Whatever your answers may be, a service mesh is worth investigating, as it has the potential to help you get from where you are to where you want to be – more securely, and faster. But apart from just reaching your goals faster and more securely, a service mesh can offer a lot of additional benefits:

Decreasing risk

Risk analysis. Security. Compliance. These topics are priority one, if you want to stay out of the news. But there is good news – service mesh can help to provide your company with better – and provable – security and compliance.

Everyone’s asking a good question: What does it take to achieve security in cloud native environments?

We know that there are a lot of benefits in cloud-native architectures: greater scalability, resiliency and separation of concers. But new patterns also bring new challenges like ephemerality and new security threats.

With an enterprise service mesh, you get access to observability into security status, end-to-end encryption, compliance features and more. Here are a few security features you can expect from a service mesh:

  • mTLS status at-a-glance: Easily understand the security posture of every service in your cluster
  • Incremental mTLS: Control exactly what’s encrypted in your cluster at the service or namespace level
  • Fine-grained RBAC: Enforce the level of least privilege to ensure your organization does not create a security concern
  • Egress control: Understand and control exactly what your services are talking to outside your clusters

Optimizing Cost

Every business needs cost optimizations. But how do you choose which are going to make an impact and which aren’t? Which are most important? Which are you going to use?

As you know, one aspect to consider is talent. Your business does better when your people are working on new features and functionality rather than spending too much of their time on bug fixes. Applications, like service mesh, can help boost your development team’s productivity, allowing them to spend more time working on new business value adds and differentiators rather than bug fixes and maintenance.

But internal resources aren’t the only thing to consider. Without end-users, your company wouldn’t exist. And it’s becoming increasingly important to provide a better user experience for both your stakeholders as well as your customers.

Service mesh provides help to applications running on microservice architectures rather than monolithic architectures. Microservices natively make it easier to build and maintain applications, greater agility, faster time to market and more uptime.

A service mesh can help you get the ideal mix of these cost savings and uptime.

Driving better application behavior

What happens when a new application wants to be exposed to the internet? Well, you need to consider how to secure it, how to integrate it into your existing user-facing APIs, how you’ll upgrade it, and a host of other concerns. You’re embracing microservices, so you might be doing this thing a lot. You want to drive better application behavior. Our advice here? You should use a service mesh policy framework to do this consistently, organization-wide.

Policy is simply a term for describing the way a system responds when something happens. A service mesh can help you improve your company’s policies by allowing you to:

  • Provide a clean interface specification between application teams who make new functionality and the platform operators who make it impactful to your users
  • Make disparate microservices act as a resilient system through controlling how services communicate with each other and external systems and managing it through a single control plane
  • Allow engineers to easily implement policies that can be mapped to application behavior outcomes, making it easy to ensure great end user experience

An enterprise service mesh like Aspen Mesh enables each subject-matter expert in your organization to specify policies that enable you to get the intended behavior out of your applications and easily understand what that behavior will be. You can specify, from a business objective level, how you want your application to respond when something happens and use your service mesh to implement that.

Implementing Progressive delivery

Continuous delivery has been a driving force behind software development, testing and deployment for years, and CI/CD best-practices are evolving with the advent of new technologies like Kubernetes and Istio. Progressive delivery, a term coined by James Governor, is a new approach to continuous delivery that includes “a new basket of skills and technologies… such as canarying, feature flags, [and] A/B testing at scale”.

Progressive delivery decouples LOB and IT by allowing the business to say when it’s acceptable for new code to hit the customer. This means that the business can put guardrails around the customer experience through decoupling dev cycles and service activation.

With progressive delivery:

  • Deployment is not the same as release
  • Service activation is not the same as deployment
  • The developer can deploy a service, you can ship the service, but that doesn’t mean you’re activating it for all users

Progressive delivery provides a better developer experience and also allows you to limit the blast radius of new deployments with feature flags, canary deploys and traffic monitoring.

Gaining a competitive advantage

In order to stay ahead of your competition, you need an edge.

You don’t have to be Google to benefit from microservices or a service mesh. Enterprise companies evaluating or using a service mesh come in lots of different flavors – those who are just starting, going through or those who have completed a digital transformation, companies shifting from monoliths to microservices, and even organizations using microservices who are working to identify areas for improvement.

If you’re using containers and having problems like the ones you’ve read about in the above sections, you should consider a service mesh. Many of your competitors are, and there’s no reason to be left behind.

Service mesh success measurements

How do you plan to measure success with your service mesh? Since service mesh is new and evolving, it can be difficult to know what to look for in order to get a real pulse on how well it’s working for your company.

Here are some example questions to ask:

Saving resources Your users’ experience Increasing efficiency
Is your team is more efficient with a service mesh? How much more time are they able to spend on feature and function developments rather than bug fixes and maintenance? Do you have a complete picture of your customers’ experience and know the most valuable places to improve? How much more successful are deployments to production? How much time do you spend figuring out which microservice is causing an issue? Does your service mesh save you time here?

When service mesh is a win/win/win

Service mesh is an application that can help entire organizations work together for better outcomes. In other words, service mesh is the ultimate DevOps enabler.

  • Observability – Take system monitoring a step further by providing observability. Monitoring reports overall system health, while observability focuses on highly granular insights into the behavior of systems along with rich context
  • Security and Decreased Risk – Better secure the services inside your network and quickly identify any compromising traffic entering your clusters
  • Operational Control – Allow security and platform teams to set the right macro controls to enforce access controls, while allowing developers to make customizations they need to move quickly within defined guardrails
  • Increased Efficiency with a Developer Toolbox – Remove the burden of managing infrastructure from the developer and provide developer-friendly features such as distributed tracing and easy canary deploys

What’s the secret to getting the most out of your service mesh?

  1. Align on service mesh goals with your teams
  2. Choose the service mesh that can be broadly deployed to address your company’s needs
  3. Measure your service mesh success over time in order to identify and make improvements

Conclusion and Contact Info

Because running a service mesh is a process that typically spans roles across the organization, we hope this information serves you and your team well as each of you consider different aspects of this decision.

As you continue along your journey, we’d love to support you. Have more questions? Want to try before you buy? Looking for even more ways to get more out of your service mesh? You got it.

Visit our website to learn more, or give us a shout.

We’d love to hear from you!