I recently attended DevOps days at Les Fontaines (Capgemini University in Paris). The key reasons were to understand some details of this buzzword and how it may impact me as an engineer and my existing clients. Being an engineer, my expectation was that it would be some sort of tool set or process that will speed up the delivery through automation.
What I learnt was that it is not just about the tools and there is no cookbook yet. DevOps is not simply about buying or using a toolset. Actually a good engineer has to persuade the client not to jump to the toolset upfront for the false impression of buying into DevOps. It is worth adding that Agile and DevOps are related concepts but not the same. A typical journey towards DevOps assumes an Agile mindset is in place. Equally, DevOps does not mean forgetting about compliance with standards such as ITIL etc. Before sharing my understanding of DevOps definition and how it may impact me, it is worth noting why CIOs/CTOs are asking about DevOps.
My Understanding of Why Companies Are Looking Into DevOps
Increased expectations of great personalised user experience is one of the key reasons that is driving the need for speed. As a consequence, every company has become a customer company, every company has turned into a software company and every company needs development speed and agility like Amazon or Google. Therefore not only do the engineers have to learn it, service providers (as a whole company) need to understand it and the customers have to make an informed decision to embrace it.
As Andre Cichowlas, Capgemini’s head of Group Delivery, puts it, “new ways of delivery in the cloud are changing the game and DevOps appears as a best fit enabler to leverage this delivery model”.
Out of many success stories shared at the event, one was of a mission-critical enterprise level system. By adopting a DevOps culture, the delivery time was improved to 27 times faster and the team was reduced from 45 people to 15, most of whom were engineers.
DevOps In My View
DevOps is defined using multiple aspects, for example:
DevOps is about being agile to be closer to the client and being more responsive to their needs.
DevOps is about changing mindset, finding value, removing waste, automating wherever possible.
“A cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.” Viktor Farcic – Docker captain & DevOps author
But the one aspect that stuck in my mind was that DevOps is about transforming organisations by combining the organisational team’s efforts to become more centric to the end customers, for example development and operation teams working together as one team with no barriers. Although people may use a different buzzword, please also allow me to extend collaboration by adding business (both client and service provider) teams working together with development and operations as one team. By one team I mean, absolutely no boundary restrictions between people i.e. no more throwing stuff over the wall.
Why should I embrace DevOps as an engineer?
There is no doubt that engineers are the key people of almost all organisations as “software is eating the world” - Marc Andreesen and “engineers will eat your organisation” Gideon Zondervan - Capgemini. While clients are leveraging or planning to leverage Cloud (Public or Private) to enhance speed, efficiency & elasticity, engineers are required directly to work with the business to experiment with an app without long analysis, test and deploy it. If successful, then they have to support it while working on some new experiments.
To support such disruption models, engineers need to give up the traditional mindset of receiving elaborated specifications and leaving it to the QA team to identify any functional gaps or leaving the task of deployment and maintenance to the Ops team. Engineers are required to churn unstructured and un-elaborated requirements into scalable Digital Applications. Engineers have to leverage intelligent automation drive to translate automation technology into a business value. Equally, engineers have to embrace the mindset of an operations person in order to act like a Business Agility Team member. Without such knowledge, one may remain confined in the borders of the development. In essence, engineers are the analysts, testers and support team members and DevOps and cloud are supporting such model.
A concrete example is of a decent size UK based engineering firm (21,000 people), who handed over the contract of maintaining its intranet to a small company (six people) and of them only two people support the whole of their intranet (hardware, software, website, web apps, load balancing, fail over, high availability, monitoring etc) using AWS. Adding more to the surprise, they are not full time on this client, they are managing many more.
Another example is of a large public sector department who migrated to shared service infrastructure about 3 years ago. It needed two partners to work together with the client for more than four weeks to provision hardware, software and web apps, involving a number of analysts, developers, ops people and project managers in the exercise. When an engineer who worked on it was exposed to the DevOps mindset, with help of AWS, he was able to set up 70% of the whole environment, as it excluded deploying application etc, in about 3 hours. No analyst, no ops, no project manager and time was reduced from about 4 weeks to 3 hours. It is an example of least delays, least handover and fastest validation.
A more recent example is of a public sector client whose supplier is struggling with maintaining and extending an existing complex web application. Structured around more than 12 subunits, they requested service providers for a complete package (business consultants, project teams, operations teams and all environments) that revolves around business function. Such customer-centric proposal would have been very difficult without the whole team adopting to the DevOps mindset and would be even more challenging if engineers resist to land into this arena.
In terms of skill set, engineers have to move away from the I-beam profiles (for example Java developer, front end genius, Oracle expert) as it becomes either a bottleneck or overcapacity on that skill. Typical T-shape profiles (for example, Java specialist with some knowledge of other languages) for task sharing and productivity may soon become history. Engineers may need to start embracing π-shape profiles (TestDevs, DevTest, people with two badges), by removing critical specialist dependencies. Although almost impossible, the next probable step points towards moving to an ideal square profiles (multi-specialist). However it is likely to cost much more development and training time; not to mention that it would be too hard to stay up to date with all skill sets.
In terms of design and development, engineers have to leverage business feature driven development to align it more around the moving parts of the business to support agility. It may require leaning more towards adopting microservices in order to build, scale, and deploy smaller loosely coupled services by leveraging DevOps to deliver business value. For example, a client required the service provider to build a dashboard along with the web app to show how much money business is making or losing for each key component of the application. It would have been very difficult to achieve it without having a microservice architecture.
In terms of support, compliance will become a more important aspect for engineers as they have to understand it in order to comply with it as they are the developer as well as the operation. There is no separate ops team, and as a consequence, it cannot be delegated. From an automation perspective, DevOps would be how to make it more robust, for example by automating compliance aspects. We have to be innovative within the bounds of the compliance of the industry.
Some High Level Steps Towards Adopting DevOps
For engineers, DevOps starts with the mindset and what a DevOps engineer can bring into the organisation. Tools are only enabler of achieving the DevOps mindset and can vary for different settings like Confluence, Jira, Chef, Puppet, Jenkins, URlease etc. However, like anything else, you should not start your DevOps journey without a plan. One way to start is by thinking of how to achieve the following:
Person
- Work as one team with shared goals and responsibilities
- Focus on delivering customer value and business goals
- Build high trust, collaborative environment
- Value communication, knowledge sharing
Process
- Drive towards smaller, more frequent releases
- Think components, microservices end-to-end
- Maximize flow, manage constraints
- Enable fast feedback and foster experimentation
Tools
- Standardize
- Make it modular for re-use
- Automate everything!
- Systematize feedback
For companies, the journey starts with forming customer centric teams. Teams need to go through stages of being comfortable with agile ways of working to continuous integration and delivery to mastering cross concerning skills. It can start from being a project team that turns into a product team or value stream. Companies like Capgemini provide a framework for transforming to the DevOps that includes a Maturity assessment model and a road map.
Conclusion
In summary, DevOps adoption is about people, process and technology. Businesses need to adopt it to avoid being a historical brand while acknowledging that transformation may vary to different speeds depending on team, organisation and application maturity.
The key message for myself as an engineer is that as I have to be more open to the change by accepting it rather than sticking to a developer mindset who cares less about the pre and post implementations stages. Engineers have to be more involved in the end to end lifecycle. Engineers have to act as a member of the Business Agility Team that drive the change, implement it, brings it to the life and supports it. In other words, we are expected to discover and assess innovative technology and processes, support them through proof-of-concept and industrialise and harden them in the operating models.
Within Capgemini, this has already been started by training engineers to develop a π-shaped skill profile along with embracing a DevOps mindset.
As engineers, we have to embrace this new career framework and align personal ambitions accordingly to avoid eating the dust by being the disrupter and not the disrupted ones.
