Trending in today’s software development world is the DevOps culture. No more are monolith apps being developed with reams and reams of code. For the progressive developers of today, DevOps has become the way to work.
A dialogue often heard in tech companies that develop apps is:
Operations team member: “Oh no, the server is going down! We need to roll back the updates they just sent us. Who writes this code anyway; don’t they test it beforehand?”
Development team member: “Hey, we wrote the code and the QA team tested it to confirm it works in both our environments. The problem is likely with your deployment process and not our code!”
You can well imagine this scenario recurring at any one of the thousands of tech companies building to-scale products that serve millions of users. The bigger the code base, the higher the likelihood of bugs and the more challenging the road from development to production. While unit-tests play a significant role in the process, it is evident that communication plays an equal or greater role, especially in resolving sensitive situations that can otherwise go awry for the entire team. In such cases, the adoption of the DevOps model becomes inevitable. Essentially, this is the team that bridges the developer-operations gap. The purpose is to aid in shortening the systems and software development life cycle whilst continuing to deliver features, updates and bug fixes frequently and in close alignment with business objectives.
Why has DevOps become popular?
As the Amazon Web Services explanation goes, DevOps is the combination of cultural philosophies, practices and tools that increases an organisation’s ability to deliver applications and services at high velocity, evolving and improving products at a faster pace than organisations that use traditional software development and infrastructure management processes. According to Webopedia, the goal of DevOps is to change and improve the relationship between the Dev team and the Ops team, by advocating better communication and collaboration between these two business units.
In some ways, DevOps started as the introduction of some much-needed sanity in navigating the quagmire of enterprise-scale software. The idea was to take products from being ‘in principle’ to ‘in practice’, dealing with hordes of issues and putting out all the fires that are lit along the way. DevOps deals with a mix of culture, practices and pipelines. It moves from traditional software development, followed by deployment and then blends both, hence ironing out the kinks that usually occur on account of communication lapses and, in general, entirely disparate processes.
For these reasons, DevOps now plays a growing role in many organisations. Adopting DevOps is usually well-compensated since it deals with a growing skillset and expertise in cross-domain topics. Typically, DevOps engineers are either professionals adept in systems and networking, and are inclined towards more of development; or they are software developers that are drifting towards the systems administration end of things. Ultimately, the roles and responsibilities focus on the management and automation of production-ready microservices.
The growing popularity of DevOps
Figures from DevOps Zone (dzone.com) state that:
- In 2016, 66 per cent of global organisations had adopted DevOps, 19 per cent had not adopted it, and 15 per cent had not yet decided.
- By 2017, 74 per cent of global organisations had adopted DevOps, 16 per cent had not done so, and 10 per cent were undecided on this topic.
In 2018 and 2019, the popularity has only gone higher as illustrated in Figure 2. It is interesting to note that there were some dips in popularity right before DevOps shot back up, making the case for further analysis that might uncover a pattern associated with this rise.
DevOps demands a delicate balance and is fairly complex to introduce. An explanation based on experience by the team at Turbonomic (turbonomic.com) claims that there are two components to a DevOps model — having the right tools and the right culture. This analogy claims that implementing DevOps is a lot like rowing a boat! You can have the lightest shell, the best oars and the strongest men but if everyone is out of sync, the speed is lost. And the opposite holds true too — if everyone is collaborating and working in unison but the boat is heavy, the bottom has a few leaky holes and the oars are badly designed, you can’t go as fast.
Reports by Puppet Labs and by DevOps Research and Assessment firmly establish that it is the cultural changes that are needed for DevOps success. Teams find that this is what delays the process and makes it more difficult for organisations to implement DevOps across multiple verticals. These are the practices that require broader organisational input and support to get things right. Ultimately, everyone needs to share the responsibility for the Quality of Service for a product, and if all teams share a role in an application’s performance, then it will kindle collaborative efforts. DevOps tools, like repositories, build servers and orchestration, help to speed up all three phases individually (build, test and deploy) but don’t tie them together.
Site-reliability as a DevOps role
DevOps is more of a culture then a concrete formulation that can be described by a set of requirements, skillsets and deliverables. The question then is what can be an apt formulation of DevOps roles — which brings us to site-reliability engineering (SRE). This term clearly states that it is an engineering role, while the responsibilities include a broad array of tasks aimed at ensuring the product in question remains online and functions as originally designed. There are nuances that separate site-reliability from DevOps, namely, fine-grained responsibilities that fall into different buckets not directly lying under the DevOps umbrella. Some people argue that DevOps has more to do with automation and is often a placeholder used to hire sysadmins ‘with bells and whistles on top’, while SRE has a lot more to do with availability and scalability of software. Broadly speaking, SRE and DevOps do have a lot of similarities and remain closely related to one another.
Obviously, DevOps is not a one-stop solution to all the problems that are production related and there is a huge team effort usually involved in getting a product right. There are a ton of components introduced in pipelines due to DevOps recommendations that cause some pain to transition into, but for teams looking to build real-world products, it is critical to get the foundation right so the building is able to weather harsh storms. This is the DevOps decade, all the way!
