Guest: Renuka Nadkarni (LinkedIn)
Company: Aryaka (Twitter)
Show: T3M

Aryaka offers secure access service edge (SASE) solutions, integrating networking and security as a service to customers. In this episode of TFiR: T3M, Aryaka Chief Product Officer Renuka Nadkarni shares her insights on observability and how that term and the company have evolved through the years.

Evolution of Aryaka:

• When Aryaka was founded in 2009, containers weren’t a big deal and Kubernetes didn’t exist. However, the software had to be provisioned because of the needs of the business. So, they did process-level isolation, which is the main purpose of a container. Without using the term “container” and all that’s associated with it, by definition and by design, Aryaka was built with it.
• As a service, Aryaka’s customers are global, with instances that are running globally. They built a monitoring system called EagleEye and gradually added a lot of capabilities that we today call observability.
• Back in the day, people were doing “monitoring.” Then, it evolved into root-cause analysis. Everything was monolithic. The applications were monolithic. Users were in the office, the applications were in the data center, and everything was relatively deterministic, so troubleshooting was easier.
• Then, environments became highly non-deterministic because users are now working from home, the applications are in the cloud as a service. The applications themselves are microservices-based.
• Aryaka was already doing process isolation and running multiple instances for global scaling, so it was dealing with those kinds of problems and getting the signals from disparate and very diverse ecosystems. They have firsthand experience in observability, and they have evolved with the industry.

Observability trends:

• Observability is necessary to operate a business.
• Companies are already doing things that are part of observability. Things used to be reactive. Now, people want to do more predictive analytics and predictive monitoring. These conversations are done out of necessity, primarily for business survival.
• Companies want to know what’s happening to their workloads on Amazon, how many S3 buckets they have, and who’s talking to who. They are starting to realize that with observability, they not only figure out what’s going on, but they discover a whole bunch of insights.
• One of the fundamental requirements of observability is that there must be instrumentation in place, i.e., things that gather signals and give you the right information, etc.
• There is now a tendency for more instrumentation by design. It has to be baked in. The new mindset is “If I don’t build the instrumentation right from the get-go, adding it later is harder.”

Challenges that hinder adoption of observability:

• Number of silos that exist within an organization: Whose responsibility is it, whose problem is it, who should actually spend resources (time, budget).
• Disparate projects and frameworks: Not everybody subscribes to observability, but everyone has some flavor of it.
• Petabytes of data: how to handle it, where to put it, who is going to churn and analyze this information, who’s going to pay for it.

On generative AI:

• There’s definitely a lot of interest, lots of opportunity, but it boils down to how a company is going to make it work from a practical point of view. There has to be an initial investment to set it up.
• Generative AI depends on the data it is being fed. If you have good data, you get good results. If you have bad data, you get questionable results. As long as you use it in the right way, for the right use cases, it definitely is much easier to control.
• Aryaka is using generative AI for knowledge base. They use all the data on all the questions that customers have asked them and all the answers they gave to figure out a better version of the answer.

Advice for companies looking to start their observability journey:

• Understand your priorities. What are the cost and resource constraints? What kind of data is meaningful? Otherwise, you will very easily run into data overload problems.
• Build the architecture, build the systems from the get-go with security and auditability in mind. Do you have GDPR constraints? Do you have things that need to be monitored and produced for audit purposes?
• Build expertise slowly and gradually.
• Use standardization so you can interoperate with multiple open-source systems.
• Manage the resistance within the organization and establish the cultural base.
• Know that observability is a journey. It’s not one day, you don’t have it and the next day, you have the most observable system. It takes time and systematic effort across the organization.

This summary was written by Camille Gregory.