Why many startups are doing DevOps wrong

We’ve seen multiple startups begin using configuration management tools like Chef and Puppet and being sure they are now fully DevOps-powered. Alas, this is not fully true.

As we have explained in our recent article that demystified 5 popular myths of DevOps services, adopting DevOps is quite different to buying new tools, automating every process you can think of and obliterating Ops department as a whole. First and foremost, DevOps is a culture and a mindset, and these assets are grown and built within the startup, not bought overnight.

There are two main reasons for doing DevOps wrong, and these are incorrect perception and wrong attitude. We will describe them on examples below.

Let’s assume your business is a fledgling startup, which aims to leverage the DevOps practices. We will take a look how wrong perception and attitude can spoil the best endeavors.

A startup operates in the state of constant uncertainty, and its main goal is to launch the product, to meet the target audience expectations and secure their bottom line as quickly as possible in order to ensure its survival. They opt for the shortest MVP development cycles and prefer spending money on the most pressing matters only, under a paradigm of solving the matters once they arrive, not preemptively. This does seem like the goals and methods of DevOps culture, doesn’t it?

While such approach definitely looks solid from the term of saving money and ensuring more rapid time to market, it holds several unpleasant downsides. If you concentrate only on the matters at hand, it’s harder to think strategically and ensure scaling capabilities. This results in technical debt and situations when the startup cannot scale predictably to meet the demands of the rapidly growing numbers of customers. This is a sad story of too many startups that skyrocketed before nose diving miserably. What advice can be given then?

The preferable approach is having the right perception and attitude from the start. Do not aim for short-term goals, think of the problems your product will meet in a year or more, and build the code keeping them in mind. Ask yourself the following questions:

• Are you employing all-around capable teams of versatile DevOps engineers that can write the code, test it, push it to production and solve the customer’s requests?
• Is your team using fresh DevOps tools for optimal efficiency of your infrastructure operations?
• Is your product able to scale overnight to meet the growing number of requests?
• Are you able to redesign it quickly, should some new trends arise?
• Is the product modular (built with microservices), so that new features can be introduced (or old ones removed) seamlessly and without trouble?
• Most importantly, when are you going to automate the software delivery process — from the get-go or only when manual testing and deployment begins to take too much time?

If you answered any of these questions negatively — well, sorry to disappoint you, yet you are doing DevOps wrong…

How to do the DevOps right then?

An ounce of prevention is worth a pound of cure, as the old saying goes. Do not concentrate on the problems of tomorrow, think of how to avoid stockpiling the issues in the future. Instead of siloing the tasks and responsibilities in certain departments, make sure your developers can provision the environments and push the code to production, while operations engineers can run tests and fix the bugs on the go.

The code must be built with scalability in mind from the start, and the product must be comprised of several separate microservices, rather than act as a monolithic entity. If a mistake happens, it’s not somebody’s fault — it’s a system flaw that must be corrected, a room for improvement, not a reason to blame somebody.

Such attitude towards the workflow provides the following advantages:

• a cross-functional team of highly-motivated DevOps specialists,
• independent development and continuous integration of new features,
• automated testing and continuous deployment of new code to production,
• building the infrastructure as code, rather than manually provisioning and configuring the required development, staging and production environments.

This is what doing DevOps right really means for a startup:

• Adopting the culture of communication and collaboration on the projects, rather than delegating and siloing tasks and tools
• Writing code with scalability and fault-tolerance in mind to ensure the performance issues are solved preemptively, not after they cause a service downtime
• Writing automated tests from the get-go, to ensure maximum service versions and components compatibility and efficiency of testing
• Automating multiple routine tasks to reduce maintenance costs and focus resources on essential things and improvement
• Preventing “works on my machine” situations, due to using immutable infrastructure and automated software delivery pipeline
• Delivering new product features according to a steady schedule, not “once it is ready” or semi-annually (the rate depends on the product, the predictability is what really matters).

Conclusions

As you can see, simply buying tools like Ansible, Chef, Puppet or Kubernetes will result in no good if the team does not commit to adopting the spirit of DevOps. However, DevOps is not a space flight that ends in a catastrophe if anything goes wrong. It is rather tangoing, as Al Pacino has put it in the “Scent of a woman”: No mistakes in a tango, not like life. It’s simple. That’s what makes tango so great. If you mistake, get all tangled up, tango on!

Any business, and a startup is not an exception, has to have a clear vision of what they intend to achieve. One of the best goals to strive for is a predictable delivery of a new code with minimal disruption of existing operations and optimal allocation of available resources by a team of versatile and engaged DevOps engineers. To achieve this goal you must accept the new culture, train to use new tools and develop a specific mindset of your team. If you are not doing the things that way — perhaps, you are doing DevOps wrong.

This article was originally published here.