How to Turn Increased Resource Usage into an Advantage For You
Tags: servicemesh, istio, saas, microservices
Published: 2023-01-20 21:52:44

A Service Mesh is a fantastic solution for a variety of problems.
Critics, however, might bring up a considerable disadvantage: **The
increased need for computing resources.** If you're considering
deploying a Service Mesh but are hesitant because of the increased
resource usage, keep reading. In this blog post, you will learn why a
Service Mesh is worth its spending.

## Increased Resource Usage in Exchange for What?

Let's be clear, installing a Service Mesh increases your infrastructure
bill. Istio, for instance, installs proxies with every pod to intercept
network traffic. These proxies can consume quite a bit of memory. To
give you an example, let's say we run a pod with
[httpbin](https://httpbin.org/). The total memory usage might be in the
neighborhood of \~300 MB. Broken down, httpbin consumes 70-80 MB at
most, while over 200+mb goes towards the Istio proxy.


![httpbin memory consumption with Istio Sidecar](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3w4jpe9l2mek61gk1krz.png)



That's a substantial increase. Looking at these numbers without
additional context, it is not worth our while to run Istio.

## Gain Insight into your Cluster

If you had to find out right now what services within your Kubernetes
cluster handle a lot of traffic or are close to failing because they
reach resource limits, could you find out without too much effort?
Without any additional tooling, it's a challenging and time-consuming
task. It's like standing at the observation deck at a larger airport and
looking in the sky for approaching airplanes. You know they're there,
but you can only see them a minute before the touchdown. Up in the
tower, on the other hand, with radar available, monitoring air traffic
became much more manageable. With the right equipment at your disposal,
keeping track of incoming airplanes is more than manageable, whether
sunny or foggy.

The same is true for a Service Mesh. Once installed, you see which
services are healthy or need more attention. You also learn about all
"traffic patterns" within your Kubernetes Cluster. With that data
available, it might turn out there are services that shouldn't be
talking to each other.


![Calisti Demo Applicatio Topology](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6jkoe4oi5mj5g3if5q0h.png)



## Planning for the Future

When was the last time your business faced a **"scaling event"**, such
as Black Friday or onboarding a large new Customer? Whatever the event
might be, it results in a (significant) increase in traffic. Is your
cluster ready for that?

Without doing anything, and the new customer just onboarded, things will
likely break, like too many new users and too much traffic to handle. To
mitigate such outages, what services would you need to scale? The good
news is: It doesn't have to come that far. With Istio, you can
investigate in advance to find out: Are all services healthy right now?
What happens when we add some more traffic? Do we see any red bubbles
pop up?

![MySQL Service Health](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fsra71p8v3wk2aodr8e8.png)



Nothing feels better than coming in to work on the day when a massive
number of new users start using the system, and everything **just**
works. Events like Black Friday or new Enterprise customers became a lot
less intimidating.

## Rapid Response During Outages

It's everybody's worst nightmare: Receiving an emergency ticket because
a critical feature stopped working. Users can't check out their products
or can't complete that one important transaction. In either case, time
is of the essence to fix it.

Every minute the application is completely offline or only partially
functional costs the company money. Figures quickly go up to Thousands
of Dollars per Minute.

How long does it usually take for the team to resolve a critical user
issue and find the faulty service(s)? With a Service Mesh, you can
identify these faults almost in real time. What would it mean for you if
you could reduce your MTTR from several hours to one hour or less?

In such scenarios, it becomes easier to offset the increased hardware
usage with a significantly reduced MTTR.

## Conclusion

A Service Mesh requires additional resources, which increases your
infrastructure spending. This increase, on the other hand, buys you
Insight into the following:

- What services are causing an outage?
- Current resource utilization
- Potential Bottlenecks

If you're interested in getting started with a Service Mesh, but you're
not feeling comfortable reading Istio documentation for hours at a time,
check out [Calisti.app](https://calisti.app). Calisti is a managed Service Mesh
using Istio under the hood. You get all features Istio offers already
configured so that you can get started right away. To get started, visit https://calisti.app.