Is DevOps living up to its hype?

Expert surveys are revealing that teams working with DevOps have reduced their lead times by 200 times and have gained the ability to deploy 10s of times faster than the competitors. This agility and speed are coupled with 60 times fewer failures and 100+ faster time to revoker from disaster. This is huge!

Every enterprise is looking to decrease the time from Concept to Cash. DevOps has demonstrated the ability to help an organization achieve this particular goal.

Let’s look at the background of DevOps and then the different versions of its implementation.

DevOps and its Benefits

DevOps combines software development with information technology operations.

DevOps can help you with the speed to market. It makes your organization and infrastructure elastic and reduces the time from ideation to marketing. This enables organizations to have control over unit costs and infrastructure while improving efficiency. All this results in an increase in core infrastructure to produce consistent resilient and available products.

Why DevOps? — Mindset: Traditional vs Now!

Product vs Services

Product development and deployment have gone through many shifts over the years. Traditionally, you build a product and then hand it over to operations. Now, more and more enterprises are looking towards building services and managing those.

So, there is a transition from product to services mindset.

Traditionally, you would have features developed and deployed. With this new mindset, you build services which are always running and being improved upon, until they are turned off.

Wall of Confusion

Back then, teams worked in silos and the term “Wall of Confusion” popped up. Dev and Ops worked in different departments. All the info was simply thrown over the wall and each group would blame other for the mishaps and mistakes.

With DevOps, where both functions work together as a team, all are working tougher for end-user value delivery.

Reactive vs Proactive

Traditionally, monitoring and operations were primarily reactive. This resulted in the blame game and customer value delivery was hurt during the process.

With the new mindset, you are proactively managing the apps and have shared resources for complete focus towards value delivery for end users.

Polyglot Languages, Frameworks, and Environments

Traditionally the applications were built using common languages, frameworks, platforms, and infrastructure.

In cases, where different systems are to be integrated, resulted in massive hassle and at times such endeavors failed.

A natural transition was to enable a mechanism to allow plugging in distributed services, using different operators, instances, and hardware.

Waterfall vs Agile

Essentially a waterfall approach from design to development to testing to deployment to Ops has to be changed in a way, where all activities are continuous.

So, with DevOps, you are trying to enable a system of continuous delivery, continuous testing, continuous integration, and continuous deployment. Let’s look at each.

Continuous Delivery

Continuous Delivery can be termed as the core function of the DevOps. With Continuous Delivery, you have the ability to build the code and move it to other stages like build, QA, testing, and operations.

With Continuous Delivery, you might be able to do versioning, scripting, dependency mapping, and then move onto the testing stage. With the testing stage, you can work with test scripts, test deployment, provision data, and generate testing reports. Once done, now can move to operations, where you can do image management, auto environment deployment, security configuration and so on.

Remember, with Continuous Delivery, you have the ability to push certain changes to the production, but in essence, this process isn’t inherently focused on delivering every change to production. You are setting up a system, where you can push your code base to any next stage you want.

Continuous Testing

To err is human. To protect ourselves and our products from this, building a strong testing suite is a must. Testing gives any organization the ability to confirm the desired functionality of the feature or the product. It also helps to find syntax errors, standardize code patterns and format, version and configure properly, and reduce bugs.

Continuous Testing should be enabled using as much automation as possible. Automation in testing help bringing in consistency. So, good old unit testing, regression testing, smoke testing, and so on are to be automated. This enables a system where you can adjust and react quicker.

Continuous testing helps in building on lean methodologies of having a cord to pull whenever an error occurs.

Continuous Integration

Continuous integration is all about bringing system together. So the work of the developers, DBAs, Security administrators and so on can be brought together in an automated manner and making sure that all system work well with one another. So in essence, you are integrated technology, tools, people, and processes.

Why continuous integration? Consider a workflow where coders are committing the changes to the code. Now your integration server (could be Jenkins, Travis, CircleCI …) will fetch those changes and try to build it. If that succeeds, the output is sent for testing. In case there is a failure during the process, the notification is sent back to the developer to have a look at the issue and fix the problem. This enhances the ability to find and fix issues, improve quality, and reduce time to release updates.

Continuous Deployment

As the name suggests, with continues deployment you are deploying your work out to the world. With Continuous Deployment, you are pushing your products continuously and you have an entire system in place to make changes in code to the end user for value realization with few clicks.

For continuous deployment to work, you need to make sure that your organization is ready for Continuous Integration and Delivery. Essentially, you need your system to work together to continuously deliver your code through the build, testing, configuration, staging, and finally to production.

Do you need Continuous Deployment?

There are organizations like facebook, where you can commit code to the end user, using Continuous Deployment easily and swiftly. But not all organization would want to make code commits that often. Any organization that releases an update once per year, might consider setting up Continuous Deployment, too much of an effort.

Still, even if your needs aren’t that frequent, you might want to look at other user cases like Bug Fixing. With Continuous Deployment in place, you might fix a bug with few clicks. But if your organization lacks Continuous Deployment, you might be stuck with days or weeks before you can commit code to resolve the issue.

Summing Up:

At the heart of DevOps are the people and the organizational culture. Since Agile principles are pretty much at the heart of DevOps operation, you need to get the hierarchy of People, Process, and Tools, right. So the beginning point for any organization would be to get the right people in first. Once they are in, then they can opt for the best tools and process to get the ball rolling.