Thanks to Harjot Gill, CEO and Co-founder and Shariq Rizvi, COO and Co-founder of Netsil, for sharing their vision for application performance management (APM) in a microservices world.
I just completed twenty interviews with executives familiar with microservices architecture. One of their greatest concerns was having visibility into all of the microservices and all of the containers that multiply as the application grows.
Harjot and Shariq explained that the state of APM needs to change. They have created auto-discovery maps which shows who is talking to who while providing golden metrics for operations. Netsil naturally captures dependencies, interdependencies, and congestion freeing engineers to spend time on auto-discovery maps to drill down on performance or security rather than sorting through logs.
Q: What are the keys to application performance management?
A: There are four golden signals that make up the Site Reliability Engineering bible: 1) throughput; 2) latency; 3) error rate; and, 4) saturation of infrastructure. Performance monitoring complexity is shifting and business logic that was earlier a function call away in the code is now an API call away. Measuring the performance of, and understanding, API call is critical. If the site reliability engineer is alerted to a problem at 2:00 a.m. they’ll be grateful to have maps telling them the source of the problem rather than having to sort through 200 services. Auto-discovery is critical in the new world.
Q: What are the most significant changes to application performance management?
A: We talk about application performance observability. How does the system behave beyond primary inputs and outputs? Observer teams are suspicious of monitoring. Teams don’t know the problems they’ll have to solve in production, nor do they know what questions to ask. They need to understand the interactions between microservices and APIs. Netflix Flux is a traffic map that helps conquer the microservices challenge. Interrogation-centric UX will enable the asking of questions and visualize the action you need to take. This results in faster feedback loops and faster responses to customer needs: observer oriented action.
Q: How does Netsil improve the security of microservices and APIs?
A: We’re able to monitor cloud security and isolate portions of the environment as needed. We can see new queries, exfiltrations, and drill down to determine if these are legitimate or not. This improves SecOps’ lives. You’re able to see who’s talking to whom. The site reliability engineer is able to see if there are deviations. If the application layer is stressing out microservices during an API-level DDOS attack, you can perform freestyle analytics to identify the outside IP hitting your network and respond accordingly.
Q: What are some real-world use cases where you are helping your clients?
A: Kubernetes is taking the app to a whole new level of virtualization. Maps enable you to see how all the layers of Kubernetes are performing since we start with a map of the data center and enable the client to drill down from there. When doing continuous deployment (CD) clients can run old and new versions side-by-side for 15 or 20 minutes to see the drift in performance. You’re able to see more detail in each API call.
Q: What are the most common issues you see affecting the implementation of a microservices architecture?
A: Microservices is more of a multi-year journey for enterprises. We’re able to show where the hotspots are and identify which APIs are best suited to be separated in a microservice. You need to define the service level objective around each service. Young, hyper-growth start-ups moving fast may decommission services without realizing they’re still part of the critical path. The map will show this.
Q: What is the future of microservices from your point of view?
A: Thanks to open source, microservices will be the norm for the next five years. Modularization of apps will be critical to business transformation. There are clear cost benefits to agile – apps are easier to deploy; however, you need an observability tool in place to see what’s going on and ensure success. Large companies with hundreds of engineering teams can run independently with global visibility to make good use of resources. By increasing the data collection mechanism, you will be able to do more artificial intelligence (AI)/machine learning (ML) on raw data. Ultimately this will lead to removal of the human operator – the holy grail of automation.
Q: What do developers need to keep in mind when working on microservices?
A: Know how to define API interfaces. Be able to clean up APIs making them compatible backward and forward. Have an overall picture of what’s happening and focus your service on where the heavy lifting is taking place. You need to be able to see the lay of the land. Be aware of the team or services calling your service. While you may be working on three or four microservices, there are hundreds of others in the company that are depending on your microservices and you are depending on theirs. It’s a very dynamic concept – who are the customer and callers of my service. Have real-time dependency awareness.
Q: What have we not discussed that’s important to consider with regards to microservices?
A: Microservices require a complete cultural shift. Processes change with microservices. Toolsets change. Observability helps to see how your teams should be built. Don’t try to replicate Twitter, Google, or Netflix. Define what works for your enterprise. Every company is different. Ask whether or not you have the engineering discipline, internal standardization necessary to move to a microservices architecture. If not, get help from tool and partners – it’s critical to your organization’s survival.