View All Videos

Archive for the ‘Business Impact’ Category

DevOps and Technical Debt: A Debt Crisis in Your Workplace?

37

Damon Edwards / 

With all of the recent global financial news being dominated by various debt crisises, this seems like a fitting time to point out that there is another type of debt that is rampant in IT organizations as well.

This type of debt also sneaks up on you if you aren’t keeping an eye on it and it too can have devastating effects. I’m talking about Technical Debt.

Technical Debt is already well known in the Agile circles as way of quantifying the deficit created by cutting corners on code quality or completeness in order to speed business feature delivery. The “Technical Debt” is the difference between doing something good enough for now rather than doing it right.

The debt metaphor is used because it implies that the organization has taken on liabilities that must be “repaid” (i.e. fixed) at some point in the future. The further along in development you move without getting rid of that debt, the more the debt grows. And like monetary debt, there is a nasty compounding effect at work here as well.

 

My favorite short explanations of the main points of the metaphor are:

  • Skipping design is like borrowing money
  • Refactoring is like repaying principal 
  • Slower development due to complexity is like paying interest

Folks like Ward Cunningham, Martin Fowler, and Israel Gat do a much better job of explaining Technical Debt than I do and I highly recommend reading their work.

So what does this have to do with DevOps? I think it’s becoming increasingly clear that DevOps problems can best be approached and quantified using the concepts of Technical debt. I hear people all the time digging themselves into deep holes of DevOps problems with mindset of “lets just get these features out the door first and then we’ll come back and fix our process and automation issues”. They are taking on massive amounts of technical debt and are usually lacking a way to quantify or account for it.

Let’s try the above definitions on for size with one particularly common DevOps problem — missing or poor quality automation:

  • Missing or poor quality process automation is like borrowing money
  • Implementing and improving process automation is like repaying principal
  • Slower pace of innovation and poor execution due to missing or poor quality process automation is like paying interest

It does seem to fit quite well. And the best part? Aside from being a concept that forward thinking developers have already embrace, Technical Debt has also been proven to be a persuasive metaphor at the executive level. Now we just have to port these ideas and vocabulary to the mainstream of the DevOps movement.

The next time you are struggling to convince an executive to fund and support DevOps work, remember to looking into using tried and true Technical Debt arguments.

Below is an except from a recent video interview I did with Israel Gat of the Cutter Consortium. In this segment he goes into what technical debt is and how it can be used to prove the cost of not “doing it right”.

 

Update: If you are at Agile 2011, go see Israel speak at one of his sessions. It’s worth it. His session on Wednesday, ‘Super-Fresh Code’, promises to be of interest to anyone grapping with DevOps issues.

 

DevOps Days Mountain View 2011: Escaping the DevOps Echo Chamber (Video)

36

Damon Edwards / 

“Escaping the DevOps Echo Chamber” panel at DevOps Days Mountain View 2011.

Gene Kim (Founder of Tripwire / Author of “Visible Ops”)
Ernest Mueller (National Instruments)
Lee Thompson (Hewlett-Packard)
Tom Grant (Forrester Research)
John Christian (TSYS)
Jez Humble (Thoughtworks)
John Alioto (Microsoft)

Moderator: Damon Edwards (DTO Solutions)

See all videos from DevOps Days Mountain View 2011

DevOps Days Mountain View:
http://devopsdays.org/events/2011-mountainview/

Special thanks to LinkedIn for hosting DevOps Days Mountain View 2011.

Also, thank you to the sponsors:
AppDynamics  DTO Solutions  Google  MaestroDev  New Relic  Nolio
O’Reilly Media  PagerDuty  Puppet Labs  Reactor8  Splunk  StreamStep
ThoughtWorks  Usenix

 

DevOps Days Mountain View 2011: LinkedIn’s DevOps Journey (Video)

43

Damon Edwards / 

Stefan Apitz gives a short presentation at DevOps Days Mountain View 2011 about the ongoing DevOps journey at LinkedIn.

See all videos from DevOps Days Mountain View 2011

DevOps Days Mountain View:
http://devopsdays.org/events/2011-mountainview/

Special thanks to LinkedIn for hosting DevOps Days Mountain View 2011.

Also, thank you to the sponsors:
AppDynamics  DTO Solutions  Google  MaestroDev  New Relic  Nolio
O’Reilly Media  PagerDuty  Puppet Labs  Reactor8  Splunk  StreamStep
ThoughtWorks  Usenix

 

DevOps Panel at Interop 2011 Las Vegas (Video)

28

Damon Edwards / 

Interop is often thought of the land of big hardware and big networking. Take a tour around the massive exhibit hall and you’ll witness a sea of marketing dollars from hardware, networking, data center design, and storage vendors.

But as I walked around in on of my DevOps t-shirts (DevOps Days Boston to be precise) I was surprised by the number of conference attendees who made a comment or struck up a conversation with me about DevOps.

DevOps was definitely on a significant number of people’s minds. Further evidence? The DevOps panel was one of the last sessions of the 5 day conference yet a sizable crowd stuck around and peppered the panelists with engaging questions.

Below you’ll find the video from that lively “DevOps and You” panel at Interop Las Vegas on May 12, 2011

Panelists:
John Willis (DTO Solutions)
Shlomo Swidler (Orchestratus)
George Reese (enStratus)

Moderator:
Mike Fratto (Network Computing Magazine

The Five Why’s of Cloud

The Five Why’s of Cloud

53

John Willis / 

 

Editors note: This is the first post by our newest dev2ops.org contributor, John Willis.

 

 In my “cloudy” travels from Cannonical, to Opscode, to DTO Solutions, I often ask a seemingly simple question to the companies I meet – “Why do you want to use the cloud?” – and I get an array of amazingly unsatisfying answers.

Some people cite the classic 8-weeks-to-8-minute provisioning use case. Some people regurgitate the analyst answer of “for the ROI of (insert magic number here)” . Of course there is always the CAPex vs OPex answer. Now I am no financial type, but I’ve been around enough to know that in many types of businesses, OPex is more of a dirty word to the CFO than is CAPex.

Every once in a while I get a more informed answer like “I want to go to the cloud for agility”. But the usual lack of depth behind the answer proves to be just as unsatisfying.

 

The 5 Whys Epiphany

The other day I was having a conversation with my good friend Michael Cote and it hit me as to why I never get the depth of answer that I am am looking for. I have not been asking the right question(s).

Many of of us in our industry have learned and adapted many techniques and methodologies from Toyota’s lean manufacturing models. One of my favorites is the applying the “Five Whys” technique to determine a root cause of a problem. Therefore, I started applying the 5W’s during my informal surveys.

Here is an example of one of those conversations:

Question 1 – Why do you want the Cloud?

Answer: To decrease provisioning time.

Question 2 – Why?

Answer: So we can get servers provisioned in 8 minutes instead of 8 weeks.

Question 3 – Why?

Answer: So developers can get resources quicker to get there job done faster.

Question 4 – Why?

Answer: So they can get features out to customers faster.

Question 5 – Why?

Answer: So we make more money faster.

Aha, so that is why they wanted their cloud, to make more money and make it faster. At this point if I had more time I would start another line of questions (unfortunately I usually don’t) that begins with “Will the cloud do that for you?”.

Any of you who have been working with the cloud in a business for more than a year already know the answer to that question – Not out of the box it won’t. But dispelling the myth that Cloud alone solves all problems is not my point here.

My point is that the real question/answer I should have gotten to my initial “Why Cloud” question is that last question/answer after 5W’s. The real answer regarding “Why Cloud” should not focus on technical feature, it should be be based on specific business goals. Ask the 5W’s until those true goals are clear to everyone. Don’t doubt the power of “Why?”.

 

Begin With the End in Mind

They now teach to kids in elementary schools the idea of beginning with the end in mind. Its a lesson we can all learn from.

I like to use my cell phones in Russia analogy. When Eastern Europe opened up to capitalism, they didn’t go out and order land line phones all over the place. They knew from recent history that it was much easier to create new phone networks via cell phones. The began with the end in mind.

All too often, smart people lose site of this simple idea when it comes to the cloud. Getting a cloud is not the goal. The goal is to achieve a specific business objective (i.e., the root cause of why you want a cloud). Therefore if your real goal is “We want to make more money faster” then let’s map out the full path to get there.

I often describe the cloud as a big fence that comes just up to everyones eyebrows. It looks really cool but you can’t quite see what’s over the fence. I try to urge people to use a step ladder to look over the fence and see the longer journey. Most people will see that whats beyond the fence is not the end of the journey, but just the beginning.

Depending on what your business goal is, the end state which probably will include a cloud. But in almost every case, the end state will require far more than just a cloud.

 

In Cloud We Trust

I often hear in my travels the remark that “I thought the cloud did that”. It amazes me that an organization will first implement a cloud and then start asking questions like “where is the autoscaling part” or “where are the automated load balancers” or “where is the push button application deployment”. I call this the being blinded by the cloud pixie dust.

When the pixie dusts settles and they examine what their cloud really delivers, typically they will find that they are still missing what my good friend Damon Edwards calls the “abilities”. Around you cloud you are still going to need to create a strong operational infrastructure that delivers scalability, manageability, availability, reliability, flexibility, and – last but not least – agility.

In my forever quest to find the perfect cloud, I have yet to find one that comes with one big red “Abilities Button”. Sure the cloud will help with some of these — and some clouds provide more than others — but the cloud is just one tool that you will need.

Just like before the cloud, successful cloud-based operations include a hand full off glue technologies and a whole lot of additional sweat equity.

When analyzing your requirements, don’t let you thinking stop at the word “cloud”. Focus on what that actually means. Focus on ideas like:

  • Utility based infrastructure
  • Self-service resource allocation
  • Self-managing infrastructure
  • Software development life cycle support
  • Behavior driven availability

The cloud is just one part of the equation. Clouds are useful tools, but not the magic bullet. My suggestion, therefore, is to always apply the Five Why’s to make sure you know where you are going.

Adam Rosien on how Wealthfront moves fast and agile (Video)

83

Damon Edwards / 

 

Adam Rosien from Wealthfront came to the Silicon Valley DevOps Meetup on Tuesday April 5 and gave a great presentation on how they use techniques like Continuous Deployment, Test Driven Development, and their “Immune System” (think automated testing and analysis) to run fast and run agile. Wealthfront’s DevOps lifecycle challenges a lot of conventional assumptions, but the results they achieve in a highly-regulated financial services business (with already over $180M being managed) speak for themselves.

Scroll down for the full video and slides…

 

 

 


 

Special thanks to the kind folks at Box.net for hosting the meetup! 

Page 3 of 41234