Why you should use code-driven instead of infrastructure-driven monitoring tools with Symfony
This article will share why software developers should always prefer code-driven to infrastructure-driven monitoring tools.
Understanding their different approaches will help you better organize your team, stay agile and fast during delivery times, and quickly identify issues before your customers are aware of them.
Valerio Barbera is the CTO of Inspector.
As CTO of a Code Execution Monitoring product, he has the opportunity to discuss this topic every week with companies of all sizes searching for a better solution.
Due to software bugs and down times, he's witnessed firsthand disputes between teams, angry customers, canceled contracts, lawsuits, and other disasters.
In most cases, the software development team was simply not in the right position to deliver optimal results.
This article will utilize his experience so that you can make the lives of your developers easier and avoid losing customers and money due to unexpected technical problems in your applications.
Why Monitoring Matters
Many developers first feel the need to monitor their applications when they start working on a medium to large project.
The reason is simple: when your software becomes complex or serves high-value customers, software bugs become expensive; doubly so when your customers find them! As a result, customers may rate you as unreliable and search for other alternatives.
Monitoring is the best way for developers to avoid unexpected incidents and retain happy customers as long as possible – which means continuing stable income.
Infrastructure-driven monitoring tools
The best-known monitoring platforms are DataDog, Dynatrace, NewRelic, AppDynamics, and others. They require installation and configuration at the server level or on the IT infrastructure in general, but many developers hate dealing with this. Like them, you want to stay focused on coding.
The tools necessitate lots of assistance and training or even a dedicated engineering team for configuration and maintenance. They also tend to be too complex and expensive for small to medium-sized teams that need to focus solely on application development.
Dealing with infrastructure is a concern for many developers for two reasons:
1) Work overload
Managing IT operations is a profession in itself. It requires many vertical skills in server environments and involves complicated technologies like Kubernetes.
In order to reduce this headache, developers tend to rely on external tools to automate server provisioning like Cloud Hosting panels, PaaS platforms, or others.
But in mid to large-sized organizations, or when a company scales up, it may be necessary to have a dedicated team to take care of the infrastructure, in order to leave developers free to spend their time working on application code and implementing new features.
2) Everything configured at the server level tends to be out of the developer's control
Whether you’re using infrastructure automation tools, or have external teams to take care of it, everything configured at the server level is out of the software development lifecycle, and developers tend to lose their autonomy from other teams.
Each team in your organization has its own monitoring needs (Kubernetes, Cyber Security, Networking and Infrastructure, Privacy and Compliance, application, etc.). Something that works in one scenario may be a bottleneck in another.
Valerio recently held a conference call with the management of one of the largest utility companies in Europe. He saw the heads of the software development team and the infrastructure operations team meet for the first time in years.
Because sharing tools across different teams was difficult, software developers continued to rely on logs to monitor their applications, instead of depending on the operations team for any configuration or customization.
Forcing the collaboration of different teams with different goals on the same tool can create confusion, constant email exchanges across teams to adjust configurations or make customizations. In the end software developers almost always get shorted because they have no control over everything installed inside the infrastructure.
If developers aren’t in the right position to do their job, they’ll waste hours or days with many issues.
This is a perfect example for understanding the drawbacks infrastructure-driven monitoring tools can create for software developers.
Code-driven monitoring tools
Code-driven monitoring tools instead provide a software library you can install and use like any other application dependencies.
The idea behind a code-driven monitoring tool is to create a monitoring environment specifically designed for software developers while avoiding any server or infrastructure configuration that they detest dealing with.
This technical difference (relying on an application library instead of an agent at the server level) has many implications for the ability of software developers to quickly identify bugs and bottlenecks within applications, before they become down times.
Thanks to a tool that can be installed, configured, and customized without depending on any external team, developers will be able to quickly identify and solve problems.
They can do so:
- With no interaction with other teams
- Without endless tickets or email exchanges that are bounced around multiple levels inside the company
- Without delays for customers
Making sure the software development team can work quickly and independently is critical to having:
- Fewer bug reports
- Faster bug fixes
- More happy customers
One of the most important things customers happily pay for is to “have no problems”, right.
As you can see a code-driven monitoring tool is versatile.
However, don’t just trust this article.
For several months, Valerio gave talks and solicited feedback at events in the Italian PHP community. He also discussed the issue extensively with other CTOs. On this page he collects reviews and comments from developers who have tried Inspector. You can also view several presentations he gave.
Try Inspector for free and as long as you want
To let everyone interested try this new solution, Inspector offers a free tier with up to 30,000 monthly transactions. And it’s not a limited trial. Consequently, you and your team can get familiar with Inspector without the pressure of a deadline.
There is also a referral link for this article. Use the link to get an additional 50,000 monthly transactions. Register your account to start with 80,000 monthly transactions for free.
Try Inspector today
I hope you will try and enjoy the Inspector experience.
If you found the article useful, please share it with others who could benefit from Inspector.
This article originally appeared on Inspector.dev and was written by Valerio Barbera. I have made slight edits to it to meet the standards and formatting of Symfony Station. All sponsored posts are for products we have vetted and stand behind. We either use them or would do so if they were applicable to this site.
Top comments (0)