paint-brush
Ten years of DevOps. What changed?by@oleksiidzhulai
1,866 reads
1,866 reads

Ten years of DevOps. What changed?

by Oleksii DzhulaiOctober 3rd, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

There are lots of discussions, talks, white-papers and books available about DevOps which coalesce around delivering software faster, more often and reliably, breaking down walls between development and operations.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coins Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Ten years of DevOps. What changed?
Oleksii Dzhulai HackerNoon profile picture

There are lots of discussions, talks, white-papers and books available about DevOps which coalesce around delivering software faster, more often and reliably, breaking down walls between development and operations.

The shortest and high level definition, which I find the most accurate, says:

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality

DevOps: A Software Architect’s Perspective

DevOps came from world of web giants like Amazon, Google, Facebook and is endemic to the world of cloud and distributed systems. It’s almost a decade has passed since this term was first mentioned and gained wide adoption. Has anything changed since then?

Infrastructure as Code is requirement and not an option

This became true for anything bigger than a prototype. Even small apps consist of numerous micro-services, integrate with 3-rd party systems and it’s quite rare to see a deployment of a stack or environment which takes longer than couple of hours, considering all the available to modern developers toolset. Today, infrastructure management is a matter of writing software. This software cannot be developed in isolation and then handed over to operations team, dev and ops team should work together and apply all known SDLC best-practices.

Continuous Deployment becomes easier

In addition to mature culture and experienced team, delivering a change to production continuously, assumes 100% of automation in areas of workloads orchestration, pipelines, quality gates and monitoring. Taking into account availability of cloud PaaS options and contribution of industry pioneers to the tools like Spinnaker and Knative, continuous deployment became something available out of the box.

Cloud adoption

Cloud computing is focal for DevOps evolution. It raised roughly at the same time was the thing which blurred the line between development and operations even more. It’s tricky to develop for the cloud without having understanding of operations, at least at application level, and you can’t operate without automation. It’s all about software practices! Cloud has grown from a choice of startups to an enterprise mainstream and it is number one priority in digital transformations. Today, fear of cloud computing is gradually moving towards “cloud first” strategies.

DevOps ecosystem is enterprise ready

Cloud Native development becomes mainstream. For example, CNCF which was founded in 2015, already includes around 600 opensource projects and is the fastest growing ecosystem ever! And yes, DevOps engineer and SRE are in the list of most popular job descriptions.

The Myth about NoOps. Do I need to operate serverless?

Cloud native stacks are designed with high availability, scalability and self-healing automation in mind, environments become more “clever” but more complex at the same time. This allows to shift focus of operations from reactive firefighting towards predictive maintenance and continuous improvement of automation. As a result, operations function don’t disappear but instead becomes more effective and can manage much larger infrastructures.

Culture vs Tooling

Using PaaS or implementation of a fully automated delivery pipeline doesn’t mean we’re practicing DevOps. Automating big legacy stacks is obviously rewarding, however, we end up doing big chunks of change at a time with side effects such as complex coordination, low speed and quality. Cultural change is required here in order to rethink and optimize old ways of working

At the same time, it’s a mistake to disregard tooling in favor of culture and process. Doing something continuously, fast and reliably, assumes minimizing human factor in the chain. DevOps is about automating and reusing expertise, that’s where tooling is crucial, so it’s about a balance!