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.
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.
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 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:
Watch the WebinarFor 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!
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!
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.
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.
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.
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:
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:
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:
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.
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:
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 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 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.
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:
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.
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:
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
Enterprise Architect, OpenLogic
With over two decades in enterprise architecture, integration, SOA methodology, and data standards development, Shuddhasatwa implements technology solutions for clients worldwide. His love interest has been OpenStack since 2012.