Showing results for 
Search instead for 
Did you mean: 

Transitioning to DevOps? What's DevOps?

Level 9

If you're in technology, chances are you don't go too many days without hearing something about DevOps. Maybe your organization is thinking about transitioning from a traditional operations model to a DevOps model. In this series of blog posts, I plan to delve into DevOps to help you determine if it's right for your organization and illustrate how to start down the path of migrating to a DevOps model. Because DevOps means different things to different people, let's start by defining exactly what it is.

My big, semi-official definition of DevOps is that it is a way to approach software engineering with the goal of closely integrating software development and software operations. This encompasses many things, including automation, shorter release times for software builds, and continuous monitoring and improvement of software releases. That’s a lot, and it’s understandable that a good amount of people may be confused about what DevOps is.

With that in mind, I reached out to people working in technology to get their thoughts on what exactly DevOps means to them. These individuals work in varying technology disciplines from data center engineers, Windows SysAdmins, and Agile developers to unified communications, wireless, and network engineers. About thirty people responded to my simple query of, "When someone says 'DevOps,' what do you think it means?" While there was a fair amount of overlap in some of the answers, here's a summary of where the spread fell out:
  • It's supposed to be the best combination of both dev and ops working in really tight coordination
  • Automation of basic tasks so that operations can focus on other things
  • It's glorified script, in other words, developers trying to understand network and storage concepts
  • It's the ability to get development or developers and operations to coexist in a single area with the same workflow and workloads
  • It's something for developers, but as far as what they actually do, I have no clue

A lot of these responses hit on some of the big definitions we discussed earlier, but none of them really sums up the many facets of DevOps. That’s okay. With the breadth of what DevOps encompasses, it makes sense for organizations to pick and choose the things that make the most sense for what they want to accomplish. The key part, regardless of what you are doing with DevOps, is the tight integration between development and software operations. Whether you’re looking to automate infrastructure configurations or support custom-written, inventory-tracking software, the message is the same. Make sure that your development and operations teams are closely integrated so that the tool does what it needs to do and can be quickly updated or fixed when something new is encountered.

Level 21

My wife was a software developer / coder and Quality Assurance Manager for Control Data back in the '80's and '90's.  She laughed when she read about "DevOps" using the definitions above.

"That's just good writing of code--it's nothing special.  It's competent people writing software properly so the applications work well.  Don't obsess over the terminology because at the end of the day it's nothing new.  It's simply doing the job of programming the way it should always be done.  It's not necessarily the way you learned to code in school, or online, or OTJ--but the way to make an app work the way users need it to work.  Nothing more."

Level 9

I agree with most of what your wife said.  DevOps is people writing good code and interacting with users to make an app work the way they need it to work.  I actually considered skipping this post completely, but when I started talking to people I got answers from people who have management asking them to make their organization more DevOps oriented and they think that it's some sort of product from Cisco (I had more than one reply like this, as well as others where they weren't sure).  So yes, if you're a developer with almost 40 years of experience it may seem silly to try to define it, but there are a lot of people in roles that are traditionally not development roles (network managers, server admins, storage admins) being asked to do this that have no clue what they are being asked. Unfortunately they have to obsess over the terminology because their boss read about it in a magazine or heard about it at a trade show and now have set it as part of this person's role.
Level 16

Nice write up

Level 15

Collaboration between teams/silos/departments Ahh the pipe dream of us all.

Level 21

It's unfortunate we aren't all given, or required to take, training to ensure our performance is efficient and optimized.  People dropped into new positions but not given training, not knowing which wheels have previously been invented, and how to do the new job well (by working closely with PMs, Clients, Networks, Security, DBAs, SysAdmins, etc.) results in a lot of inefficiency.

Enough of that kind of performance, across sufficient businesses and industries, gives code writers an opportunity to develop reputations, good or bad.

It's impossible to ensure that everyone has the skills and tools and training they need to do the job the right way--especially when staffing levels are kept to a minimum, and training budget isn't allocated.

Level 18

What was old is new again.

It all runs in cycles. Pretty much history repeating itself but named something else.

Level 14

Looking forward to this thread.  We are moving in the DEVOPS direction.

Level 9

Very true,  I could probably write a whole series on training and what happens when you skimp on getting your employees trained

Level 21

I touched on some of those ideas here:  Some Thoughts on Professional IT Training

I'd LOVE to see your analysis of what happens when skimping on training.

Level 19

Dev what???

Level 21

This must be the new trend in our industry, slap some new terminology on something and teat it like it's a brand new idea that is going to revolutionize our industry.

Level 21

"New trend?"  Naw, see Cisco's entire history.  And that of the military and its vendors, too.

Level 18

Not a new trend..been happening in the industry for over 2 decades now....

Level 19

My group has been making the transition from a standard Network Operations Team into a Network DevOps team over the past year. At first I had no idea what DevOps is, much less Network DevOps. The more we do, the more I understand what Network DevOps is and why it is so difficult to understand. Here is what I have come to realize. First, DevOps applies more to ops than it does to development. It involves taking the best practices from the dev world and applying that framework to operations. There are probably a lot of ways this can be done but we are doing is applying scrum/sprint to help breakdown typical operations projects into smaller, more achievable efforts. 

Secondly it involves applying automation and orchestration to operations using tools like scripting, Ansible, and Chef to rid operations of repetitive tasks.

I recommend DevOps for Networking by Steven Armstrong. The book has more to do with applying DevOps to Networks (thus the name) than DevOps principles.

Level 21

I suspect adopting a "DevOps" style includes "Doing unto others as you would have them do unto you." 

In other words, if someone were going to impact your life, wouldn't you want to work with them and give them ideas and feedback, approval or denial for requested actions, and teach them about what it takes to make your world a happy one?

It shouldn't be a new concept to anyone (and it's not to successful sales people who have great moral character), but apparently many of us are like Chrysler Motor Company in the 1970's, where they built cars as fast as they could, assuming consumers wanted whatever rolled off the assembly line.  That was a mistake--and a DevOps style of manufacturing would have done great research and sharing with the customer base, then taken their input to the designers.  What came out the factory door would have been in demand instead of in the junk yard.

Don't let your projects proceed without including your clients and all ancillary teams.  Communicating with them thoroughly and effectively (by getting their input on everything you think your team should be doing, and then asking what their teams think your team should be doing) will provide more satisfying results to everyone.

You'll sleep better at night, maybe get better job security or a raise or a promotion--it's all in your control. 

DevOps is sharing and listening and thoughtfully considering what you've learned--before making a single change to the environment in which you work.

Level 14

The worst thing about DevOps is that management don't know what it means but still force their idea of it onto us techies who are already doing the job properly.  All that happens is that stuff gets done poorly because of new tighter deadlines, nothing gets documented or tested and the end result is the users think IT is crap.  Case in point - automation - a new script was deployed here without testing because management wanted something done 'yesterday'.  Change control was ignored and no sharing of information happened.  Unfortunately that script caused an undocumented script which ran overnight to expire all of our AD service accounts.  Chaos the following morning and one of the basic principles of DevOps ignored.

Level 21

That's an excellent example of NOT following DevOps processes.  It's too bad your administration team doesn't understand that DevOps includes doing the job the right way, instead of only worrying about getting it done quickly.

An unhappy customer is the result.  I'm sure that's not their intent, but it certainly is the result of their new DevOps implementation.

Level 13

Dev-ops, is a culture of the business, I seen it as a business embracing agile methodologies combined with automation.

Level 7

DevOps - methodology, born in 2009, aimed on collaboration of developers and aiem administration for the increase of product release frequency.

Therefore, DevOps engineer is a specialist who works on the joint of these two positions, and who is engaged in automation of product lifecycle (including designing, development, testing, deployment, support and monitoring).

Objectives and responsibilities.The main duty of DevOps engineer is to increase predictability, efficiency and security of software development.

If we take a look on the complete lifecycle of software, than we see that on the estimation stage DevOps specialist receives and analyse the information about the requirements to infrastructure.

On the planning stage he designs the architecture.On the stage of developing and testing (QA) he works on automation of product deployment to development and testing environments, integration of code auto-tests into development process, and load testing of the infrastructure.

At last, on the delivery stage, when the product is ready to be deployed to production environment or updated to the newest version, he responsible for making this process seamless and without interruptions, invisible for product users.