Born out of the difficulties of a challenging data migration project and getting siloed teams to work together better, DevOps has evolved into a movement to facilitate software development and its implementation, while improving reliability and increasing security.
While the process of combining teams is hardly seamless, when done successfully, DevOps delivers significant benefits across businesses whether they are large or small.
DevOps combines the words Development and Operations, with the term originating in 2009 and attributed to Patrick Debois, who is widely considered the ‘Godfather of DevOps’ and is the founder of the popular DevOpsDays conference.
Debois’ philosophical approach to software development and operations grew from his experience the year prior with a data migration project for the Belgian government, where the project developers and the system administrators were simply not on the same page. After this, Debois created the aforementioned conference to share this experience, and a movement was born, which came to be known by its still popular Twitter hashtag #DevOps.
Linguistics aside, DevOps goes by various definitions, and in the end, is just a little different at any given organization. In general, DevOps is a term that describes a collection of principles, tools and even culture that endeavors to unify the development of software and its implementation in operations.
The goal of this to make an organization more nimble, so that products – like apps – can be developed at a faster pace than software is traditionally created. With DevOps, the usual barriers between the development and operations groups at an organization are completely removed, as these two traditionally separate teams get merged into a single group.
This way, engineers can work on a product throughout its lifecycle, and not just during development to then hand it off to others with less expertise, and less knowledge of what happened in the earlier stages of the project.
DevOps in practice
DevOps runs the risk of becoming a word without meaning as the industry rallies to attribute it to every product and service in their portfolio. The reality is that I can't sell you DevOps, and you can't buy it.
DevOps is more than simply automation. It includes things like culture. It's a way of working that values collaboration with a shared view of success. As the name implies, this collaboration is primarily between developers and operators, but it is not restricted to that.
DevOps means that you see the end to end delivery system from concept to production, your DevOps scope is any group that are involved in that workflow. So if you're willing to make a cultural investment in changing how you work, then you can start to implement some of the working practices that DevOps recommends.
Integrating DevOps
But before you jump head first into identifying work and managing constraints, ensure you know why you want to make DevOps part of how you succeed at IT services. Many successful implementations have been driven by a desire to:
• Reduce time to market for new products and features
• Build more agility to adapt to internal and external influences
• Unlock cost savings offered by cloud platforms
• Eliminate the risk of shadow IT services
Successful DevOps adoptions are easy to spot. They are the organisations that talk about making tens and even hundreds of code releases into production every day, where there seems to be a constant flow of new features to keep users engaged and loyal.
The leaders here are internet giants like Google, Facebook, Netflix, Etsy and more. But whilst many of these grab headlines, there are large numbers of success stories where organisations require internet and web services as a significant portion of their go to market channel.
Is your organisation a good fit?
From the eclectic list above it should be apparent that DevOps is not an exclusive club, anyone can pick it up and try to make positive changes in their business. However, there are some common traits that identify the strong fit candidates for change:
• Existing strong culture of collaboration and open communication
• An executive leadership team who sees IT as a business enabler
• Sponsorship from a high enough level to allow challenges to status quo
• Revenue and brand derived substantially from web and mobile channels
• Established organisations who view internet start-ups as a threat
• Start-ups who want to be more nimble than their established competition
• Applications that are self-built and developed on open technology
All of these provide compelling business drivers to embrace change as an opportunity to create an advantage in your industry. But the transformation will be hard at times and leaders who are sponsoring these initiatives need patience and clear expectations to ensure the team are given every opportunity to succeed.
As with cloud transformations, DevOps transformations will not be universally successful. In fact you should expect to fail at times. The trick is to fail fast, learn and repeat.
Removing fear of failure is important, especially when deep-rooted in a business culture where incident reviews are a blame session rather than a learning outcome.
This is why it is vital that you must commit to the culture as well as the working practices. However, the risk of not addressing DevOps does carry risks itself. If your competition gets faster to market with features and products, what does this mean for your business? If your competition can open up financial advantages by increasing operational efficiency without impacting margins, how will you react?
DevOps adoption should not be driven by fear, but not making it part of your IT plans should be a well-managed risk in your organisation's strategy.
Where to start
So hopefully, you've reached the point where you're interested in getting started. Here are some prompting questions to get you going:
• Which application am I going to build this model around?
Don't do this wholesale across your IT estate. The application and teams around them are key factors in success, identify a candidate application and create a bubble of autonomy around it.
• Can I draw out the entire process from idea to production release?
Simply drawing out your processes is a great way to identify stakeholders and eliminate waste. Never assume you have all the right people in the room in the first meeting!
• Where are my constraints?
The key to increasing flow through a system is to manage constraints. Creating capacity either side without addressing the bottleneck will not increase output. Work out which parts of your system slow you down and improve them.
• Do I have the skills to execute this?
DevOps skill sets are in high demand right now. Take time to understand if you have the right resources to succeed? If you don't, make plans for additional hiring, training, or look to introduce a third party who can help offload some of the core functions.
Integrating security
A key concern with any IT infrastructure is going to be security, and sometimes this gets combined with DevOps - this triple combination gets referred to as a related clipped compound term: DevSecOps.
This integration of several teams contributes to this ‘leaner and meaner’ approach to software development and rollout. Traditionally, software development, and its implementation, has been a laborious, manual-based process which is unsurprisingly sluggish. Today’s ever changing market innovates at breakneck speed, and the advantages go to those organizations that can keep up with this rapid pace – rather than risk the near certainty of being left behind.
DevOps uses tools to speed up these processes, for example, using technology stack and tooling to increase efficiency and reliability in software development. These tools also facilitate the deployment of code, which can be done from within the same team without the involvement of others, and this also contributes to the rapid pace of innovation and deployment of this DevOps model.
DevOps engineers involve themselves with more than just code automation. They also get stuck in with the implementation, which involves their company’s servers, including the more affordable open source operating system servers, including Linux and BSD.
DevOps at work: an example
Now, let’s take a look at an example of DevOps at work. Allstate is a Fortune 500 company, with the origins of this insurance giant dating back to 1931. However, it is hardly nimble, with 16,000 employees, many of whom are out in the field.
The firm’s goal became to get its mobile workforce the latest tools to be able to work with a greater level of efficiency. Simultaneously, there was also a second goal of enabling better self-service for its customers, so that they would be able to make claims, and track them as they are processed.
While cost savings were reportedly the company’s previous priority, with the DevOps approach, the more recent focus has been on customer retention, and differentiated software features. Through the teamwork and common values that are central to the DevOps approach, the company has focused on product development on its app, and keeping it current with the ability to deploy the latest features rapidly.
On the horizon, Allstate also plans to continue using the DevOps approach to implement Internet of Things sensors in customer’s vehicles, using analytics to assess their driving habits. From the significant number of Allstate DevOps jobs currently listed, Allstate clearly continues to embrace this approach.
Speed and scale
With the inherent advantages of speed of deployment, better reliability, the ability to scale, and integrated security, it is not surprising that many organizations have embraced the DevOps approach. Last year a survey of business technology decision makers was used to create the 2018 State of DevOps report. Some useful statistics to highlight include:
- DevOps is popular with a third of respondents already using it, and 35% planning to implement it this year
- A key benefit is faster speed, with 69% claiming benefits of “increased speed and frequency of application deployment”.
While there are inherent advantages of DevOps, it is still a tool that needs to be applied selectively to the correct situation, and there is always the danger that DevOps does not deliver on expectations. However, this is often because the business involved continues to silo its staff and so suffer from departmentalization.
Breaking down silos and combining teams requires a cultural shift; after all, the software development and Quality Assurance folks were on different teams for a reason originally, and they do not automatically share the same skillset just because we push their desks closer together.
Teams do not necessarily want to work with each other, and it takes time for this more modern DevOps approach to bed in, with a healthy dose of mutual respect needed for them to get along towards a common goal, and less concern about which of the former teams are running the show. This type of transition does not commonly occur overnight, at least with most organizations.
Born out of the difficulties of a challenging data migration project and getting siloed teams to work together better, DevOps has evolved into a movement to facilitate software development and its implementation, while improving reliability and increasing security.
While the process of combining teams is hardly seamless, when done successfully, DevOps delivers significant benefits across businesses whether they are large or small.
- Check out the best workstations
