Planning a Service Mesh: Key Focus Areas

Executing an open source software service mesh can seem insurmountable, especially when dealing with large legacy systems. However, having well-structured transformation plan can make that process much more achievable.

In this blog, we discuss some of the key focus areas used in planning a service mesh transformation, including sections on determining business capabilities, establishing governance models, operational and security considerations, and the milestones used to track your progress.

Why Should You Implement a Service Mesh?

The goal of implementing an open source software service mesh is to better achieve business goals and priorities. Doing so with an open source software service mesh is just one method for achieving these goals.

Implementing an OSS Service Mesh to achieve this transformation makes it possible to improve business agility, increase development speed, increase delivery speed, and improve the ability to achieve service level objectives.

Targeting and Achieving Business Values

An important step in planning your service mesh project is in tying the project back to your business goals and priorities. If an architectural transformation doesn’t present clear, honest value to your organization, then getting buy-in will be a (rightfully) herculean effort.

The transformation must have very clear, measurable business outcomes

Planning Your Service Mesh Implementation

Planning your Service Mesh integration project starts with a sound strategy. Without a sound strategy in place, the seemingly endless tasks needed to complete the transformation can quickly overwhelm and divert the project from its intended goal – achieving business values.

For the purposes of this blog, we’re going to focus on four of the five key focus areas for implementing a service mesh:

• Business Capabilities
• Organizational Actions
• Governance
• Operations and Security

Watch the Webinar

For a more in-depth breakdown of the process, don’t miss my recent webinar, Achieving Enterprise Transformation with an OSS Service Mesh. Watch it for free below!

Determining Business Capabilities

An early step in the transformation process is in determining your business capabilities. These capabilities are then defined as microservices on the OSS Service Mesh platform. This step helps to prevent the creation of duplicative services, and is accompanied by the creation of life-cycle management policies (more on these later). These policies are co-related and define business processes with the appropriate line of sight.

Setting a Reference Mesh Architecture

An important planning component for implementing a service mesh architecture (or any existing architecture, really) is having a shared and fully understood reference architecture. This ensures that those planning the process have a shared, fundamental understanding of the architecture at its most basic, component level. Rationalizing and validating this reference service mesh architecture serves as an important part of the overall organizational transformation, and is critical to the overall success of the project.

Organizational Actions

Establishing organized structures within your organization that can help to achieve your enterprise transformation is critical. While the webinar we mentioned above goes deeper into these actions, the two we cover here are especially important when implementing a service mesh.

Forming a Competency Center

Another important consideration in planning your OSS service mesh is in forming a competency center. The competency center provides guidance to the enterprise on how to produce microservices that accomplish the determined business capabilities needed for the service mesh platform.

Their duties include:

• Defining and charting a migration path for services from legacy to future state.
• Establishing and communicating standards and governance procedures for services to ensure the business capabilities can be realized from the services.
• Providing a common forum for representatives from all areas involved in designing, delivering and managing services to share best practices and address issues.

Domain Boards

Forming domain boards within the competency center helps to establish and communicate the standards and governance procedures mentioned above.

These standards and governance procedures are then communicated to extended teams in the following areas:

• Configuration Management
• Release Management
• Operations Management
• Security Management
• Service Lifecycle
• Operations Management
• Business Requirements Management

Establishing a Governance Model

Implementing proper mesh governance at the organizational level is unique to each organization, and is based on the underlying service classifications. Mesh governance is practiced to manage the creation and modification of enterprise-wide microservices by using the processes for lifecycle management, including:

• Microservice Life-cycle Management {Define, Analyze, Arch, Produce, Optimize, Operate}
• Policies {Security, QoS, Notification, Escalation}
• Reference architecture {abstract – component view}
• Microservice Taxonomy {Utility, Entity, Capability, Process}
• Standard Canonical Models {Business Object Document Model}
• Business Capability Model
• Service Metrics {Undelivered, Authentication, Access, Usage}

Microservice Governance

Microservices governance is categorized to be task centric. It’s mainly used for life-cycle management, and to enforce design policy decisions, but is also used as an aid in the “produce” phase by the microservice developers within the greater enterprise business units.

Mesh Policy Enforcement

Setting and enforcing the policies that govern service usage, currency, and SLAs is another important step in planning your open source service mesh architecture. Whether that’s quality of service, or encryption, policies need to be carefully laid out and adhered to in order to ensure success of the project. At a minimum, policies should include:

• Quality of Service Policies
• Business Rule Policies
• Notification Policies
• Version Management Policies
• Security Policies:
  • Access Control
  • Encryption
  • Signature
  • Logging
  • Auditing

Operations and Security Considerations

Mesh transformation allows the operational guidelines to be followed in conjunction with Security considerations in a coherent manner. It also allows you to reap the benefits of a true dev-ops lifecycle, since infrastructure is now code. Security is no longer an afterthought, even at the virtualized microservice abstraction layer. Greater operational oversight is required to generate and maintain metrics while in transformation phase.

Configuration Management

Configuration management is no longer a challenge when this function is governed by the Mesh Competency Center. That's because there is oversight at individual configurations with a line of sight to even upgrade, and the transformation related to migration of configuration management services.

Release Management

Release management now has the benefits of a true devops platform that allows multiple versions to be simultaneously released and maintained, governance  oversight is now available as policy from the transformation board so that implementation is now trivial, also obsolesce of branches are automatically archived.

Establishing Metrics

Metrics are used throughout the life-cycle phases to make policy decisions on the specific microservice. Historical data is critical for us in designing new services, and optimizing existing services.

The recommended initial set of metrics for transition team to capture are:

• Service Executed Count
• Undelivered Message Count
• Service Failure Count
• Authorization Failure Count
• Authentication Failure Count

Service Mesh Implementation Milestones

Using service mesh governance, we normally ensure delivery of the following items to ensure the corresponding business value is created within 6 months.

In addition, once the service lifecycle process is well understood, and the highlighted items are completed, it serves as a checklist to onboard additional line of business to the service domain platform.

Final Thoughts

Something as complex as an enterprise service mesh implementation far exceeds the limitations of a short blog post like this one. But if you have two key takeaways from this blog, let them be these:

1. Make sure the transformation process is paced and gives a clear return on investment.
2. Ensure the transformation journey is based on your business goals, not on individual technologies. 

Need Guidance on Your Service Mesh Transformation?

The enterprise architects here at OpenLogic have a wealth of experience in guiding companies through architectural transformations – especially those that modernize systems via open source packages. Whether you need guidance, support, or migration services, our team can help make your project a success. Talk with an expert today to see how we can help achieve your business goals.

Talk to an Expert

Additional Resources

• Blog - Microservices Architecture Example
• Blog - Kubernetes Orchestration Overview
• Datasheet - OpenLogic Discovery Workshop
• Video - What Are Microservices?