One of the current trends in software development is a strong push towards DevOps. As a concept, DevOps has been spoken about for nearly ten years. Teams, big and small, old and new, are rapidly evolving to incorporate a mature DevOps process. The general benefits from this are frequent deployments, reduced complexity, and more stable operating environments. In simple terms, the DevOps way is a means to co-opt, as opposed to isolate activities pertaining to software development, release, and monitoring.[1]
DevOps is an operating procedure for engineers, and software development teams. DevOps could also herald a change in culture. It needs buy-in from individuals who wish to participate. It aims to reduce dependencies, and improve stability. Adopting DevOps could mean a change in tools that are required by engineers to be able to embrace this change. System Reliability Engineering (SRE) is a similar concept.[2] The broad definition of the categories of activities for teams adopting DevOps is – Code, Build, Test, Package, Release, Configure, and Monitor. There is an alternate with a slight variation – Plan, Create, Verify, Package, Release, Configure, and Monitor. But, the common denominator is to build software, release it, and monitor it continuously.
Within DevOps teams, in the initial phases of building software, there is predominantly “dev” work done, and in later stages, it shifts to more “ops” responsibilities. The codebase spans both these areas, and facilitates both flavours of activities, which is where the unification comes from. Tools that aid development include version control, and CI-CD pipelines. For the code developed, release includes artifact repos, staging servers, and infrastructure. Once released, numerous monitoring tools are attached to track the performance of the software and provide feedback.
Authors of The DevOps Handbook note that there is a marked absence of rapid feedback within the larger technology domain.[3] There is an urgent need for transparency in the interface between users and software. This is especially relevant, as engineering teams begin to adopt a DevOps mindset. There is more responsibility shouldered by engineers, and this requires additional support. Tools that can observe usage of a product, and provide information about the application in the context of usage becomes a need. The success or failure of adopting DevOps, like all other practices, depends on how well teams mature in their adoption of these toolsets.
The best feedback an engineer can get is from users. Irrespective of what responsibilities they have or which parts of a system they are responsible for, the ultimate goal is satisfactory user experience. The better teams get at improving user satisfaction, there will be an upward trend in usage, growth, traction, and revenues for a user-facing software product.
With Plumbr, we aim to introduce a mature way of communicating application performance – by monitoring how real users interact. Based on the behaviour of the app, when it responds to usage, we allow engineering teams to make decisions about product behaviour. Pointing to parameters such as power, compute, network, bandwidth, and storage does not capture the context of how users feel. And we’ve written before about the awkward conversations that ensue. Parameters such as latency, availability, and throughput gain immense weightage when observed together with user behaviour. The magnitude of failures and slow responses is only tenable when viewed in the context of usage of an app.
With Plumbr, we invite you to introduce a sophisticated DevOps toolchain with real-user monitoring within your organization today!
[1]What is DevOps?, Mike Loukides, June 7, 2012
[2] Chapter 1 – “Introduction” (DevOps or SRE?), Site Reliability Engineering: How Google Runs Production Systems, O’Reilly Media, Incorporated, 2016, ISBN 9781491929124
[3] Chapter 3 – “The Second Way:The Principles of Feedback”, The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, IT Revolution Press, 978-1942788003
| Published on Java Code Geeks with permission by Ramanujan Iyengar, partner at our JCG program. See the original article here: Real-user Monitoring in a DevOps Toolchain Opinions expressed by Java Code Geeks contributors are their own. |
