LogSense Blog

See everything, even before it happens.

App Developer Responsibility for Performance & Security

Jul 23, 2019 3:17:15 PM |     Przemek Maciołek, PhD

When we talk about moving responsibility for application performance and security "to the left," we mean that it has to start at the source — that is, with the developer. We touched on this topic briefly during our Inside Perspectives podcast. Application performance and security need to be built into the software from the beginning. Logging and application performance management tools show where there's room for improvement, but if developers ignore them when creating the code, no fix will be really adequate.

The shift in software development

At one time, performance simply meant implementing algorithms as efficiently as possible. While that is still an important concern, today's server environments bring other considerations to the forefront. Containerization and virtual machines run many instances of an application at once. They share resources, and access to them requires synchronization. If the timing code is done badly, the instances will spend most of their time waiting for each other. They can even lock up completely.

Developers have to acquire skills at locking and unlocking resources efficiently. They also need to devise probes that test how the code performs and reveal any bottlenecks. Code written with multitasking in mind will perform much better than haphazardly written code, but only thorough testing will confirm that they haven't missed any sources of inefficiency. The code ought to provide the hooks that facilitate these measurements. Log management solutions can help to optimize your container environment.

Designing security in

Some developers think they can create code that works first and then make it secure. This approach never works well. In fact, it often results in having to rewrite large pieces of the software, which wastes time and resources.

Code with security built in from inception can protect against attacks from intruders. Security-focused software uses well-tested libraries to process inputs rather than checking each item separately. It aborts and logs actions that go inexplicably wrong, rather than ignoring error returns and exceptions. Anomalous events are reported at an elevated severity level.

Automated testing is an important part of built-in security. Individual functions should be tested for handling of erroneous and valid parameters. Testing should involve simulated user inputs, including attempts to exploit weaknesses.

Understanding logging and test points

It's common for developers to add points for logging and testing haphazardly. They start out with none and add them as testers and analysts demand them. In some cases they're afraid that too many logging calls will degrade the code's performance. The cycle of demanding and adding more log points leads to unnecessary build cycles without good coverage.

Done properly, these checks add almost nothing to the time to execute the code. Serious information dumps typically happen only if there is an anomalous event. Regular logging should reside in outer loops, where it builds an overview of what's happening without creating an unreasonable burden. Log management solutions can help developers optimize their build time, particularly intelligent log monitoring that can help assess performance and diagnose problems.

LogSense focuses heavily on making the backend efficient, so that each call has as little overhead as possible. Developers should be more concerned with making the necessary information available than with being stingy with logging calls for the sake of performance. Additionally, LogSense's automated pattern discovery makes it easy for developers to troubleshoot and accelerate application delivery.

Developers and analysts should agree on how to use severity levels. Warning, error, and fatal entries all have distinct meanings and should be used consistently. Logging messages should have a consistent format and terminology. Messages which follow internal standards are easier to interpret and to find patterns in them.

Including relevant variables can add a lot of value to logging calls. An "Invalid URL" message is more useful if it includes the URL. At the same time, they shouldn't create a security risk. Including the mistyped password in an "Incorrect password" log message would be a bad idea obviously.

Coordinating development and diagnosis

The DevOps paradigm aims at making development and maintenance parts of a single, iterative process. Some organizations have pushed it a step further to DevSecOps, bringing security into the loop from the start. LogSense's automated pattern discovery tightens the loop. Instead of having to design specialized searches to pull out useful information, analysts get intelligent summaries of what is happening.

Past experience may have led developers to believe that no one reads the logs, so there's no point in putting much effort into them. LogSense changes the stakes by making logs valuable information sources without requiring excessive manual effort. It becomes more important for developers to determine what data is important and make it available, since it will be used.

Security and performance depend on a good working relationship among developers, testers, administrators, and analysts. When developers think carefully about the information their code provides the rest of their team, products can improve faster and bugs are easier to find and fix.

If you want to learn more about how LogSense can help your development team accelerate application development, with built-in security and performance, sign up for a free trial today.


New call-to-action



 New call-to-action

Want more of the LogSense Blog? You got it.
Subscribe to our newsletter.