What Are Companies Using Service Mesh For?

We recently worked with 451 Research to identify current trends in the service mesh space. Together, we identified some key service mesh trends and patterns around how companies are adopting service mesh, and emerging use cases that are driving that adoption. Factors driving adoption include how service mesh automates and bolsters security, and a recognition of service mesh observability capabilities to ease debugging and decrease Mean Time To Resolution (MTTR). Check out this video for more from 451 Research's Senior Analyst in Application and Infrastructure Performance, Nancy Gohring, on this topic:

Who’s Using Service Mesh 

According to data and insights gathered by 451 Research, service mesh already has significant momentum, even though it is a young technology. Results from the Voice of the Enterprise: DevOps, Workloads & Key Projects 2020 survey tell us that 16% of respondents had adopted service mesh across their entire IT organizations, and 20% had adopted service mesh at the team level. Outside of those numbers, 38% of respondents also reported that they are in trials or planning to use service mesh in the future. As Kubernetes dominates the microservices landscape, the need for a service mesh to manage layer 7 communication is becoming increasingly clear. 

451 Research Service Mesh Adoption

In tandem with this growing adoption trend, the technology itself is expanding quickly. While the top driver of service mesh adoption continues to be supporting traffic management, service mesh provides many additional capabilities beyond controlling traffic. 451 found that key new capabilities the technology provides includes greatly enhanced security as well as increased observability into microservices.

Service Mesh and Security

Many organizations—particularly those in highly regulated industries such as healthcare and financial services—need to comply with very demanding security and regulatory requirements. A service mesh can be used to enforce or enhance important security and compliance policies more consistently, and across teams, at an organization-wide level. A service mesh can be used to:

  • Apply security policies to all traffic at ingress, and encrypt traffic using mTLS traveling between services
  • Add Zero-Trust networking
  • Govern certificate management for authenticating identity
  • Enforce level of least privilege with role-based access control (RBAC)
  • Manage policies consistently, regardless of protocols and runtimes 

These capabilities are particularly important for complex microservices deployments, and allow DevOps teams to ensure a strong security posture while running in production at global scale. 

Observability and Turning Your Data into Intelligence

In addition to helping enterprises improve their security posture, a service mesh also greatly improves observability through traces and metrics that allow operators to quickly root cause any failures and ensure resilient applications. Enabling the rapid resolution of performance problems allows DevOps teams to reduce mean time to resolution (MTTR) and optimize engineering efficiency

The broader market trends around observability and advanced analytics with open source technologies are also key to the success of companies adopting service mesh. There are challenges around managing microservices environments, and teams need better ways of identifying the sources of performance issues in order to resolve problems faster and more efficiently. Complex microservices-based applications generate very large amounts of data. Many open source projects are addressing this by making it easier for users to collect data from these environments, and advancements in analytics tools are enabling users to extract the signal from the noise, quickly directing users to the source of performance problems. 

Overcoming this challenge is why we created Aspen Mesh Rapid Resolve. It allows users to see any configuration or policy changes made within Kubernetes clusters, which is almost always the cause of failures. The Rapid Resolve timeline view makes it simple for operators to look back in time to pinpoint any changes that resulted in performance degradation. 

Aspen Mesh Rapid Resolve

This enables Aspen Mesh users to identify root causes, report actions and apply fixing configurations all in one place. For example, the Rapid Resolve suite offers many new features including:

  • Restore: a smarter, machine-assisted way to effectively reduce the set of things an operator or developer has to look through to find the root cause of failure in their environment. Root causing in distributed architectures is hard. Aspen Mesh Restore immediately alerts engineers to any performance outside acceptable thresholds and makes it obvious where any configuration, application or infrastructure changes occurred that are likely to be breaking changes.
  • Replay: a one-stop shop for application troubleshooting and reducing time to recovery. Aspen Mesh Replay gives you the current and the past view of your cluster state, including microservices connectivity, traffic and service health, and relevant events like configuration changes and alerts along the way. This view is great for understanding and diagnosing cascading failures. You can easily roll back in time and detect where a failure started. It's also a good tool for sharing information in larger groups where you can track the health of your cluster visually over time.

The Future of Service Mesh

Companies strive for stability with agility, which allows them to meet the market and users where they are, and thrive even in an uncertain marketplace. According to 451 Research,

“Businesses are employing containers, Kubernetes and microservices as tools that allow them to more quickly respond to customer demands and competitive threats. However, these technologies introduce new and potentially significant management challenges. Advanced organizations have turned to service mesh to help solve some of these problems. Service mesh technology can remove infrastructure burdens from developers, enabling them to focus on creating valuable application features rather than managing the mechanics of microservices communications. But managing the communications layer isn’t the only benefit a service mesh brings to the table. Increasingly, users are recognizing the role service meshes can play in collecting and analyzing important observability data, as well as their ability to support security requirements.”

The adoption of containers, Kubernetes and service mesh is continuing to grow, and both security and observability will be key drivers that increase service mesh adoption in the coming years.

 


Aspen Mesh 1.6 Service Mesh

Announcing Aspen Mesh 1.6

We’re excited to announce the release of Aspen Mesh 1.6 which is based on Istio’s release 1.6 (specific tag 1.6.5). As a release manager for Istio 1.6, I’ve been eager for Aspen Mesh’s adoption of 1.6 as Istio continues its trend of adding many enhancements and improvements. Our commitment and relationship with the Istio community continues to flourish as our co-founder and Chief Architect Neeraj Poddar was recently appointed to the Technical Oversight Committee and I joined the Product Security Working Group, a group tasked with handling sensitive security issues within Istio. With our team members joining these groups, you can be assured that your best interests are represented as we continue to develop Aspen Mesh.

As with every new major release, we’re excited to detail the new features and capabilities offered by Istio, and also new features available within Aspen Mesh. 

Hare are some key items to note for this new release:

Helm Based Installs

At Aspen Mesh, we encourage users to adopt the GitOps workflow using Helm. Istio is moving towards CLI tool based install using istioctl and the Istio Operator for installations and upgrades. While the chart structure located in the manifests/ directory shipped in Istio works with Helm, we’ve spent considerable effort in streamlining the charts to make them ready for the enterprise to ensure continuity.

However, upgrading to 1.6 will be drastic due to the structural changes made to the charts in Istio. Given the efforts we are putting into Istio, as well as the burden this places on users, our intent is to streamline this before the release of Aspen Mesh 1.7 to ease the upgrade process moving forward.

Istiod Monolith

With the change to Helm charts, users will be able to leverage Istiod and Telemetry v2. Istiod is the consolidated Istio controlplane, delivered as a monolithic deployment (with the exception of Mixer). There are two key reasons we are eager to support this consolidated deployment:

  1. It significantly reduces the memory and CPU footprint of the service mesh, resulting in lower operating costs.
  2. The simplified deployment model makes it easier for operators to debug production issues when the need arises. It’s no longer necessary to look at the logs of different services to determine the root cause of a problem, but rather just your Istiod pods.

Telemetry v2

As of Aspen Mesh 1.6, we only support Telemetry v2, also known as Mixerless telemetry. While Telemetry v2 does not have parity with Mixer, the benefits of Telemetry v2 now far outweigh the features no longer in Mixer. Don’t be alarmed as the Istio community is diligently working on having Telemetry v2 reach parity with Mixer.

Many of our users have reported Mixer related performance issues, such as high CPU load, high memory usage and even latency issues. These issues should be solved with the move towards Envoy-based filters, such as the WASM filter used by Telemetry v2. In-band and in-application, high performance C++ code should better meet the needs of large enterprises with hundreds of nodes and thousands of pods.

SDS: The Default Behavior Across Your Service Mesh

In Aspen Mesh 1.5, Secret Discovery Service (SDS) was not enabled by default for sidecar proxies across your cluster. With the Aspen Mesh 1.6 release, both gateways and workloads support SDS, allowing for better service mesh security as well as performance improvements.

For reference, beginning with Aspen Mesh 1.6, an executable istio-agent lives alongside Envoy sidecar proxy and safely shares certificates issued to it by Istiod with Envoy. This is a change from Aspen Mesh, where 1.5 Kubernetes Secrets were created by Citadel, presenting risks if the Kubernetes cluster wasn’t properly secured. One of the top benefits of SDS is that it allows Envoy to be hot-restarted when certificates are set to expire and need to be rotated.

Next Steps for You

Aspen Mesh 1.6 is available for download here. You can look at the complete list of changes in this release by visiting our release notes. If you have any questions about your upgrade path, feel free to reach out to us at support@aspenmesh.io.

If you’re new to Aspen Mesh, you can download a free 30-day trial


What is a service mesh Aspen Mesh

What’s a Service Mesh?

What is a service mesh? It’s an infrastructure layer that helps you manage the communication between your microservices.

What is a service mesh

Designed to handle a high volume of service-to-service communications using APIs, a service mesh ensures that communication among your containerized application services is fast, reliable and secure. 

A service mesh helps address many of the challenges that arise when your application is being consumed by your end users. The ability to monitor what services are communicating with each other, knowing if those communications are secure, and being able to control the service-to-service communication in your clusters is key to ensuring your applications are running securely and resiliently. You can think about service mesh as being the lexicon, API and implementation around the next tier of communication patterns for microservices.

Service Mesh Capabilities and Patterns

Some of the capabilities that a service mesh provides include service discovery, load balancing, encryption, observability, traceability, authentication and authorization, and the ability to control policy and configuration in your Kubernetes clusters. 

A service mesh sits at Layer 7, managing and securing traffic between your network and application, unlocking some patterns essential for healthy microservices. Some of these patterns include:

  • Zero-trust security that doesn’t assume a trusted perimeter
  • Tracing that shows you how and why every microservice communicated with another microservice
  • Fault injection and tolerance that lets you experimentally verify the resilience of your application
  • Advanced routing that lets you do things like A/B testing, rapid versioning and deployment and request shadowing

Check out these FAQs for answers to more general questions.

 

What Does a Service Mesh Provide?

A service mesh keeps your company’s services running the way they should. Service meshes designed for the enterprise, like Aspen Mesh, gives you all the observability, security and traffic management you need — plus access to configuration and policy patterns and expert support, so you can focus on adding the most value to your business.

A service mesh can provide many benefits: Security, reliability, observability, engineering efficiency/reduced burden, more holistic insights, operational control, and better tools for your DevOps team. The four main benefits that a service mesh provides include:

  1. Observability: A service mesh takes 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. 
  2. Security: A service mesh provides security features aimed at securing the services inside your network and quickly identifying any compromising traffic entering your cluster. 
  3. Operational control: A service mesh allows 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 these guardrails.
  4. A better user experience: A service mesh removes the burden of managing infrastructure from the developer, and provides developer-friendly features. But on top of that, the security and reliability that you get from a service mesh creates a smoother, better experience for your end users while they're using your systems or application. Building trust with your customers is invaluable.

Service mesh is new enough that codified standards have yet to emerge, but there is enough experience that some best practices are becoming clear. As early adopters develop their own approaches, it is often useful to compare notes and distill best practices. We’ve seen Kubernetes emerge as the standard way to run containers for production web applications. Standards are emergent rather than forced: It’s definitely a fine art to be neither too early nor too late to agree on common APIs, protocols and concepts.

 

When Do You Need a Service Mesh?

A service mesh provides a great way to help you manage microservices. But how do you know when it's the right time to adopt one? The answer is that it depends on your needs, but many companies we've worked with start needing a service mesh when they run into one or a combination of three things:

  1. You’re starting to run too many microservices for you to effectively manage based on team size or skills
  2. You want to free up application developers from managing infrastructure so they can spend more time adding business value to applications
  3. Your’e scaling or committed to scaling applications on Kubernetes

So how do you make sure that you and your end users get the most out of your applications and services? You need to have the right kind of access, security and support. 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 on a single application 

These are all scenarios where a service mesh shines. Service meshes are great at solving operational challenges and issues when running containers and microservices because they provide a uniform and highly observable way to secure, connect and monitor microservices. 

On a broader tech landscape level, we’ve been thinking about how microservices change the requirements from network infrastructure for a few years now. The swell of support and uptake for Istio demonstrated to us that there’s a community ready to develop and coalesce on policy specs, with a well-architected implementation to go along with it.

Thanks for reading! Check out Service Mesh University to learn more about service mesh at your own pace through an on-demand, video series.


Helping Istio Sail

Around three years ago, we recognized the power of service mesh as a technology pattern to help organizations manage the next generation of software delivery challenges, and that led to us founding Aspen Mesh. And we know that efficiently managing high-scale Kubernetes applications requires the power of Istio. Having been a part of the Istio project since 0.2, we have seen countless users and customers benefit from the observability, security and traffic management capabilities that a service mesh like Istio provides. 

Our engineering team has worked closely with the Istio community over the past three years to help drive the stability and add new features that make Istio increasingly easy for users to adopt. We believe in the value that open source software — and an open community  —  brings to the enterprise service mesh space, and we are driven to help lead that effort through setting sound technical direction. By contributing expertise, code and design ideas like Virtual Service delegation and enforcing RBAC policies for Istio resources, we have focused much of our work on making Istio more enterprise-ready. One of these contributions includes Istio Vet, which was created and open sourced in early days of Aspen Mesh as a way to enhance Istio's user experience and multi resource configuration validation. Istio Vet proved to be very valuable to users, so we decided to work closely with the Istio community to create istioctl analyze in order to add key configuration analysis capabilities to Istio. It’s very exciting to see that many of these ideas have now been implemented in the community and part of the available feature set for broader consumption. 

As the Istio project and its users mature, there is a greater need for open communication around product security and CVEs. Recognizing this, we were fortunate to be able to help create the early disclosure process and lead the product security working group which ensures the overall project is secure and not vulnerable to known exploits. 

We believe that an open source community thrives when users and vendors are considered as equal partners. We feel privileged that we have been able to provide feedback from our customers that has helped accelerate Istio’s evolution. In addition, it has been a privilege to share our networking expertise from our F5’s heritage with the Istio project as maintainers and leads of important functional areas and key working groups.

The technical leadership of Istio is a meritocracy and we are honored that our sustained efforts have been recognized with - my appointment to the Technical Oversight Committee

As a TOC member, I am excited to work with other Istio community leaders to focus the roadmap on solving customer problems while keeping our user experience top of mind. The next, most critical challenges to solve are day two problems and beyond where we need to ensure smoother  upgrades, enhanced security and scalability of the system. We envision use cases emerging from industries like Telco and FinServ which will  push the envelope of technical capabilities beyond what many can imagine.

It has been amazing to see the user growth and the maturity of the Istio project over the last three years. We firmly believe that a more diverse leadership and an open governance in Istio will further help to advance the project and increase participation from developers across the globe.

The fun is just getting started and I am honored to be an integral part of Istio’s journey! 


How to Achieve Engineering Efficiency with a Service Mesh

How to Achieve Engineering Efficiency with a Service Mesh

As the idea for Aspen Mesh was formulating in my mind, I had the opportunity to meet with a cable provider’s engineering and operations teams to discuss the challenges they had operating their microservice architecture. When we all gathered in the large, very corporate conference room and exchanged the normal introductions, I could see that something just wasn’t right with the folks in the room. They looked like they had been hit by a truck. The reason for that is what turned this meeting into one of the most influential meetings of my life.

It turned out that the entire team had been up all night working on an outage in some of the services that were part of their guide application. We talked about the issue, how it manifested itself and what impact it had on their customers. But there was one statement that has stuck with me since: “The worst part of this 13-hour outage was that it took us 12 hours to get the right person on the phone; and only one hour to get it fixed…”

That is when I knew that a service mesh could solve this problem and increase the engineering efficiency for teams of all sizes. First, by ensuring that in day-to-day engineering and operations, experts were focused on what they were experts of. And second, when things went sideways, it was the strategic point in the stack that would have all the information needed to root-cause a problem — but also be the place that you could rapidly restore your system.

Day-to-Day Engineering and Operations

A service mesh can play a critical role in day-to-day engineering and operations activities, by streamlining processes, reducing test environments and allowing experts to perform their duties independent of application code cycles. This allows DevOps teams to work more efficiently, by allowing developers to focus on providing value to the company’s customers through applications and operators to provide value to their customers through improved customer experience, stability and security.

The properties of a service mesh can enable your organization to run more efficiently and reduce operating costs. Here are some ways a service mesh allows you to do this:

  • Canary testing of applications in production can eliminate expensive staging environments
  • Autoscaling of applications can ensure efficient use of resources.
  • Traffic management can eliminate duplicated coding efforts to implement retry-logic, load-balancing and service discovery.
  • Encryption and certificate management can be centralized to reduce overhead and the need to make application changes and redeployment for changing security policies.
  • Metrics and tracing gives teams access to the information they need for performance and capacity planning, and can help reduce rework and over-provisioning of resources.

As organizations continue to shift-left and embrace DevOps principles, it is important to have the right tools to enable teams to move as quickly and efficiently as possible. A service mesh helps teams achieve this by moving infrastructure-like features out of the individual services and into the platform. This allows teams to leverage them in a consistent and compliant manner; it allows Devs to be Devs and Ops to be Ops, so together they can truly realize the velocity of DevOps.

Reducing Mean-Time-To-Resolution

Like it or not, outages happen. And when they do, you need to be able to root-cause the problem, develop a fix and deploy it as quickly as possible to avoid violating your customer-facing SLAs and your internal SLOs. A service mesh is a critical piece of infrastructure when it comes to reducing your MTTR and ensuring the best possible user experience for your customers. Due to its unique position in the platform, sitting between the container orchestration and application, it has the unique ability to not only gather telemetry data and metrics, but also transparently implement policy and traffic management changes at run time. Here are some ways how:

  • Metrics can be collected by the proxy in a service mesh and used to understand where problems are in the application, show which services are underperforming or using too many resources, and help inform decisions on scaling and resource optimization.
  • Layer 7 traces can be collected throughout the application and correlated together, allowing teams to see exactly where in the call-flow failed.
  • Policy can allow platform teams to direct traffic — and in the case of outages, redirect traffic to other, healthier services.

All of this functionality can be collected and implemented consistently across services — and even clusters — without impacting the application or placing additional burden or requirements on application developers.

It has been said that a minute of downtime can cost an enterprise company up to $5600 per minute. In an extreme example, let’s think back to my meeting with the cable provider. If a service mesh could have enabled their team to get the right expert on the phone in half the time, they would have saved $2,016,000.00. That’s a big number, and more importantly, all of those engineers could have been home with their families that night, instead of in front of their monitors.


Announcing Aspen Mesh 1.5

Announcing Aspen Mesh 1.5

We’re excited to announce the release of Aspen Mesh 1.5 which is based on Istio’s latest LTS release 1.5 (specific tag 1.5.2). Istio 1.5 is the most feature-rich and stable release since Istio 1.1 and contains many enhancements and improvements that we are excited about. With this release, Istio continues to increase stability, performance and usability. At Aspen Mesh, we’re proud of the work that the Istio community has made and are committed to helping it become even better. We continue to represent users’ interests and improve the istio project as maintainers and working group leads for key areas, including Networking and Product Security. It has been amazing to see the growth of the Istio community and we look forward to being a part of its inclusive and diverse culture.

Given the changes in the release, we understand that it can be challenging for users to focus on their key issues and discover how the new features and capabilities relate to their needs while adding business value. We hope this blog will make it easier for our users to digest the sheer volume of changes in Istio 1.5 and understand the reasons why we have, at times, chosen to disable or not enable certain capabilities. We evaluate features and capabilities within Istio from release to release in terms of stability, readiness and backwards compatibility, and we’re eager to enable all capabilities once they are ready for enterprise consumption.

Key updates in Istio 1.5 include: 

  • The networking APIs were moved from v1alpha1 to v1beta1 showing that they are getting closer to stabilizing; 
  • Enabling Envoy to support filters written in WebAssembly (WASM); 
  • The istio operator continues to make major strides in installing and upgrading Istio, as well as istioctl; 
  • A new API model to secure mutual TLS (mTLS) and JWT use in your service mesh.

The number of features added or changed by Istio is long and exciting, so let’s dig deeper into the changes, rationale behind them and how it will impact you as an Aspen Mesh customer.


New Security APIs

Istio 1.5 introduces new security APIs (PeerAuthentication, RequestAuthentication) that work in conjunction with Authorization Policy resources to create a stronger security posture for your applications. We understand that customers have widely adopted Authentication Policies, and the pain of incrementally adopting mTLS as well as debugging issues encountered. We believe that the new set of APIs are a step forward in the evolution of application security. With the older APIs being deprecated in Istio 1.5— and with the intent to remove these APIs in Istio 1.6—it is imperative that customers understand the work required to ease this transition.

To ease migration from the v1alpha1 APIs to the v1beta1 APIs Aspen Mesh has updated our dashboard to reflect mTLS status using the new APIs, we have updated our Secure Ingress API to use the new security APIs and we have updated our configuration generation tool to help you incrementally adopt the new APIs.


Challenges with Older APIs

While Authentication Policies worked for most of the use cases, there were architectural issues with the API choices.

Authentication Policies used to be specified at the service level, but were applied at the workload level. This often caused confusion and potential policy escapes as all other Istio resources are specified and applied at the workload level. The new API addresses this concern and is consistent with the Istio configuration model.

Authentication Policies used to handle both end user and peer authentication causing confusion. The new API separates them out as they are different concerns that solve different sets of problems. This logical separation should make it easier to secure your application as the possibility of misconfiguration is reduced. For example, when configuring mTLS if there is a conflict between multiple PeerAuthentication resources, the strongest PeerAuthentication (by security enforcement) is applied. Previously conflict resolution was not defined and behavior wasn’t deterministic.

Authentication Policies used to validate end user JWT credentials and reject any request that triggered the rule and had no or invalid/expired JWT tokens. The new API separates the Authentication and Authorization pieces into two separate composable layers. This has the benefit of expressing all allow/deny policies in a single place, i.e. Authorization resources. The downside of this approach is that if a RequestAuthentication policy is applied, but no JWT token is presented, then the request is allowed unless there's a deny Authorization policy. However, separating authentication/identity and authorization follows traditional models of securing systems, with respect to access control. If you are currently using Authentication policies to reject requests without any JWT tokens, you will need to add a deny Authorization policy for achieving parity. While Istio has greatly simplified their security model, our Secure Ingress API provides a higher level abstraction for the typical use case. Ease of adoption is one of our core tenets and we believe that Secure Ingress does just that. Feel free to reach out to us with questions about how to do this.


Migration Towards New APIs

You don’t have to worry about resources defined by the existing Authentication Policy API as they will continue to work in Istio 1.5. Aspen Mesh supports the direction of the Istio community as it trends towards using workload selectors throughout its APIs. By adopting these new APIs we are hopeful that it will alleviate some application security concerns. 

With the removal of the v1alpha1 APIs in istio 1.6 (ETA June 2020) we are focused on helping our customers migrate towards using the new APIs. Our Secure Ingress Policy has already been ported to support the new APIs, as well as our tool to help you incrementally adopt mTLS. Note that our Secure Ingress controller preserves backward compatibility by creating both RequestAuthentication and Authorization policies as needed to ensure paths protected by JWT tokens cannot be accessed without tokens.

Users upgrading to Aspen Mesh 1.5.2 will see their MeshPolicy replaced with a mesh-wide PeerAuthentication resource. This was intentional, although upstream Istio chose not to remove a previously installed MeshPolicy, so that users can quickly migrate their cluster towards using the new security APIs. With that in mind, istioctl now includes analyzers to help you find and manage your MeshPolicy/Policy resources, giving you a deprecation message with instructions to migrate away from your existing policies.


Extending Envoy Through WASM

WASM support, as an idea, can be traced back to October 2018. A proxy ABI specification for WASM was also drafted with the idea that all proxies, and not just Envoy, can adopt WASM helping to further cement the Istio community as thought leaders in the service mesh industry. The Istio community also had major contributions to Envoy through the envoy-wasm repository to enable WASM support and is the fork of Envoy used in Istio 1.5. There are plans to have their hard work incorporated into the mainline Envoy repository.

This is a major feature as it will enable users to extend Envoy in new and exciting ways.

We applaud the Istio community for its work to deliver this capability. Previously writing a filter for Envoy required extensive knowledge of not only Envoy C++ code, but also how to build it, integrate it and deploy Envoy.

WebAssembly support in Envoy will allow users to create, share and extend Envoy to meet their needs. Support for creating Envoy extensions already exists with SDKs for C++, Rust, and AssemblyScript, and there are plans to increase the number of supported languages shortly. Istio is also continuing to build its supporting infrastructure around these Envoy features to easily integrate them into the Istio platform. There is also on-going work to move already existing Istio filters to WASM; in fact, Telemetry V2 is a WASM extension. Istio is eating its own dog food and the results speak for themselves. Expect future blogs around WASM capabilities in Istio as we learn more about its feature set and capabilities.

For more information, please see Istio’s WASM announcement


istiod and Helm Based Installs

Support for Helm v3-based installs continues to be a top priority for Aspen Mesh. Aspen Mesh Helm installation process is a seamless operation for your organization. Aspen Mesh 1.5 does not support the istiod monolith yet, but continues to ship with Istio’s microservice platform.

We are actively working with the Istio community to enable installations and upgrades from a microservice platform to the monolithic platform a first-class experience with minimal downtime in istio 1.6. This will ensure that our customers will have a stable and qualified release when they migrate to istiod.

As Istio has evolved, a decision was made to simplify Istio and transform its microservice platform to that of a monolith for operational simplification and overhead reduction. The upgrade path from microservices control plane to monolith (istiod) requires a fresh install and possible downtime. We want our customers to have a smooth upgrade and experience minimal downtime disruption.


Moving Towards a Simplified Operational System (istiod)

Benefits of a monolithic approach to end users, include a reduction in installation complexity and fewer services deployed which makes it easier for users to understand what is being deployed in their Kubernetes environment, especially as the intra-communication within the controlplane and the inter-communication between the control plane and data plane continues to grow in complexity. 

With the migration towards istiod, one of the key features that we anticipate will mature in istio 1.6 is the istio in-cluster Operator. In-cluster operators have quickly gained traction within the Kubernetes community and the Istio community has made a significant effort towards managing the lifecycle of Istio. A key feature that we are eager about is the ability to have multiple control planes, which would enable such things as canaries and potentially in-place upgrades. As the in-cluster operator continues to evolve we will continue to evaluate it and when we feel it is ready for enterprise use you should expect a more detailed blog to follow.


Other Features on the Horizon

As always, Istio and Aspen Mesh are constantly moving forward. Here is a preview of some new features we see on the horizon.


Mixer-less Telemetry

Many users have inquired about mixer-less telemetry, hence referred to as Telemetry V2. During testing, Aspen Mesh found an issue with TCP blackhole telemetry, others found an issue with HTTP blackhole telemetry and a few other minor issues were found. Aspen Mesh is committed to helping the Istio community test and fix issues found in Telemetry V2, but until feature parity is reached with Mixer telemetry we will continue to ship with Mixer, aka Telemetry V1. This is perhaps our most requested feature and we are eager to enable it. The work surrounding this has been a Herculean effort by the Istio community and we are eager to enable it in a future Aspen Mesh release.


Intelligent Inbound and Outbound Protocol Detection

While upstream Istio has previously enabled outbound intelligent protocol detection, Aspen Mesh has decided to disable it; the reasoning for this was detailed in our Protocol sniffing in production blog. For Istio 1.5, inbound intelligent protocol detection was also enabled. While this has the potential to be a powerful feature, Aspen Mesh believes that deterministic behavior is best defined by our end users. There have been a handful of security exploits related to protocol sniffing and we will continue to monitor its stability and performance implications and accordingly enable them if warranted in future releases.

For this and prior releases, we recommend our users continue to prefix the port name with the appropriate supported protocol as suggested here. You can also use our vetter to discover any missing port prefixes in your service mesh.


Next Steps for You

The Aspen Mesh 1.5 binaries are available for download here. If you have any questions about your upgrade path, feel free to reach out to us at support@aspenmesh.io.

If you’re new to Aspen Mesh, you can download a free 30-day trial here


Service Mesh University

Service Mesh University

We're Excited to Launch Service Mesh University

There’s a lot of talk -- and even more questions -- about service mesh these days.

Service Mesh University

What is it? Do you really need it? Who should own it? How do you get it running? Will it play nicely with your tech stack? How do you know it's working? How is it evolving?

Service mesh can be complex, so that’s why we’ve created Service Mesh University (SMU). This series of seven short classes enables you to find the answers to these questions, on-demand, at your own pace.

Each class is hosted by a different Aspen Mesh 'meshpert' and is tailored to each topic. In addition, transcripts of the videos, an outline and summary of each class, and extra links and materials where you can find additional related information is posted along with each video for you to take with you.

Why SMU?

Since 2017, Aspen Mesh has been at the forefront of service mesh technology. Aspen Meshers come from a myriad of startups and some of the most recognizable companies in the world, but the one thing we all have in common is a history of solving complex engineering and infrastructure challenges. Our engineers are experts in Istio, Envoy and Kubernetes, and we can help you get the most out of containerized applications. And we don't want to keep all that expertise to ourselves!

As a team intent upon driving improved operations through smarter and more efficient infrastructure, that is also reliable and easy to operate, we hope this new video collection helps you to learn how a service mesh can help you.

What You'll Learn

Class 101: Intro to Service Mesh (with Zach Jory and Rose Sawvel)

  • Learn what a service mesh is
  • Discover the basics of how a service mesh works
  • Explore functionality a service mesh provides

Class 201: Foundations of Service Mesh (with Shawn Wormke)

  • Learn about the service mesh landscape
  • Discover how a service mesh can help your team and your end users
  • Explore prerequisites you’ll need before getting started with a service mesh

Class 301: Service Mesh Architectures (with Andrew Jenkins)

  • Find out more about service mesh as the next tier of communication patterns for microservices
  • Learn about the Istio architecture and how it improves Kubernetes
  • Discover the different service mesh components and how they operate
  • See how service mesh enables more efficient engineering processes

Class 401: Security, Reliability, and Observability (with Granville Schmidt)

  • Learn about security, reliability and observability
  • Discover the power that a service mesh provides by combining these three elements

Class 501: Setting Up Your Service Mesh (with Jacob Delgado)

  • Learn about what you need before you start setting up the Aspen Mesh service mesh
  • Walk through how to set it up
  • Discover what it helps you do

Class 601: Maintaining and Improving Your Service Mesh (with Michael Davis)

  • Learn about common issues to watch out for when operating a service mesh
  • Discover best practices for keeping your service mesh up to date
  • Find out about integrations with other tools that could have an impact on how you use your service mesh

Class 701: The Future of Service Mesh (with Neeraj Poddar)

  • Learn about where service mesh is headed
  • Discover what that means for you if you’re already using a service mesh
  • Find out how technologies like service mesh are helping companies deliver greater value to their end users

We hope you'll join us to learn more about service mesh!

Please fill out the form below to access the classes.




Service Mesh Agility Stability Aspen Mesh

Agility with Stability: Why You Need a Service Mesh

“Move fast and break things” may have worked for Facebook, but it's a non-starter for most companies.  Move fast? Yes. Break things? Not so much.  

You're probably working at a company that's trying to balance the ability to move quickly — responding to customer needs in an ever-changing world — with the need to provide secure, reliable services that are always there when customers need them.  You're trying to achieve agility with stability and it's why you may need a service mesh; a configurable infrastructure layer for a microservices application that helps make communication between service instances flexible, reliable, and fast.

We work with a variety of customers, from small startups to large enterprises, but they’re all deploying and operating microservices applications at scale. No matter the company size or industry, we tend to get three common requirements:

  • I need to move quickly.
  • I need to quickly identify and solve problems.
  • I need everything to be secure.

Let's explore these three needs, as we often hear about them from platform owners and DevOps leads who are building and running next generation microservices platforms.

I Need to Move Quickly

This is where it all starts. You're moving to microservices so that you can push code to your customers faster than your competition.  This is how you differentiate and win in a market where the way you interact with your customers is through applications.

To win in these markets, you want your application developers focused on solving customer problems and delivering new application value.  You don't want them thinking about how they're going to capture metrics for their app, or what library they're going to use to make it more fault tolerant, or how they're going to secure it.  This is what you want your platform team solving - at scale - across your entire engineering organization.

A service mesh enables your platform team to implement organization-wide solutions like observability, advanced developer tooling, and security. This allows your application developers to focus on pushing the new features that will help you win in the market.  Focus drives speed and a service mesh creates focus.

I Need to Be Able to Quickly Identify Problems and Solve Them

In breaking your monolith down into microservices, things get more complex.  That becomes painfully obvious the first time you need to respond to a production issue and it takes hours of trolling through log files to even figure out where the problem occurred - let alone getting to solve it.  

A service mesh can provide you with the metrics and observability you need to effectively identify, troubleshoot, and solve problems in your microservices environment.  At the most basic level, you'll get metrics, distributed tracing, and a service graph to work with. For more advanced implementations, you can visualize key configuration changes that correlate with changes in metrics and traces to rapidly identify the root causes of problems. Then you can start fixing it.  

A service mesh also makes it easy to establish and monitor SLOs and SLIs (service level objectives and indicators) so you can prioritize critical fixes and easily share system status with the team. With a service mesh, platform owners can more quickly identify the root cause and gain a better understanding of their environments. This enables more resilient architecting in the future, to prevent outages occurring at all. 

I Need Everything to Be Secure

Security is table stakes.  They may say that all publicity is good publicity, but you do not want to be in the news for a security breach.  It's an existential threat to your business and your career. Defense in depth is the way to go, and a service mesh provides a powerful set of security tools to accomplish this.

Firstly, you can encrypt all the traffic moving among your microservices with mutual TLS that’s easy to set up and manage.  That way, should an attacker compromise your perimeter defenses, they’ll find it difficult to do much in a fully encrypted environment. Client and server side encryption ensures common microservices vulnerabilities such as man-in-the-middle attacks are prevented.

Secondly, don't just monitor all the traffic that's entering and leaving your microservices environment. You need to also implement fine-grained RBAC that makes the principle of least privilege a reality in your environment.  Admission controls and secure ingress allow platform operators to ensure that developers are following secure and compliant practices, and also make it easy for applications to communicate securely to the internet.   

And thirdly, take advantage of the observability that a service mesh provides into the security posture of your microservices, so that you have confidence everything is operating as expected.

If you’re working for a company that’s trying to walk the razor’s edge of agility with stability, check out service mesh.  It provides a powerful set of tools that help you operate a platform where application developers move quickly, while relying on the platform to solve the observability, traffic management and security challenges that come with a modern microservices environment.


Harnessing Microservices Uncertainty

Harnessing the Power of Microservices to Overcome an Uncertain Marketplace

According to PwC’s 23rd Annual Global CEO Survey, the outlook for 2020 can be summarized in one word—uncertainty. According to the survey, only 27% of CEOs are “very confident” in their prospects for revenue growth in 2020, a low level not seen since 2009. As organizations navigate their way through digital transformations, how can they leverage strategies and applications that help them overcome uncertainty, rather than causing more?

In this article, we talk with Shawn Wormke, Incubation Lead at Aspen Mesh, about how a service mesh can help companies achieve agility with stability in order to overcome uncertainty for the future and get ahead in the marketplace.  

Q: Many CEOs are feeling a sense of uncertainty. More than half of the CEOs surveyed by PwC believe the rate of global GDP growth will decline in 2020. With this concern top of mind, how can applications like service mesh drive value for organizations by addressing security challenges, skills gaps and increased complexity at scale?

A: In times of uncertainty, the potential for flat to decreasing revenues adds intense pressure for CEOs to maintain and grow their business. One of the ways they can overcome this challenge is to focus on becoming more agile and delivering more value to their customers — faster than their competitors — with new products and services. Almost every company has embraced Agile workflows and is adopting cloud and container technologies like Kubernetes to enable this, but these new complex and distributed technologies come with their own set of challenges around operations and security.

One of the patterns for addressing those challenges is service mesh, and I believe it should be at the center of a company’s approach to microservice architectures. Because service meshes, like Istio and Aspen Mesh, are inserted next to every microservice, it enables a strategic point of control for operating and securing next-generation application architectures. By moving critical operations like encryption, certificate management, policy, traffic steering, high-availability, logging and tracing out of the application and into the platform — where it belongs — you can ensure that you have your human capital adding application value rather than managing infrastructure. 

Q: What cloud native technologies and enterprise architecture modernization strategies are you seeing organizations leverage in order to thrive in a quickly evolving marketplace?

A: Microservices architectures, and the container technologies like Kubernetes that enable them, have fundamentally changed the way applications are delivered and managed. These new patterns allow companies to efficiently scale both software and engineering, reduce risk, and improve the overall quality of applications.

These technologies are new and they present challenges like most nascent technologies. But, with the amazing work of open source projects and communities like Istio, Prometheus, Jaeger, Grafana and many others, there are solutions available to help overcome these challenges.

Q: A business’s agility is what allows them to rapidly grow its revenue streams, respond to customer needs and defend against disruption. But is that enough?

A: Agility is a company’s number one business advantage. It is a business’s agility that allows them to rapidly grow revenue, respond to customer needs, and defend against disruption. It is the need for agility that drives digital transformations and causes organizations to define new ways of working, develop new application architectures, and embrace cloud and container technologies.

However, agility with stability is the critical competitive advantage. Companies that can meet evolving customer needs — while staying out of the news for downtime and security breaches — will be the winners of tomorrow.

Q: How exactly does a service mesh get you agility with stability?

A: Because a service mesh sits below the application and above the network — and has a control plane that can consume and apply policy — it enables development and platform teams to work together while focusing on their specific areas of expertise so companies can deliver solutions to their customers that are performant, secure and compliant. 

In addition, a service mesh handles encryption and provides visibility into an application's behavior like no other technology. It can see the “final product” of the application or service as an outsider and provides a unique perspective on that service’s behavior, performance and communication patterns. This allows operators to operate, manage and scale those services based on their actual needs and the end users’ experience.

Q: Service mesh is a useful tool, but when does it make sense for an organization to consider adopting one?

A: It is true that the service mesh pattern has been around for a few years, but it is still an early market for the technology and surrounding products. Specifically at Aspen Mesh, we have been working with customers in this area for over two years and realize that each organization is different in their maturity and needs when it comes to Kubernetes and microservices. A company may adopt service mesh early in order to meet compliance needs. Some organizations run into challenges in production and need visibility, while others may need to reduce errors caused by lack of engineering expertise on their development teams.

In general, you probably need a service mesh if you can no longer draw your microservices topology on a sheet of paper, or hold it in your head. This usually happens for our customers at about 15-20 microservices.

Q: What are some of the top use cases you are seeing service mesh used for?

A: Kubernetes and containers is a journey for most organizations. Along that journey, road-blocks will be encountered that must be addressed. The most common path for the organizations we talk to involves:

  • Understanding what services they have deployed and how they are communicating,
  • How they can make their platform and applications comply with either company or regulatory requirements, and
  • How they ensure they are providing the best possible user experience and reducing downtime.

Therefore, the most common use cases we see our customers implementing a service mesh for include visibility, observability, and encryption of service-to-service communication. More recently, we've seen adoption increase for operational benefits that allow them to quickly identify, diagnose and resolve customer-impacting problems.

Q: What do you see for the future of service mesh? How will it help organizations overcome the challenges associated with uncertainty?

A: Service mesh is a new frontier, and despite all the recent attention, is still a nascent market and pattern. This is due to its strategic point of control in application architectures and its ability to operate in a transparent and distributed manner. More and more companies, as they move from proof-of-concept to production with their new application architectures, will come to rely on a service mesh to provide a consistent layer in which they are able to control and manage their services while ensuring that all applications are optimally performing and meeting compliance and security requirements.

As service meshes mature, they will become a critical piece of infrastructure that enables organizations to maximize their true competitive advantage of agility with stability.

If you’re scaling microservices on Kubernetes, it's worth considering a service mesh to help you get the most out of your distributed systems. To learn more about service mesh, feel free to reach out to our team to schedule a time to meet.


Aspen Mesh digital transformation service mesh

Digital Transformation: How Service Mesh Can Help

Your Company’s Digital Transformation

It’s happening everywhere, and it’s happening fast. 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). 

Several years ago, digital transformations saw companies moving from monolithic architectures towards microservices and Kubernetes, but service mesh was in its infancy. No one knew they'd need something to help manage service-to-service communication. Now, with increasing complexity and demands coupled with thinly-stretched resources or teams without service mesh expertise, supported service mesh is becoming a good solution for many--especially for DevOps teams.

Service Mesh for DevOps

"DevOps" is a term used to describe the business relationship between development and IT operations. Mostly, the term is used when referring to 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. Ultimately, it’s the Dev and Ops teams who are responsibility to ensure that teams are communicating effectively, systems are monitored correctly, high customer satisfaction is achieved and projects and issue resolution are completed on time. A service mesh can help with this by enabling DevOps.

Integrating a Service Mesh: Align 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 service mesh 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 some of your company’s business objectives? Here are three we’ve identified that a service mesh can help to streamline:

1. 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.

2. 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 come with observability, security and resilience features, it can help alleviate these responsibilities, decreasing MTTD and MTTR.

3. Maintaining Delivery to Customers
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

How do you actually go about approaching the process of integrating a service mesh? What will drive success is for you to have 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 include:

  1. Mitigating risk
  2. Production readiness
  3. Policy frameworks

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. Ensuring security, compliance, and data integrity is the way to go. With security and compliance at top of mind for many, it’s important to address security head on. 

With a well-designed enterprise service mesh, you can expect plenty of security, compliance and policy 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.

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 real 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’ experiences.

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 and service availability policies.

How to Measure Service Mesh Success

No plan is complete without a way to measure, iterate and improve your success over time. So 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, there are a few things you can consider to get an idea of how well your service mesh is working for you. Start by finding a good way to measure 1) how your security and compliance is impacted, 2)  how much you’re able to change downtime and 3) differences you see in your efficiency.

Looking for more specific questions to ask? Check out the eBook, Getting the Most Out of Your Service Mesh for ideas on the right questions to ask and what to measure for success.