MaltaToday previous editions

MALTATODAY 1 September 2019

Issue link: https://maltatoday.uberflip.com/i/1161926

Contents of this Issue

Navigation

Page 47 of 55

TECHNOLOGY maltatoday | SUNDAY • 1 SEPTEMBER 2019 16 Ing. James Attard, B.Eng(Hons), MBA(Henley) DEVOPS, a term coined in Europe back in 2009, is a set of software development practices that aims at bridg- ing Software Development with Information Technol- ogy Operations. DevOps goals DevOps goes hand in hand with several project man- agement practices such as Lean and Agile and they share similar goals. These include: 1. Increased frequen- cy of software deployment 2. Increased velocity in deploying software fea- tures to the market 3. Decreased software errors and bugs 4. Shorter time to re- cover from software failures DevOps Benefits In a recent study conduct- ed by Puppet Labs and the DevOps Research & Assess- ment (DORA), it was found out that organisations that adopted DevOps practices, have not only reached the above goals, but directly experienced a greater com- petitive advantage com- pared to their peers (Figure 1). MITA approach to DevOps MITA is currently transi- tioning towards a DevOps culture. Before rolling out its DevOps strategy, we embarked in an exercise to identify which DevOps practices yielded the most value. The approach was based on a very well-known model known as CAMS, referring to the Culture, Automation, Measurement and Sharing dimensions of the DevOps journey. Using this model, we based our DevOps vision on the idea to foster a cul- ture where we all respect each other; optimise and automate our processes to reduce the likelihood of er- rors; measure and improve every process; and to dis- seminate lessons learned, collaborate and share ideas. In this regard, MITA has setup a team of specialised architects, known as the DevOps Working Group. Having this type of organi- sational structure ensures an effective change catalyst and a closer alignment with the Agency's strategy. Our DevOps strategy is made up of five different phases, as defined below. These phases are not linear per se` and most of them spin off in parallel as re- quired. First Phase: Enforce Version Control Practice Version Control refers to the principle of having soft- ware source code and in- frastructure configuration stored in a central reposi- tory that allows tracking changes, accepting changes to go to release cycles, and to allow collaboration be- tween multiple teams. Version control has been enforced at MITA for a number for years, at least from a software perspec- tive. Given the opportunity given to us through the hy- brid cloud to utilise infra- structure as code, the same version control rigour will need to be applied. This is a fundamental stage, because failure of executing it successfully will warrant failure in the overall DevOps strategy. In this phase it is important to define and disseminate a common set of technology practices and re-engineer business processes that al- lows teams to work together and that allow change man- agement practices, such as ITIL, to work in tandem with Agile processes. Second Phase: Define a standard technology stack Having a converged and harmonised technol- ogy stack not only reduces variability and complexity, which in turn reduces or- ganisational cost, but also helps at enforcing govern- ance and infrastructure sta- bility. For this phase to be suc- cessful, both developers and operations should meet regularly to come up with a common set of tools and technologies. While the choice of tools is important, our ethos is to focus on prac- tices rather than the actual choice of tool. This is to help us be technology agnostic so our business process can plug and play with other tools with minimum effort. Third Phase: Combine change management with DevOps A common failure among organizations that try to adopt DevOps is when they trade off their current change management prac- tices with DevOps, or per- haps, give up on DevOps methodologies because they struggle to see where it fits in the Change Manage- ment process. The actual reality is that Change Management prac- tices, such as ITIL, have evolved and can be eas- ily used in tandem with DevOps principles, such as Agile. The idea is that within development and staging environments, the software development and IT Oper- ations teams should adopt DevOps principles such as Continuous Integration and Continuous Delivery, to deploy frequently and in shorter times, and without manual approval. Once the code is ready to be deployed to live envi- ronment, the Change Man- agement process kicks in and a manual approval is required, along with other processes, as stipulated in an ITIL lifecycle. This two-stage process guarantees fast releases without compromising on governance and control. Fourth Phase: Infrastructure as a code This phase goes hand in hand with the previous phases and in fact, kicks off as early as the first phase. The aim here is to treat in- frastructure configuration and provisioning in the same way we traditionally treat software code. Therefore, all the previous DevOps principles apply – from version control, to continuous integration and delivery. Moving towards an Infrastructure-as-a- Code (IaaC) mindset allows us to automate orchestra- tion of infrastructure sys- tems. Given that at MITA our infrastructure is increas- ingly moving towards the Cloud, it is more intuitive to treat infrastructure as a set of lines of code. We are also moving towards a mi- cro service approach where even client services can be treated as code. The advantages are sev- eral – from guaranteeing repeatability and predict- ability, hence reducing hu- man errors; to simplifying QA testing processes. IaaC further provides a gateway towards more advanced concepts such as AI based self-healing architectures. Fifth Phase: Business processes engineered for self- services Once all the previous phases are fulfilled, the or- ganisation will naturally incline towards providing end-to-end self-service ar- chitectures. Most bottle- necks are removed – prod- uct teams can orchestrate infrastructure, and opera- tion teams can automate builds. Work becomes less mun- dane, and manual work re- duced. Engineers can shift their efforts from servicing customers to innovating and building more creative services. Conclusion Moving towards a DevOps culture was a necessity to improve our services and to keep up with today's fast-paced, challenging de- mands. This article focused not only on the technical approach but also on the cultural aspects implied that one must keep into consideration, especially for a complex and mission critical agency such as MI- TA. The efficiencies and im- provements MITA will gain after having com- pleted its journey towards fully adopting a DevOps approach will effectively translate into a better user experience for all the citi- zens of Malta and Gozo. The MITA DevOps Journey Ing. James Attard is a Senior Solutions Architect (Infrastructure Services Department) Figure 1 - State of DevOps Report (Puppet Labs, 2016)

Articles in this issue

Archives of this issue

view archives of MaltaToday previous editions - MALTATODAY 1 September 2019