As the DevOps movement gains popularity enterprises have started to adopt its concepts and tools to manage large infrastructures and complex delivery processes.
InfoQ asked some experienced DevOps adopters about the organizational and technical obstacles still ahead for the movement to step into the enterprise world.
The panelists:
- Gene Kim - founder of Tripwire and author of the upcoming book "The DevOps Cookbook" from IT Revolution Press.
- Jez Humble - consultant at ThoughtWorks Studios and co-author of Continuous Delivery who blogs here
- Patrick Debois - developer, manager, sysadmin, and tester who coined the term DevOps and since then organizes regular DevOps Days
- John Allspaw - SVP Tech Ops at Etsy.com and Culture Hacker
- Mitchell Hashimoto - Creator of Vagrant, operations engineer at Kiip and open source enthusiast
The questions:
- To what extent does the size of an organization affect the successful implementation of a DevOps culture?
- When talking about DevOps in large traditional organizations (enterprises) one of the main roadblocks seems to be the environments heterogeneity (machines/OS) and the fact that existing tools seem to work really well only on particular environments, not mixed. Do you agree?
- Opscode Chef's CTO Chris Brown recently mentioned the importance of migrating private Chef to a DB (MySQL and PostgreSQL) more familiar to enterprise folks. Do you think avoiding (technical) disruption is a requirement for DevOps to thrive in enterprise settings? Or on the contrary such disruption is needed in order to trigger/reinforce a cultural change within organizations?
- What would you say are the main obstacles and road ahead today for enterprises to adopt DevOps as part of their ALM?
- Do you think it's possible for large enterprises suffering from organizational silos to realize the benefits of a DevOps approach? How?
- DevOps appeared a year ago on the Gartner hype cycle as an emerging approach holding less than 1% enterprise market penetration but thought to reach its plateau of productivity in 5 to 10 years. Does this ring a bell in your own experience?
- Could too much hype eventually harm the movement by focusing on visible changes as creating DevOps jobs without actually addressing collaboration problems between devs and ops?
- Most of you have participated at DevOps Days and other conferences in this field. How do you see the evolution of DevOps and in particular its expansion from web-based agile companies to legacy-based process-oriented organizations?
- Any last words about these topics?
InfoQ: To what extent does the size of an organization affect the successful implementation of a DevOps culture?
Gene: Being in a large enterprise IT organization is no excuse not to adopt DevOps types of practices. But it would be foolish to ignore the challenges caused by the cultural aspects and effects of incentive structures that happen in larger organizations.
There’s a considerable amount of literature that the amount of counter-productive "us vs. them" tribal behaviors occurs more in larger organizations. It isn’t restricted to "Dev vs. Ops," but also "Production vs. Sales," "Marketing vs. Development," "Development vs. QA," etc.
Dr. Eliyahu Goldratt described this as the "local optima" problem in his Theory of Constraints and his book "The Goal." Often, the tribal warfare between groups is codified in their measurements.
For example, in manufacturing organizations, the VP of Sales often would, in order to protect customer commitments, be incentivized to carry as much inventory as possible; while the VP of Plant Operations, in order to reduce costs, is incentivized to reduce the amount of inventory. So, no wonder they’re often warring with each other.
The classic DevOps example is the VP of Development who is incentivized by feature time to market, and thus is motivated to deploy as many changes as possible; but the VP of IT Operations is incentivized by operational availability, and thus is motivated to deploy as few changes as possible.
Overcoming this core, chronic conflict between Development and IT Operations is a key part of a DevOps transformation. When organizations make this breakthrough, the results are amazing. I've seen organizations with thousands of developers and hundreds of IT operations staff make incredible improvements in feature flow, while increasing stability and reliability.
Jez: My personal definition of devops is "a placeholder for a continuing discussion about how everyone involved can work together to improve the business of building and running systems." So I'm going to argue that you can never be "done" with a devops implementation - as Mike Orzen said to me, you shouldn't think of such an implementation as a project or program because they have end-dates. Thus I believe devops should be implemented through continuous improvement - find out what your biggest problems are, try and define some quantitative goals you want to achieve, and then come up with some ideas about how you might achieve them. Run some experiments with some teams who have a high level of maturity and are willing to try things out. Then take the lessons learned from these experiments and apply them to other parts of the organization.
How does the size of the organization affect this process? First, of course it will take longer. Second, you have to get buy-in from the leadership to get the time and resources you need to carry these experiments out and accept that they will slow things down and cause pain in the short to medium term. Finally you need people on the ground who are willing to make the time to experiment and collaborate.
Thus in a sense a "devops culture" means an organizational culture in which continuous improvement is actually possible - one that fulfills the criteria above. That's something that's very hard to implement, and usually the biggest barrier in large organizations is that the leadership - perhaps unwittingly - doesn't understand the importance of creating such a culture, or know how to do it (see my discussion on Theory X and Theory Y below).
John: In theory, I don't think that the size of an organization should matter. In practice, I wouldn't be surprised if success on that front had an inverse proportional relationship to size, mostly because larger organizations have some characteristics that allow for scale, but may prevent large shifts in culture to propagate. For example, a company whose development group is geographically separate (different building, different continent) from the operations group are going to have a tough time getting empathy, cooperation, and frequent communication put together unless they invest in expanding how the groups communicate.
Having said that, if a company has small pockets of dev and ops groups co-located or who can communicate freely and given a wide charter on implementation of technology, I could see it working well. This is what's been suggested before, a "skunkworks" approach: start with a small group, get them to ship something that has higher quality and operability than the status quo, and then point to the cooperation/collaboration as something to replicate elsewhere. I've seen and heard about this approach working, but I haven't yet see it spread entirely across the org until it's the predominant cultural norm.
Mitchell: I've never worked in an organization with more than 50 people, at least as an engineer, so I don't have any experience to back up any answer to this question. It’s always easier to invoke change in a smaller group than it is a larger group. However, some large organizations are setup in such a way that incorporating a DevOps culture is less painful. For example, if the organization is broken up into several small, autonomous, agile groups of a handful of people, then incorporating DevOps into one group is almost as simple as doing so in a start-up environment.
When more people are involved, it is important to show each person the value that DevOps brings to any organization. For developers, this means shipping features faster, for operations this means sharing more responsibility and getting more eyes on the infrastructure as well. For business folks, this means improved overall agility, which is typically cheaper.
Patrick: As with any change, the number of people to be changed will affect the speed of change and impact: within smaller organizations new ideas will take less time to reach all people and when the ideas reach people the initial idea will stay more pure because it has not been 'translated/transformed' along the way. This is regardless of top-down of bottom-up approaches.
Larger organizations will by nature have more structure/rules in place and changing them will also take more time, much like turning an oil-tanker into a kayak. Still the size does not tell you a guarantee of success, even within small organizations early failures or misinterpretations can lead to non adoption.
Therefore I think it's import, as with all change, that there is value and benefit for doing so. Showing early and repeated success is crucial.
InfoQ: When talking about DevOps in large traditional organizations (enterprises) one of the main roadblocks seems to be the environments heterogeneity (machines/OS) and the fact that existing tools seem to work really well only on particular environments, not mixed. Do you agree?
Gene: Heterogeneity is a fact of life, and I don’t believe it’s actually a valid DevOps objection. After all, any IT Operations organization that has had any amount of success will struggle with complexity, where a sprawling number of platforms and applications starts becoming a drag on daily operations. When this happens, organizations need an architecture and platform strategy where they decide where the organization will invest to create mastery, and which ones to abandon.
Overcoming complexity is part of the growing pains in any IT organization, with or without DevOps. In fact, done right, DevOps can help ensure that there’s always fast flow of planned work, which should help accelerate the paying down of technical debt.
Jez: I actually think that the organizational issues I discussed in the previous answer are a lot harder to solve than the technical ones described in the question. The main roadblocks I find are concerns around governance (can we have developers and operations people collaborate and still be SOX or PCI-DSS compliant?), empire-building by managers of functional silos, and an unwillingness to create slack time to work on improving the delivery system. This last problem exhibits itself in different ways in different parts of the organization. In development you find managers who won't let developers do anything other than working on features and fixing bugs. In QA, testers are focussed primarily on performing manual testing. Operations spends its entire time firefighting. Nobody has time to think about improving the process. It's like a woodcutter who is under a tight deadline to cut down a lot of trees, and thus doesn't want to stop cutting down trees in order to sharpen his axe.
Of course there are technical issues too. But more than environmental heterogeneity, I find that often a bigger problem is enterprise architecture. In enterprises, systems are usually big monolithic codebases that are tightly coupled to each other and to COTS that has been heavily customized. Thus you can't deploy anything without deploying everything, which makes provisioning production-like environments for integration and testing purposes incredibly slow and expensive. The first priority here is to work on making their systems more modular so you can deploy individual modules independently in an automated fashion and find the majority of bugs through acceptance testing in a non-integrated environment. Modular architectures also make integration testing easier. When enterprise architects think about requirements for their systems, deployability and ease of testing and integration don't feature nearly as highly as they should.
John: I can see how someone might take that stance, but I don't think that it's a true impediment. I can't say with a straight face that the converse is true; that homogeneous environments would have a better time getting development and operations cooperating and collaborating. I guess one could say that the more homogeneous an environment is, the number of automation (imaging, config management, deployment, monitoring, etc.) tools would potentially stay low, which would make it easier for multiple parties to share experiences, code, and adjustments.
The ironic thing that I've found in companies that have a huge number of software stacks across pockets of the company is usually indicative of historical rationales that follow axioms like "not invented here", "right tool for the job", and "my manager knows this tech, so we'll use this in our group", which are local optimum (good for the group), but globally sub-optimal (not good for the entire company). Part of a mature dev and ops relationship is to make tradeoffs explicit (in this case, when choosing software), and globally optimal solutions come from that.
In the extreme case where many groups all over a company have decided on completely unique software stacks, there's a danger that even if there aren't organizational silos, there can be implicit ones aligned with the stacks. For example, the "PostgreSQL" group, the "MySQL Server" group, the "Windows" group, etc. Walls that align on those boundaries are still walls to hurdle.
Mitchell: Heterogeneous environments certainly raise the difficulty level substantially. It is easy for many people to disregard this and yell "use the same machines and operating systems, obviously!" But I think most organizations would prefer a homogenous environment, and simply end up at a heterogeneous due to factors they can't control. Some software only runs on some operating systems, some parts of the organization move forward with new systems while legacy systems retain older versions, etc.
For myself, I can say that it is a top priority for my own tool, Vagrant to support as many environments as possible. If Vagrant doesn't work properly in one environment, then it is a bug. As Vagrant is a relatively new tool and only recently starting to breach larger businesses, I'd say that as tools become "enterprise ready," that one of the core features necessary is widespread system support.
Therefore, while heterogeneous environments are certainly annoying to deal with, I expect newer tools to embrace this sort of chaos.
Patrick: If you think of devops through the CAMS model (Culture, Automation, Measure and Share), I don't see any inherent devops issue but more in technological challenges. We should still use the best tool for the job, regardless. Reducing the number of tools will contribute to speeding up the learning curve. But then again it's in the nature of enterprises to have a multitude of different apps build at different times with different technologies. It's important that you keep fighting this heterogeneity as a form of technical debt, especially when systems become legacy. I would not consider it a roadblock of devops adoption though.
InfoQ: Opscode Chef's CTO Chris Brown recently mentioned the importance of migrating private Chef to a DB (MySQL and PostgreSQL) more familiar to enterprise folks. Do you think avoiding (technical) disruption is a requirement for DevOps to thrive in enterprise settings? Or on the contrary such disruption is needed in order to trigger/reinforce a cultural change within organizations?
Gene: I think the transition Chris Brown is referring to is not DevOps specific, but more about how technology vendors need to fit within the technology capabilities of their customer. We went through a similar transition when I was the CTO of Tripwire. We migrated to Oracle and MySQL so that creating a new database instance would be a routine task (i.e., opening a ticket), instead of a novel one-off task, involving days of research for our customers.
This reinforces the adage that initiatives such as DevOps should leverage existing processes and tools, as much as possible.
Jez: You need to work out what battles to fight. For me, when people within organizations are trying to change the way they work, the key thing is to demonstrate measurable improvement as rapidly as possible, and certainly within a few months, and then keep doing it. That necessarily limits the scope of what changes you should embark on. The changes with the biggest lead times are political, so if you're going to avoid a big fight with the operations folk by agreeing to use Postgres or MySQL, that's probably a smart move.
John: I don't think that avoiding technical disruption is a requirement. Instead, I'd say that a requirement be that an organization have the ability to make tradeoffs in every technical choice explicit, in terms of performance, feature set, and operability. I see where and how Chris would say that, related to my comment in the previous question.
Now it's probable that the cultural shift needs a big-bang moment, such as a large technical decision, in order to harness the enthusiasm and self-selection of engineers who are up for such a change. But is it a requirement? I'm not entirely sure.
Mitchell: It matters. Opscode Chef is open source software, an open box that they expect organizations to be able to install and manage on their own. If an organization doesn't feel comfortable with this, they can go with private Chef. On the other hand, when something is a black box, technology choices do no matter so long as the company behind the software makes service level guarantees about the software they are shipping.
Patrick: The balance is somewhere in between: to have people adopt new technology they have to be able to relate to either the problem/technology/solution you propose. Disruption brings people out of their comfort zone: some people like that as a way of being challenged others not. It's important you understand your audience. If like Chris, you want to drive adoption of your tool, make the barrier for adoption lower by reducing the learning curve.
InfoQ: What would you say are the main obstacles and road ahead today for enterprises to adopt DevOps as part of their ALM?
Gene: Based on the work I’ve seen presented by enterprise IT organizations (e.g., Unum, Paychex, BNY Mellon, World Bank, etc.), DevOps initiatives are often pushed by the same groups that drive enterprise ALM and SOA initiatives. This makes sense. These are the groups motivated to improve service quality, and routinely work with Enterprise Architecture, Development, QA and Operations.
Their challenge is to get all these different groups to act as one super tribe, trying to solve a larger systemic problem as opposed to allowing these groups to act as warring tribes.
See the next question below for how ALM groups are uniquely suited to solve this organizational silo problem.
Jez: First you have to recognize that you have problems and be committed to solving them on an ongoing basis, and that doing this is going to be painful, especially in the short term. The scope of devops adoption is pretty wide, ranging from how you approach compliance and auditing to the architecture of your systems. People will need training, coaching and support in everything from maintainable test automation to how to communicate effectively with other people in the organization. Finally, everybody needs a clear, shared vision of where they want to go in order to create a plan on how to get there.
John: I would say that organizations that don't view technology as a competitive advantage is the largest obstacle. This is my own bias, but when I see a company refer as a whole to the people who run the computers as the "IT Department", as opposed to "Application Development" or "Technical Operations", etc., I see a company who very much views computers as a necessary evil for the business, not a vehicle for enablement.
I once worked at an advertising firm in Boston. The resourcing, focus, and ability to get things done in Technology to enable the business was generally on-par with the Facilities group, who was charged with making sure light bulbs got replaced when they were burned out. The engineering groups were not seen as enablers for the business so therefore left out of the loop of conversations about future direction and other ways that technology might help move the company forward. This meant that culturally, the engineering groups were treated as second-class citizens in the company, and so therefore didn't get as much attention paid on progressive topics, which is needed.
So the greatest obstacle for Enterprise companies is to get past the stereotypical view of IT as technicians keeping the servers working and start viewing them as engineering-driven groups that can bring a competitive advantage to the business, and therefore worth investing time and effort.
Mitchell: The biggest obstacle at this point is education. DevOps has been a turbulent movement the past few years because it hasn't been strongly defined. I think we're finally reaching a place where more people can comfortable say what DevOps is along with case studies showing it actually works. Given this, the resources are still too hard to find on what DevOps is and how you can transition your organization to a DevOps culture.
I'd like to see less hand-wavy talks on DevOps and more concrete step-by-step approaches to implementing DevOps. I realize that these approaches don't work for every organization, but at least it'll help guide folks.
Patrick: If you consider the challenges for the devops 'movement', it's to bring out more Enterprise success stories compared to the many startup/web 2.0 company success. People are trying with varying success, but they are often scared to bring out the 'non' successes as they would consider them a failure. Sharing failure is an important thing of learning, and needs to stimulated.
From people within the enterprise, I think are similar to any change being introduced (like Agile several years ago). Depending who you talk, CEO, CIO, project mgr or technical person it needs to be compelling and bring value. The obstacle for adoption is often the inertia of companies and looking wearily at the new trends. They need to be proven. People and their habits are really the biggest challenge. I found that often it becomes a believe question: does collaboration and shared goals increase value or do you believe stricter and clearer separation of duties have a better impact. Depending on the team and persons vision, they will be inclined to go for one of both. I even believe that some people will not thrive within a devops mindset if that's your core belief.
InfoQ: Do you think it's possible for large enterprises suffering from organizational silos to realize the benefits of a DevOps approach? How?
Gene: a. Recognition of a shared problem
What I’ve found in over five years of research is that the organizational silo problem leads to an adversarial relationship between Development and IT Operations, which results in an ever-increasing amount of technical debt that slows down the rate of feature release and time to market, as well as ever increasing instability and chaos in the IT production environment.
The challenge is always how to show Development and IT Operations leadership that neither of their goals are being met, and left unaddressed, will continually get worse.
b. Willingness of management and practitioners to face it
I’ve found that when we demonstrate to leadership how the entire organization is jeopardized and threatened by this inter-tribal warfare, they will act decisively to end it, working together to overcome big challenges, that could scarcely be imagined in months prior.
Outcomes include shorter deployment times, better automated testing, less time spent doing code packaging, more successful releases and faster deployment cadences. Furthermore, with better feedback loops between IT Operations and Development, developers get needed information faster (often through self-service), reduced numbers of escalations because they’ve cross-trained IT Operations staff, and a higher percentage of organizational cycles are spent paying down technical debt.
The result is faster flow of planned work, while increasing the stability, reliability, resiliency and security of the production environment.
And when that happens, Development and IT Operations are truly helping the business win.
Jez: Yes. For me, the most important message of devops is that nobody is powerless - there are little things any of us can do every day to make things better. Developers can go and have lunch with the DBAs and find out why they hate the developers, and what they could do to make things a little bit better. People in operations can carve out 30 minutes of their day to set up version control and check all their scripts into them so that they can improve their configuration management and give read access to developers so they can understand how production environments are created and maintained. Set up cross-silo lunch and learn sessions to share knowledge and develop relationships between groups. Create an internal blog. Nobody should be waiting for a mandate from on high to start up some kind of "devops program".
John: I do, but only by investigating the true reasoning behind the original silo-ing of the groups. If you can't illustrate quickly and easily why it's beneficial to have groups cooperate, then you can't make the case for doing it. Also, if upper management aren't on board, especially management who believe that they are benefitting from silo-ing the groups (vis-à-vis, a convenient "Cover Your Ass" and finger-pointing boundary) then traction will be tough.
I believe the trick is to convince plainly that the effort put in to cooperate, collaborate, and communicate between dev and ops is an investment worth making, worth more than the cultural security blanket of keeping a finger-pointy culture. This persuasion can't happen unless both teams recognize the legitimate place for domain expertise, which means that they defer to each other along those boundaries.
Mitchell: I think it is possible. The people in charge of these silos need to see the benefit DevOps has on the business and the culture. A change for the sake of change is pointless, but when there is actual value gained, then we see change happen.
Patrick: Sure, they can and I would even say they probably often need it the most as the size of company often is driver in creating groups of people as a natural human reflex for grouping similar things. The approach from switching from project teams to product teams with full responsibility from beginning to the end can work well within an enterprise. This will foster collaboration and better results. But much depends on the culture of the company : IT doesn't live in a vacuum, it's a balanced act. Those product teams often seems to be a duplication of effort/costs by less leveraging the so called economies of scale. Still the benefit from adding agility and self management outweighs this.
InfoQ: DevOps appeared a year ago on the Gartner hype cycle as an emerging approach holding less than 1% enterprise market penetration but thought to reach its plateau of productivity in 5 to 10 years. Does this ring a bell in your own experience?
Gene: I believe we’re only at the very beginning of DevOps adoption, which will result in a massive increase of productivity in enterprise IT. When I’ve asked enterprises who’ve adopted DevOps how to respond to people who say DevOps isn’t for enterprises, they’re always puzzled. To them it’s merely a prioritization issue.
I believe that the DevOps patterns are the inevitable outcome when you apply Lean principles to the IT value stream. As Dr. Deming once said, "Survival isn’t mandatory."
Jez: I'd be surprised and very happy if we manage any kind of pervasive change in 5 to 10 years. What has depressed me the most working on my new book on implementing continuous delivery is the extent to which people have been talking about these ideas for decades. Peter Drucker was discussing the differences between knowledge workers and manufacturing in the late fifties, and we still haven't learned those lessons. For example, he said "Productivity of the knowledge worker is not - at least not primarily - a matter of the quantity of output," and yet you still find many organizations which measure developer productivity in terms of lines of code per day. Lines of code are a liability, not an asset! Douglas McGregor came up with Theory X and Theory Y in the 1960s, and it is clear that knowledge workers can only be effective in an organization in which managers have a Theory Y attitude, but that is certainly not the norm in many (perhaps most) enterprises today.
John: Frankly, I don't pay much attention to Gartner, and I'm not really interested in the business of industry predictions. If an analyst is right about a prediction, it didn't really move the industry forward. If they're wrong about a prediction, it didn't move the industry forward. What I'm interested in is the dirty details that bring maturity to an organization's ability to engineer solutions to problems in the present.
Mitchell: Yes. I work in a reasonably young, "hip" environment, so DevOps has been easy to integrate. But it still has obvious rough edges. I'd say in 5 to 10 years it'll reach a solid stabilization point.
Patrick: I'm aware that many of the devops discussion are being done by the early adopters and will take time to spread. Some time ago, people questioned Agile, now about 10years old, how much the market penetration was. I have no crystal ball, but I hope to think we still have a lot of growth potential. The technical aspects like infrastructure as code are faster because they are already instant practical. In the future, culture adoption will increase but will take longer.
InfoQ: Could too much hype eventually harm the movement by focusing on visible changes as creating DevOps jobs without actually addressing collaboration problems between devs and ops?
Gene: Creating job descriptions with DevOps indicate that business leadership is seeing something of value, even if they can’t say what the roles, responsibilities or daily work are. It doesn’t invalidate the need. I think it’s just indicative of how early we are in this journey.
Currently, DevOps is more like a philosophical movement, and not yet a precise collection of practices, descriptive or prescriptive (e.g., CMM-I, ITIL, etc.). The intent behind the "DevOps Cookbook" project is to catalog what the "high performing DevOps organizations" all have in common that result in their extraordinary performance outcomes. Our goal is to create the prescriptive guidance to create the culture, values, processes, procedures and daily work so that we can repeatedly replicate their results.
You can learn more about this project here.
Jez: If organizations were looking for "devops people" to enable organizational change I could get behind it. But many organizations are attempting to address the dev/ops divide by creating a new "devops team" whose job is to span the boundary between existing functional silos that aren't expected to change the way they work. This is, of course, deeply ironic. The focus of organizations interested in actually achieving the goals that devops enables - satisfying the customer through continuous delivery of valuable software, for example - should be helping their existing people change the way they work and learn devops skills such as how to treat infrastructure as code. The other problem with trying to hire in "devops" is that the demand for good people with the necessary experience vastly outstrips supply. And many of these people have been sucked up into organizations which then use them to try and mitigate the symptoms rather than address the root causes, which doesn't do anything to increase supply.
John: I think that too much hype can harm anything, eventually. Frankly, I'm seeing it already. Many reference DevOps and Continuous Delivery as synonymous. How frequently you deploy, how you deploy, and how automated you are has nothing to do with DevOps, other than organizations that do make liberal use of automation and continuous deployment are often known to have a DevOps culture.
I also think that in general, there is a tendency to minimize the "soft-skills" in technology companies. I've seen projects where engineers will spend months trying to automate a process whose main benefit is that they don't have to talk to someone in another group every so often. This is ludicrous, and not a basis for a mature engineering organization.
So I do think that the hype can harm the concept, in the way that it could drive the focus away from the cultural focus and towards a "DevOps-In-A-Box" shrink-wrapped technology-only concept.
Mitchell: We see this sort of issue already, where people call themselves "DevOps engineers" or say "we do DevOps." Again, I find this to be caused ultimately by a problem in education. Therefore, the hype surrounding DevOps gives off some false information, and the circle perpetuates.
Patrick: It's hard to help people that want to believe in fairy tales told by vendors, by which I'm not saying all vendors are bad. The hype I'm seeing is cranked up people who have a financial incentive in doing so. The jury is out if they deliver their promises. The danger is that the so-called 'devops' label can get a bad name due to this. One bad experience weighs more than many positive experiences. Again if you want to think bad, you will have all the ammunition. By keeping the good content and stories coming we can keep the positive side on things. Similar things have happened to Agile and Lean, the difference has been the speed of which devops as an idea has spread around the world. But that speed is also an advantage to get new stories and ideas promoted or adjust remarks. Learning from critics is important and would clearly want to avoid to have devops people turn into 'fundamentalistic' views like 'infrastructure as code' is better than 'shell scripting'.
InfoQ: Most of you have participated at DevOps Days and other conferences in this field. How do you see the evolution of DevOps and in particular its expansion from web-based agile companies to legacy-based process-oriented organizations?
Gene: I believe that we saw DevOps patterns first in the web-based agile companies, because that’s where competition was the fiercest and downtime and user-response times directly equated the revenue.
Because IT is critical to almost every business, we’ll see it adopted next in the more traditional IT organizations. Mike Orzen and I did an article value created by adopting DevOps. We believe it will create four trillion dollars of value worldwide each year, which is greater than the entire economic output of Germany.
That will have a huge positive impact on productivity, standards of living and reduce the amount of damage that working in IT often causes our fellow humans. All this is why I think DevOps is genuinely an important movement.
Jez: There are plenty of web-based agile companies who don't have a devops culture - although you might argue with their definition of "agile", since arguably if you were really doing agile you'd have a devops culture anyway. In my experience these companies face similar problems to organizations that don't define themselves as agile but are still interested in implementing devops. The main risk is that organizations try to adopt devops without a clear understanding of what they are trying to achieve, and in particular without defining measurable outcomes that they want to track to.
People have a tendency to start these kinds of initiatives by buying a bunch of tools, which is almost always a Very Bad Idea - Tools are important, but they shouldn't be your starting point. A good way to start would be to look at the maturity of your existing capabilities in building and running software systems, and then how you'd like them to look based on the measurable outcomes you want to achieve, and then to put in place a plan to get from A to B in not more than a few months (if you think it's going to take longer than that, you need to choose a closer destination).
In my experience though the main barriers to implementing the plan you come up with are politics, culture, architecture, bad tools, and a lack of skills.
John: I think there is a lot of cross-pollination that can still happen, but the empathy between web companies and enterprise companies has to grow from where it is at the moment in order to truly move forward. I still see a good amount of condescension from both sides.
I've been told by a tech exec at a bank that Etsy (or any web company) wasn't a "serious" endeavor, that his bank works with "serious money" which means they can't "screw around" like web companies do. I've also seen web companies poo-poo the enterprise because they're "spoiled" with their small user base and non-24x7 working environments.
Until there is a shared understanding between those groups, the healthy and mature swapping of ideas and concepts is going to be slow.
Mitchell: I'm quite new to the field, having only been involved for a year or so, so I'd feel more comfortable leaving this question to the more experienced people on this panel.
Patrick:Over the last years of devops, we have seen people initially adopt the automation practices. This is slowly shifting into the area of measuring and metrics on a more practical level. I tend to think of it as the return feedback channel automation requires: automating bad practices does not improve anything unless you learn of it. Now the security field is recognizing the value of devops and I'm excited to see people from different parts of the company adjusting their ideas. Whether legacy-based process-oriented companies will only partly be affected of a lack of 'agile' tooling but hugely by the fore-mentioned stubbornness and inertia of the human mindset.
InfoQ: Any last words about these topics?
John: I would just like to say that reports from practitioners in the field rule the day. DevOps as a concept or collected ideas will live or die by its ability to get things done for a business. Which is why sharing these stories at conferences and in articles is so important. So for people who believe that collaboration, communication, and cooperation between dev and ops is a good idea: tell your story. And don't leave out the nasty bits, tell it all.
For those others who aren't convinced of DevOps: if you think that your business will thrive further by motivating people to hoard information, isolate their functionality in the resource chain, or otherwise work at cross-purposes with other groups…go for it. As long as you share that story with the rest of your field.
Cultural shifts don't happen because people invent new words. They happen because people take action, and then tell stories about it.
Mitchell: Use Vagrant! I'm obviously biased but multiple sources have told me it helps drive DevOps change much more smoothly throughout an organization since you can more freely experiment and play with the tools necessary to properly incorporate a DevOps culture.
Patrick: Sharing amongst peers, organizations and industries is a crucial factor in the growth and richness of devops ideas. Similar to sharing code, I'd like to capture new ways of thinking and keep on encouraging people to do the same. . Devops has shown that grass-root ideas can have an impact just like you can express yourself on youtube vs buying airtime on TV. We are the industry that we make it to be.
About the Panelists
 |
Patrick Debois has taken a habit of changing both his consultancy role and the domain which he works in, in order to understand current IT organizations: sometimes as a developer, manager, sysadmin, tester and even as the customer. During 15 years of consultancy, there is one thing that annoys him badly, it is the great divide between all these groups. But times are changing now: being a player on the market requires you to get these ‘battles’ under control between these silos. He first presented concepts on Agile Infrastructure at Agile 2008 in Toronto, and in 2009 he organized the first DevOps Days. Since then he has been promoting the notion of ‘devops’ to exchange ideas between these groups and show how they can help each other to achieve better results in business. He is currently organizing DevOps Days events all over the world.
|
 |
Gene Kim is a multiple award winning CTO, researcher and author. He was founder and CTO of Tripwire for 13 years. He has written two books, including "The Visible Ops Handbook," and is now writing "When IT Fails: A Business Novel" and "The DevOps Cookbook." Gene is a huge fan of IT operations, and how it can enable developers to maximize throughput of features from "code complete" to "in production," without causing chaos and disruption to the IT environment. He has worked with some of the top Internet companies on improving deployment flow and increasing the rigor around IT operational processes. In 2007, ComputerWorld added Gene to the "40 Innovative IT People Under The Age Of 40" list, and was given the Outstanding Alumnus Award by the Department of Computer Sciences at Purdue University for achievement and leadership in the profession.
|
 |
Jez Humble is a Principal at ThoughtWorks Studios, and co-author of the Jolt Award winning "Continuous Delivery", published in Martin Fowler’s Signature Series (Addison Wesley, 2010). He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services, and online retail companies. His focus is on helping organisations deliver valuable, high-quality software frequently and reliably through implementing effective engineering practices.
|
 |
Mitchell Hashimoto is the creator of Vagrant and is an operations engineer for Kiip. He is passionate about all things ops and open source, and enjoys spending hours of his free time each day contributing to the community. In addition to simply contributing to open source, Mitchell enjoys speaking at conferences and user groups about Vagrant. Mitchell can be found on GitHub and Twitter as @mitchellh.
|
|
|
John Allspaw has worked in systems operations for over fourteen years in biotech, government and online media. He built the backing infrastructures at Salon, InfoWorld, Friendster, and Flickr. He is now VP of Tech Operations at Etsy, and is the author of The Art of Capacity Planning published by O'Reilly.
|
