Getty Images
How viable is open source service mesh?
The open source vs. proprietary service mesh debate has a lot of gray area, and the best fit for an org might fall into that spectrum. Here's what to consider before you decide.
Five years ago, Kubernetes was simply a container option, but today it's considered an essential component of a container strategy. Many experts and users believe that service mesh technology will follow the same path, but there's still debate on what product, or even class of product, will win out.
Most service mesh discussions center on open source tools like Istio or Linkerd. But because service mesh and its relationship to cloud applications are complex, many users fear open source technology.
Service mesh and open source technology
Service mesh technology provides message and event flow management, load balancing and component discovery in microservice-based, cloud-native applications. While simpler API brokers work for simple cloud applications, service mesh has become the go-to model for the complex applications enterprises are building. Whether open source is the right approach to service mesh is an important question cloud planners and development teams must address.
Let's start with an important point, which is that Open Source and proprietary aren't the only options. In fact, the definitions of these terms can create a huge hole in offerings that most real-world deployments fall through.
The most popular service mesh tools are based on open source technology, but are offered in bundles that provide support and ancillary tools. Because this model dominates, one could argue that open source service mesh isn't viable and proves that a paid strategy is the way to go. This tension, if open source service mesh is viable or not, helps answer the broad question this tip raises.
Why adopt open source service mesh tools?
Users can adopt open source products two ways -- as software that users must support and compile from source code, or as a tool that includes packaging and support. But perhaps one in 10 prospective service mesh users would consider the first of these strategies.
Why make that decision?
- Support-bundled open source service mesh software is no longer strictly free. If a company has a strong development team, particularly one familiar with open source software development and use, it could be possible to package and support an open source service mesh at a lower cost than acquiring the support-bundled version. For companies with extensive open source development experience, this is often the driver for going strictly open source.
- Support-bundled open source service mesh offerings often lag behind the current state of the software. Open source software is revised more often than proprietary software -- a complaint from many users who find the constant changes expensive to track. However, new features are offered quickly in the native open source form, while it could take six months or more for those features to work their way into a specific support-bundled version.
- Dependencies. Software depends on OSes and middleware features, and these features evolve as projects advance in capabilities and fix bugs. A support-bundled service mesh will work for a specific set of OS and middleware versions, and the requirements might be different for other elements of cloud software. In some cases, it might be impossible to harmonize all the dependencies of the products without getting cloud software from a single source, which many enterprises feel is a form of vendor lock-in.
Cloud provider service mesh
If open source self-support is one option, then a proprietary service mesh is the other. Even here, the question of what proprietary means will arise. All public cloud providers offer service mesh as a web service, but this is often based on open source tools such as Istio or Linkerd.
Choosing a cloud provider service mesh is justified when the service mesh is necessary within a single cloud provider -- as opposed to hybridized or multi-cloud environments. The justification for using a cloud provider service mesh is similar to the justification for using any cloud provider web service, including managed container and Kubernetes services: It reduces the packaging and support efforts associated with a service mesh deployment.
Two points should be clear now:
- The overwhelming majority of service mesh deployments are based on open source tools, so not only is open source viable in the space, it dominates.
- The great majority of open source service mesh adoptions are support bundled or cloud-service based. They are not adoptions of open source products compiled and supported by the enterprises themselves.
Cloud software is complicated, and it is getting more complicated every day. It is difficult for an enterprise to adopt a self-supported open source service mesh without committing to the same model for at least the OS and middleware tools needed for, or related to, that service mesh. With the growing complexity of cloud software, fewer users are making the choice to support open source service mesh technology on their own, and that's likely the best decision.
The final test is whether your company has already embarked on self-supported open source projects. If the answer is yes, then using open source service mesh technology could be smart. If not, then a support-bundled approach is the best choice.
