This post was originally published by upguard.
When we set out to create a cloud-based tool for configuration monitoring, we used the tools we knew and wrote UpGuard using JRuby. For our application, JRuby had many good qualities: getting started only required a one line install, the agent only needed to talk out on port 443, and it was platform agnostic. Using JRuby we demonstrated the value of system visibility, attracted our first cohort of customers, and raised the funds to expand UpGuard. Now we’re not only scrapping that agent, we’re moving away from agent-based architecture altogether. Here’s why.
As we’ve learned more about configuration monitoring and discovery, both from our own R&D and from working with our customers, we’ve realized that an agentless connection manager is better than a per host installed agent. Given the investment in JRuby as a technology, our first attempt was to use the JRuby agent as a connection manager. Since expanding to deployments of tens of thousands of nodes, the performance and memory requirements of JRuby quickly became problematic. (If you want to argue about JRuby, here’s the post where you should do it.) Given the position of the company at the time, we had the rare luxury of choosing between optimizing the 2-3 year old code base in order to meet the needs of our customers or rewriting it all together. Rather than accepting the limits of JRuby, we rewrote our application in Go to achieve the goal of an agentless connection manager with the best technology available.
We are proud to announce two great things simultaneously: the launch of our fully featured agentless connection manager, and a tech refresh that improves UpGuard’s benchmark’s across the board.
The Argument for Agentless
1) Maintenance costs. Far and away, the biggest argument for an agentless design is to slash maintenance costs. UpGuard is intended to make large infrastructures easier to manage and to increase the server/admin ratio. An installed agent means additional costs for users whenever updates are rolled out. There is absolutely no way around that problem with installed agents. More subtly, since those updates will have to make it through a change management process, it also means that (potentially many) different versions of UpGuard will be deployed at any given time. More supported versions = higher likelihood that something will break and need fixing. Supporting fewer versions also means we can provide a higher level of support for the current connection manager and deliver requested features more quickly.
Read more here: www.upguard.com
The post Agent vs Agentless Monitoring: Why We Chose Agentless appeared first on Cybersecurity Insiders.
December 26, 2020 at 05:39PM
0 comments:
Post a Comment