What is Continuous Monitoring (for developers)?
This is a guest post written for the Computer Weekly Developer Network by Eran Kinsbruner in his role as chief evangelist for Perfecto.
Acquired by Clearlake Capital-backed Perforce in October 2018, Perfecto is a specialist in cloud-based automated mobile and web application test software solutions.
Kinsbruner reminds us that in the era of Agile and DevOps, organisations have to accelerate the delivery of value [through working, valuable, effective, productive software] to their customers — and they need to do it quickly and at high-quality.
The upshot – or direct corollary – of this reality is that implementing continuous testing processes and reducing the number of software iterations has become more essential.
Put simply, this also drives a clear need for continuous monitoring.
Kinsbruner writes as follows…
The Continuous Monitoring (CM) phase of the DevOps cycle is one of the most important because it continuously delivers real customer feedback from production back to the developers’ workstations.
This provides valuable end-user experience feedback from the app.
Developers implement continuous monitoring (often named Application Performance Management – APM) through either synthetic monitoring or Real User Monitoring (RUM).
Synthetic monitoring
Synthetic monitoring is when the team builds a ‘production-like’ environment that mimics the production environment as closely as possible.
Against this environment, developers execute test automation code (through the scheduler) that is connected to an alerting dashboard e.g. Splunk.
The main disadvantage of this method is that this, by design, is a ‘synthetic’ rather than ‘real user’ environment.
This can result in issues being missed, particularly in mobile apps that are specific to unique devices and environmental conditions.
RUM
Continuous monitoring via RUM is done via an SDK or an agent that is a piece of code bundled within the application in production.
This code continuously sends metrics and other important properties from the app back to the monitoring dashboards.
The advantage of this method is the unlimited coverage that developers get from the real user environment.
The risks include security – as this code acts like a backdoor from the app to the developers’ machines, reduced application performance due to the additional payload added to the app transactions by the SDK… and compliance with global regulations such as privacy.
Triggered CI jobs
With both approaches, DevOps teams automate key business transactions that are executed through triggered CI jobs – a few times a day or even hourly.
If an anomaly appears in the results of the continuous monitoring tests, an alert is thrown and sent back to a monitoring dashboard notifying developers about its severity and in some cases the root-cause of the incident.
They also enable Dev and Ops teams to tune their production environment during peak usage and / or other unique market events.
