DevOps, this way, please...

DevOps has been in practice for a long time; however, the implementation and ROI have always been unclear. In this article, I am sharing our experiences in DevOps with a broader audience; this should help in opting for DevOps.?????

?In one of its strategic call, TomTom realized the need to ship peripheral solutions to enhance maps, apart from delivering digital maps. Therefore, we targeted our workflow, a project management application. This application, developed in Java, enables project managers to track E2E map-making projects. This can track the cycle of production & various quality stages of each change in a real-world road network.

?However, this application, too, had the shortcomings of an internal application, including:??????

• ?A monolithic application????
• Lacked various security checks, for example, cross-site scripting, OWasp, etc.,
• Longer deployment - greater than 3 weeks,
• Generic application with difficulty adapting for specific project needs. If it could adapt, it proved to be an overhead for other projects,????
• Reactive improvements, driven by end-users or bugs
• Operational instability leads to productivity losses and added pressure on the team

?The figure below is the original overview of its accessibility to end-users.

Considering these challenges, the technical architect decided to target the application in a phased manner. ?

Firstly, we decided to break its monolithic structure into the loosely coupled (Modular) service-based platform with a modular structure. This enabled us to achieve better code management, which was key to dividing the work & target the technical debt. Whereas, each module can be deployed independently in the case of any change rather than the entire application. With the “platform,” we aimed to make it available for other applications to connect and adapt to it as per their needs. The team invested a few months in building the application, a platform for ‘projects’ and its subtypes. By loosely coupling all standard functionalities, it eased the development and stabilized the deployment. It also paved the way to customize the application without impacting other projects or subtypes.

?All functionalities were broken into services, making it the perfect platform to seamlessly connect with other applications across issue tracker or project management tools like JIRA, CRM (e.g., Salesforce), ERP (e.g., SAP), or any in-house developed application.

?Secondly, by adopting the ‘Think Left Strategy,’ the team was able to target token management (JWT), XSS, HTTPonly protocol, and several other functionalities to make the platform more secure. To handle them there are multiple solutions & team has to really undergo good brainstorming as well as prototyping to see the benefits coming out of it. Test engineers played the key role in comparing the prototypes and finally deciding on the best solution with matrices of test results.

Thirdly, to improve the code quality, through the process, continuous code inspections were ensured through Sonar, where code coverage was kept at about 90%. The code coverage was achieved through Junit. The team also moved all test cases to Selenium, which was previously developed in Jbehave. The advantage we found after moving to Selenium was:

• Greater stability and a predictable pipeline
• Allowing developers to participate in the automation of test cases development because of its vicinity to Java.

?Fourthly, we also moved the development script to ‘Chef’, from ‘puppet’, where both deployment and rollback strategies were handled in this script.

The figure below depicts the latest overview of how the application is perceived by end-users.

?A highly skilled team with technological acumen could achieve the goals as there was no dependency on any specific individual. This must be attributed to these evolved practices:

• ?The team was empowered to make a decision and choose the technology or approach
• All decisions were made on confluence, where they shared multiple solutions along with their pros & cons (brainstorming sessions were conducted on each topic, and decisions were made accordingly).
• All source code, configuration scripts, database schema changes (Liquibase), etc., were now available on (GIT) repository.
• To minimize the effort in technical documentation, swagger was used for APIs
• Decisions related to the improvement were made meticulously on error logs, Tableau, page rank value of application

?Monitoring: Multiple monitoring tools are used to check the health of the application. Initially, the team began with ‘Appdynamics’ but later moved to open source tools like ‘Grafana’,’ Kibana’, and ‘Thruk’. More recently, the team has also been using ‘Nagios’. As new sources of information came to light and meticulous decisions were made to improve the application:

• The team continuously reviewed the errors, reported them in the monitoring tools, and fixed them in the application, based on the priority set in bug triage
• Event tracking through Kafka: The team was able to measure the time taken in events and target the slowest or most frequently seen events for improvements
• Gemba walk: The team frequently visits end-users to monitor how their application is being used and reports cases for any improvements or fixes needed
• Process-orientated RCA: Any issue that occurred in the production besides fixing it invoked relentless root cause analysis, and corrective action was institutionalized. All this was focused on processes rather than people. All findings & corrective actions were automated & they were documented on confluence.

?With all these changes, the application is continuously being deployed on-demand, and if required, multiple deployments can be made in a single day.?

?Key values of DevOps implementation, which directly & indirectly boost the confidence of the team are:

• Not focusing on the non-functional requirement, instead focus on technology and functional requirement
• The team doesn’t have to extend their working hours because, in most cases, they are proactive (i.e., timely log-based decisions were made using monitoring tools).
• The whole team got the opportunity to work on each aspect of E2E releases because of job rotation
• The team was encouraged to bring new ideas, and they received appreciation in retrospective calls along with the go-ahead for implementation, only if applicable
• There was the negligible or minimum dependency on an individual due to job rotation as everyone was made aware of everything needed to execute the project
• No repeated jobs, anything that was repeated was automated.
• End users were overwhelmed as they were getting immediate feedback (if it’s good to implement or not) or releases for any improvement they requested. The success of this project was visible, with the end-users voicing their appreciation for the team.
• Team spirit remains high & attrition rate was almost zilch.

So, whenever kicking off a new project, following the DevOps principles from day one, will help your project to be sustainable in the long run. Whereas implementing them in the existing project will be tedious initially but keeping the above points in mind it’s worth going for. Concerning money, going with DevOps will always be an additional cost in the beginning & also elongate the development cycle but its payback period is immediately after implementation.?