#devops - CrowdChat

Clouderati on DevOps

Thought leader conversation on DevOps and Cloud. People and tools - good patterns v. anti-patterns

#devops @furrier @jfryman @epowell101 @cote @carminerimi @phool_stormer

LeaderBoard

#devopsClouderati on DevOpsWho will beat AWS in enterprise cloud? Top thought leaders discuss the news around cloud #devops

#devopsClouderati on DevOps #AWSSpecial DevOps for #AWS Re:Invent yearly cloud event. We will discuss the magic of CrowdChat on AWS

Stream Ended

Establishing a secure connection

Is Automation in a place that is good or is there more work needed?

[+] Show Hidden Comments

There is so much more work needed. We are a lot further along than we were, say 10 years ago, but there are still serious challenges with parts of the stack still not having good API access, humans are still doing too much manual work, etc.

Yes :) W/o automation "it" does not happen. But we have seen automation become a run away nightmare. Step one one troubleshooting for example - "turn off the automation"

Automation is in a good place for sure. #DevOps (esp. at scale) is barely possible without recent advances. But more still needed.

Patrick Hoolboom

There will ALWAYS be more work needed in automation...but I do believe we are at an inflection point. Adoption will increase quickly as will power.

@jfryman The API point is a great one. Good blog that @cote pointed out in newsletter recently re: VMware's "API"s.

Automation is just the beginning. Operational process optimization takes more than just automation and it should be a stretch goal for devops if it isn't already.

e.g. infra, test, release automation are core to #DevOps; but automation is still lacking in N/W, dB, sec and esp. on enterprise platforms.

Automation is just the beginning. Operational process optimization takes more than just automation and it should be a stretch goal for devops if it isn't already.

ThirdWave Insights

@lmacvittie Your point on process optimization is important... Automating a task is quite different from automating a significant portion of a life cycle.

@jfryman do you think orchestration is fantasy til automation moves along or can it be parallel dev paths?

Patrick Hoolboom

@lmacvittie Process optimization in Operations will be huge. Codifying process to abstract out patterns will be key. Eliminate unnecessary cruft while promoting actions with highest value return.

@3rdwaveinsights Yes yes YES. Processes are not tasks... but that distinction goes along with viewing ops as an integrated entity rather than as a discrete set of functions being managed ;-)

@3rdwaveinsights IOW, we're a ways off from getting to a systems view of ops. But at least we're on the right path...

@lmacvittie @3rdwaveinsights Got it, I think. @phool_stormer sometimes talks about open sourcing (via automation code) your ops patterns. Which suggests you better first know what they are. Similar thought?

@lmacvittie +1. I think that these actually play hand-in-hand. Good automation really looks at solving the problem based on the workflow, finding choke points, and eliminating the problem with automation. Process optimization is a natural next step.

can someone define "orchestration" in this #DevOps context? I'm curious what people think it is beyond/above "automation."

I think they happen in parallel. Automation really only focuses on the micro (task, at a domain level), and orchestration on the macro (tasks assembled to accomplish a unit of work).

having the workflow documented is the first step, and in my mind that constitutes a basic orchestration of sorts (manual + automatic steps) that then informs your priority/goals of automation

@cote I have a vague hierarchy in mind, task automation --> process automation --> orchestration. In #DevOps context, I see automation as within boundaries, orchestration between them. Not definitive, but how I think of it.

ThirdWave Insights

@lmacvittie As you said, we are way off getting a systems view...deeper discussions about the science behind "devops" rather than just culture is creating the right paht.

@AndiMann +1 I like that hierarchy, I think it logically extrapolates from one step to the next.

@AndiMann If we look to BPO and its evolution it's easier to see the progression. They've already done this... so has dev through Six Sigma...

Sarbjeet Johal10

Every enterprise always did development and operations the DeOps goal is being these two entities together. So everyone is doing DevOps but degree varies. As more and more developers and operators are training on automation your DevOps rating will increase

[+] Show Hidden Comments

great point about bringing the two worlds together

ThirdWave Insights

@furrier Your point about "orchestration is a fantasy until..." leads into a deeper thought I have been struggling with: It the distinction between provisioning, automation, orchestration actually creating barriers. For example, why not automate orchestr.

@3rdwaveinsights How w/d you automate orchestration? We are starting to see "automation as a service" in production in big shops. Horrible acronym, but powerful concept I think. Your thoughts?

OK lets get the people conversation going. What does a DevOps person look like? Skills etc

[+] Show Hidden Comments

coders who can engineer not just administrate. Node and integrated stacks; zero provisioning issues (manual) speed is key to success

Patrick Hoolboom

...or the other way. Ops Eng who can code. It naturally lends itself to turning out DevOps oriented tool sets.

whether dev, QA, ops, manager, product mgr, etc.: people who are curious and want to explore new things. Few will ever have the "can do everything" utopia, but people can at least learn & block less to protect their comfy cube of ignorance.

@phool_stormer This is what i'm seeing as well; it's not about just Dev or Ops but engineering talent

SW Developers with an interest in Operations - everything from Application Ops to Deployment to Infrastructure

in the enterprise-y space, equally vital to "engineers" are making sure management and "business owners" are aligned. If you build a great appdev pipeline, and the money people don't care, it's likely a waste of your effort.

we can also look at how Agile Development played out in the 2000s for similar patterns and tips/tricks.

@cote True. I think cost savings, repeatability, and delivering business more quickly are great drivers for business owners.

@cote True. I think cost savings, repeatability, and delivering business more quickly are great drivers for business owners.

@cote True. I think cost savings, repeatability, and delivering business more quickly are great drivers for business owners.

@cote I think the latter point is key. The end goal is business enablement, not automation mecca. How do you find companies tackle the balance between the pipeline development and pipeline usage wrt automation?

Patrick Hoolboom

@cote Yes! It can be quite an uphill battle getting adoption for DevOps tactics if management is not on board.

I'd argue that the Agile world crested at penetrating the business side of things, and that #DevOps has to be sure to "penetrate"/infect/turn the business to be long-term successful

There's a big difference between coding (an application) and coding (a script for automation or simple integration). That distinction needs to be made. We aren't talking full on app dev, we're talking scripting and targeted code.

There's a big difference between coding (an application) and coding (a script for automation or simple integration). That distinction needs to be made. We aren't talking full on app dev, we're talking scripting and targeted code.

ThirdWave Insights

@cote Agree with your penetration point.

@lmacvittie +1. Can scripting be a slippery slope though? We've seen orgs go through to refactor scripts in a way that basically turns them all together into a control plane. Is that just us? (self selection bias). Anyone else see it?

@epowell101 Absolutely can be a slippery slope. Discipline is necessary as is starting with design. It's not just the coding pieces of agile we need to adopt in ops.. it's the system-level approach up front we also need

@epowell101 Absolutely can be a slippery slope. Discipline is necessary as is starting with design. It's not just the coding pieces of agile we need to adopt in ops.. it's the system-level approach up front we also need

@epowell101 Absolutely can be a slippery slope. Discipline is necessary as is starting with design. It's not just the coding pieces of agile we need to adopt in ops.. it's the system-level approach up front we also need

ThirdWave Insights

@epowell101 Automating/scripting can be a slippery slope when the maintenance cost associated with lots of changes cause the ROIs to go negative.

@3rdwaveinsights Lots of changes to the automation itself? Do you get into the DevOps people, process, tools needed to author the automation for the DevOps people, process, tools?

Crowd Captain16

Steve Jobs said all Network Engineers need to learn how to code? thoughts on this http://www.jedelman....

Steve Jobs Thinks All Network Engineers Should Learn to Code
With some downtime this weekend, I was able to watch a few documentaries on NetFlix. There were a few great ones on Mark Zuckerberg, Warren Buffet, Mark Cuban, and Steve Jobs. Many of them came...

[+] Show Hidden Comments

I think at a core level, operators who interface with computers should understand their own domain language, and a common 'glue' language. The first is to automate their own domain, and the latter is to enable usage of their domain by others.

Devops == 100% of infrastructure as code.

Everyone needs to learn how to code! From my CMO needs to my 14 y.o. niece, so you bet N/W engs. need to code!

There's a difference between coding (to develop an application) and coding (to script for automation). That distinction needs to be made, because we aren't talking about needing to be app developers, we're talking about needing basic coding / scripting.

@AndiMann +1 Fundamental. It is getting easier to code. See iPhone apps. See higher level languages. Not saying easier to code *well*.... In any case this is leading to more and more coders, right?

@AndiMann I agree with this as well. I think in the future we'll see a different type of coder. Today, we run into challenges with domain language between experts and developers. Future devs will *be* domain experts with the ability to code.

@epowell101 Higher level languages != easier code. IN many cases, they're more difficult because they're less rigidly defined. See Ruby as a good example.

@lmacvittie Good point. Still, growth in # of devs including those wearing an ops badge seems like a driver of change?