I have a four year old son who recently started attending full day preschool. It has been fascinating to watch his interests shift from playing with stuffed animals and pushing a corn popper to playing with his science set (w00t for the STEM lab!) and riding his bike. The other kids in school are definitely informing his view of what cool new toys he needs. Undoubtedly, he could still make due with the popper and stuffed animals (he may sleep with Lambie until he’s ten), but as he progresses his desire to explore new things increases.
Watching the community around service mesh develop is similar to watching my son’s experience in preschool (if you’re willing to make the stretch with me). People have come together in a new space to learn about cool new things, and as excited as they are, they don’t completely understand the cool new things. Just as in preschool, there are a ton of bright minds that are eager to soak up new knowledge and figure out how to put it to good use.
Another parallel between my son and many of the people we talk to in the service mesh space is that they both have a long and broad list of questions. In the case of my son, it’s awesome because they’re questions like: “Is there a G in my name?” “What comes after Sunday?” “Does God live in the sky with the unicorns?” The questions we get from prospects and clients on service mesh are a bit different but equally interesting. It would take more time than anybody wants to spend to cover all these questions, but I thought it might be interesting to cover the top 3 questions we get from users evaluating service mesh.
What do I get with a service mesh?
We like getting this question because the answer to it is a good one. You get a toolbox that gives you a myriad of different capabilities. At a high level, what you get is observability, control and security of your microservice architecture. The features that a service mesh provide include:
- Load balancing
- Service discovery
- Ingress and egress control
- Distributed tracing
- Metrics collection and visualization
- Policy and configuration enforcement
- Traffic routing
- Security through mTLS
When do I need a service mesh?
You don’t need 1,000 microservices for a service mesh to make sense. If you have nicknames for your monoliths, you’re probably a ways away from needing a service mesh. And you probably don’t need one if you only have 2 services, but if you have a few services and plan to continue down the microservices path it is easier to get started sooner. We are believers that containers and Kubernetes will be the way companies build infrastructure in the future, and waiting to hop on that train will only be a competitive disadvantage. Generally, we find that the answer to this question usually hinges on whether or not you are committed to cloud native. Service meshes like Aspen mesh work seamlessly with cloud native tools so the barrier to entry is low, and running cloud native applications will be much easier with the help of a service mesh.
What existing tools does service mesh allow me to replace?
This answer all depends on what functionality you want. Here’s a look at tools that service mesh overlaps, what it provides and what you’ll need to keep old tools for.
Not yet. It replaces some of the functionality of a API gateway but does not yet cover all of the ingress and payment features an API gateway provides. Chances are API gateways and service meshes will converge in the future.
You get tracing capabilities as part of Istio. If you are using distributed tracing tools such as Jaeger or Zipkin, you no longer need to continue managing them separately as they are part of the Istio toolbox. With Aspen Mesh’s hosted SaaS platform, we offer managed Jaeger so you don’t even need to deploy or manage them.
Just like tracing, a metrics monitoring tool is included as part of Istio.With Aspen Mesh’s hosted SaaS platform, we offer managed Prometheus and Grafana so you don’t even need to deploy or manage them. Istio leverages Prometheus to query metrics. You have the option of visualizing them through the Prometheus UI, or using Grafana dashboards.
Yep. Envoy is the sidecar proxy used by Istio and provides load balancing functionality such as automatic retries, circuit breaking, global rate limiting, request shadowing and zone local load balancing. You can use a service mesh in place of tools like HAProxy NGINX for ingress load balancing.
Istio provides mTLS capabilities that address some important microservices security concerns. If you’re using SPIRE, you can definitely replace it with Istio which provides a more comprehensive utilisation of the SPIFFE framework. An important thing to note is that while a service mesh adds several important security features, it is not the end-all-be-all for microservices security. It’s important to also consider a strategy around network security.
If you have little ones and would be interested in comparing notes on the fantastic questions they ask, let’s chat. I’d also love to talk anything service mesh. We have been helping a broad range of customers get started with Aspen Mesh and make the most out of it for their use case. We’d be happy to talk about any of those experiences and best practices to help you get started on your service mesh journey. Leave a comment here or hit me up @zjory.