top of page

Ways to Bring Quality of Service to the Forefront in DevOps

Updated: Jan 15


DevOps is helping us build beautiful applications in shorter time slots than ever, but the quality of service can quickly become an afterthought in this hurry. We focus too much on the WHAT and neglect the WHY and HOW. The former is critical for our fast-changing business demands, but the latter poses massive risks to our IT landscape. In this post, I will give you some strategies to integrate quality of service into your DevOps chain.


Continuous build, integration, and deployment are the pillars of our fast-forward development approach called DevOps. The central idea is to break down silos and realize new requirements more collaboratively. When developers are in direct contact with business and operations, the communications are highly efficient, and all parties work on a common goal. This approach is the most efficient way to realize software in the 21st century.


Based on my experience, this hurry to push the next big thing into production draws a risk on the IT decision-makers agenda. Low service quality can result in massive rework and frustrated customers.


What is the Quality of Service?

According to Wikipedia, quality of service is related to conditions under which the solution must remain practical, qualities that the solution must have, or constraints within which it must operate. 


Widely known quality of service elements are:

  • Availability

  • Reliability

  • Testability

  • Maintainability


The widely known term for the quality of service is non-functional requirements. I prefer the former because it reflects the importance much better. Talk about quality of service more often, and you will learn that it's very well received. 


How to make Quality of Service part of DevOps?

Start with requirements and specify the whats and the hows. Enrich your documentation with meaningful quality of service requirements. Ask your business teams always about performance and security expectations of new features and describe those non-functional characteristics in your stories. This practice gives your QA teams input for their test cases and makes it easier to decide whether the new build fulfills the agreed requirements.


Design the solution for reliability, availability, testability, and maintainability. Consider scalability; consider how a tester can automate tests and how customers use this new application. Consider uptime and maintenance expectations in your architectural decisions. Right design decisions make the job for your developers easier.


Implement building blocks and keep design considerations in mind because the sooner your teams identify hotspots, the more comfortable they are to eliminate. Validate your architecture, check the communication pattern, set functional and non-functional unit tests in place, and check if your new feature fulfills specified requirements. Educate your developers on secure coding practices and schedule secure code scans according to proven security standards such as OWASP's top 10 to identify and eliminate security issues.


Build new solutions continuously, deploy the latest build on an integration environment, and start the regression. Functional tests are essential, but they are worth nothing regarding quality of service. Set load tests in place that simulate current and future growth patterns. Combine resilience tests with your load test executions to check how safe your transactions fail. 


Break the build for any violation and block deployments if one of those tests identified issues. Set the quality gate to pass if all tests are within agreed thresholds. 


Continuously monitoring how the new system behaves in production when real customers use it helps to address hotspots early. Different data sets, not expected navigation steps, other behavior of interfaces, or invalid input can cause serious problems. The sooner you identify such problem spots, the more time your developers get to fix such issues within the next release. 


Follow this advice, and the chances are high that your next deployment is in line with both customers' functional and quality of service needs.


Keep up the great work! Happy Performance Engineering!


15 views0 comments

Comments


bottom of page