Last updated at Tue, 12 Mar 2024 13:45:36 GMT
Just the other day I was hanging out with my developer buddy. We entered what we thought would be an interesting topic on how you cannot call an environment “DevOps” without analytics.
But we soon were in a nerd war on what a term meant.
Yes, this is what I talk about in my free time.
In the thick of it, we both used the term “Server Monitoring.” But neither of us were talking about the same thing. I was referring to log management and analysis, and he was referring to application performance monitoring (APM). No wonder the DevOps market is confused. But the good news is, once we realized our mistake, we agreed that both APM and log analysis are critical and beneficial to the DevOps practice.
It turns out your background is important to your interpretation of the DevOps lingo. There are basically four points of view: front-end developers, back-end developers, QA, and IT. They all speak the same language, but with different dialects. And the developer dialect is the furthest from IT’s. This is where the differences between APM and log analysis are confusing, but at the same time made more clear.
Developers
Developers are all about the software layer. And thus when they think analytics, they think mostly of analytics for the application. Which means, the “server” to them is the Web Server, not the VM that the stack is running on. When you talk about analysis, even if it is a log analysis platform and not APM being used, what they find the most important to them is getting data about the application operation, users, and functionality.
IT Operations
To IT the “server,” is at a minimum, the hypervisor, but could even be bare metal. IT keeps the VMs up and running, and their perception of the application is from the server up. They tend to think of server monitoring as OS events, and system level performance. They want to know about processes, bandwidth, pegged disks etc. As they work up the stack to the application layer, their interest is mostly focused on how activity and functionality will impact servers and uptime.
Both are right and wrong at the same time. But mostly both are wrong because they do not take the time to understand each other. Which leads to some interesting conversations that go nowhere. The result is a common vice committed across entire teams: choosing one tool for the job. This actually is feasible from IT’s perspective because log analysis has the unique ability to monitor and analyze across all layers of the application and all processes to support it.
APM
As we already alluded too, APM is the application layer only. In its simplest terms it breaks down to measuring the time for each http(s) request or post, and who made the request or post. But it goes further to an abstracted higher level value that views how application functionality either degrades or improves performance, and all user and application data over long periods of time. What is even more confusing is when you add in the term “load testing” (which is not APM either) because load testing is focused on the pre-release stages of development. It is executed by simulating connections to the application which APM does not do, but can monitor. Generally APM has not expanded to look at application data in the earlier stages of the pipeline. Such as QA, continuous integration or delivery (deployment is a different story).
Log Analysis
The great thing about log analysis is that it is like a warm blanket for the entire DevOps process. You can log anything and everything. From bare metal ( used in Software Defined Data Centers ), hypervisor, virtual machine (most common), and application. And not just your application, all the component applications around the entire process as well. This includes release management, IDE, and other services contributing to the creation of the application.
The other nice part about log analysis is that the more data you log, the more consistent your language is for talking about the environment.
The problem with getting the two to work together in sync, is not just the confusion around them, it is also in sharing. Neither IT nor developers like to share. So while IT might set up APM, the developers hoard it, and vice versa, IT might hoard log analysis. This commonly results in both teams getting the tools, but just so they can have their own castle.
Some organizations are more progressive. IT might deliver data from, or provide access to, the log analysis platform. Developers then find they can pretty much get, and share, all the data they need from the application layer, as well as it’s relationship to server data.
My vote is to have both. But I also have the perspective that you should do what you can to get them in the same place. Otherwise having two platforms means that the language barrier is carried forward and communication still doesn’t improve. DevOps is about breaking down walls, not building them up.
Integrations like Log Entries and New Relic are magic. No matter where you are, data is consistent, shared, and language is unified.
And once it is setup there really is no idea of where information is, how it is communication, or who owns what.
So the next time you start throwing around DevOps terminology, make sure you are talking about the same thing. And when it comes to server monitoring, allow log analysis to be the system of record for all data, and APM to do what it does best, understanding your users.
