Starting using DevOps: Enterprise vs. Startups

In order to remain competitive, both nimble startups and established enterprises must adopt the most efficient techniques of  value delivery.

Nowadays, DevOps is the methodology that allows allocating the resources optimally to provide uninterrupted service with constant flow of improvements. This article describes the differences in adopting DevOps ideology in startups or enterprise business.

Startups nowadays usually accept this model by default, as it allows them to thrive, ensuring fast and smooth value delivery via cloud-native software. Enterprise business, however, is the whole other thing, as they have stale structure with clearly defined specialist roles and responsibilities, which is great for delivering predictable results within certain workflow and pipeline. The main flaw, however, is the resistance to change, both structural and behavioral. “Don’t change the thing that works” is a motto that worked for quite some time in enterprise business. Well, not any more.

Annual or semi-annual release schedules don’t work any more. If the customers do not get a much needed feature within a month or so, they are quick to depart for an alternative that provides the needed functionality. Thus said, enterprise business has to adopt tighter delivery schedules and faster feedback reaction loops in order to remain competitive. How is it done best? How to transform the structure that resists changes in favor of stability?

How to Help Enterprise Embrace DevOps?

There are three major areas of effort concentration in order to help enterprise specialists adopt DevOps:

• Instating Centers of Excellence (CoE). COE is a group of professionals that operates separately from established Development, Operations and QA departments. It must include both internal talents from all of these departments and external experts in DevOps. Such a group has to receive separate funding and have a separate schedule of work on a standalone project. This will allow dropping the established practices and embracing the DevOps approach, where all specialists have decent understanding of all of the process stages and work interchangeably.
  From the idea evaluation and all the way through writing, building and testing the code, releasing the product, maintaining and updating it, gathering feedback and running all the process anew until finally retiring this software — “you build it, you run it” is the core message of DevOps paradigm. After taking part in such COE project and experiencing the DevOps benefits firsthand, enterprise employees become the visionaries and promoters of further adoption of this methodology across the enterprise.
• Splitting the software structure to microservices. When instead of complex products that require large teams to develop and maintain you utilize a set of intercommunicating microservices using API to exchange data, the speed of development drastically increases, while delivering high-quality code.
  When a rather small team of interchangeable DevOps specialists is responsible for a separate microservice, there are less bottlenecks within the software delivery pipeline, as any available team member can devote their effort to solving the issue at hand, be it writing a code, testing and deploying it or solving the customer’s support request. This works contrary to usual enterprise workflow, where operational overhead in one department can put the work of all the other departments on hold.
• Building  infrastructure as code. Instead of siloing the responsibilities, technologies and tools between Development and Operations departments, DevOps combines all the processes. This means the developers do not consider their job done once the new software build successfully runs the tests and the operations engineers do not manually set up the environments for deployment. All processes involving infrastructure can and must be automated, using the tools like Puppet or Chef for configuration management and rapid allocation of the needed resources.
  When all the processes are automated, every DevOps team member is able to use all the tools and can write the code, run the tests, build the new app version and push it to production with several strings of code or clicking several buttons in DevOps tools of choice.

Starting using DevOps requires certain effort both for enterprise and startups. However, it really pays off in the long run. It’s much better for a startup to begin working under DevOps paradigm from the very beginning, to avoid gaining technical debt and losing the momentum once the need for automated testing becomes obvious and unavoidable. For the enterprises, the choice is even more simple.  Adopting the DevOps methodology is the question of survival and nobody wants to become extinct. Evolve or be left behind.