Tag Archives: DevOps

5 Definitions of #DevOps

In my talk at QCon last week I was lucky enough to be the first speaker on the DevOps track so I took the opportunity to poll my fellow speakers for THEIR definition of DevOps and the results where fascinating.

What I ended up with was different 5 Definitions of DevOps:

DaveDefinitionOfDevOps

DevOps - Matthew

DevOps - Anna

DevOps - Amy

DevOps - Steve

So what are the key take away messages from these DevOps definitions?

Firstly – there is no single, definitive version of what DevOps “is” as you can see from the responses above!

DevOps clearly means different things to different people and we (as the DevOps community) have to ask ourselves is this a good or bad thing? Good in that it’s promoting a diversity of ideas that contribute to the DevOps movement, but “bad” in that is causes confusion amongst people trying to learn more about DevOps.

Secondly – there is a clear message around communication, collaboration and culture being a key part of the DevOps message, which is excellent” #NoMoreSilos! J

Thirdly – sadly the name “DevOps” might be seen as being exclusionary in itself and not embracing critical parts of the SDLC community – specifically in Amy’s case the Test community. Amy expands on this in her blog post “DevOps with Testers”.

A number of people would say that DevOps should be called “DevTestOps” or “BizDevOps” but at QCON Dave Farley was arguing that the correct term should be “Continuous Delivery” as DevOps is just a subset of CD. We discussed this earlier in our post on Continuous Obsolescence.

  • So what does DevOps, DevTestOps or BizDevOps means to you?
  • Has the term DevOps had it’s day and should we just extend the definition of Continuous Delivery to embrace the full application lifecycle?
  • Do we need to rename our company? :-)

Your thoughts in the comments please?

-TheOpsMgr

#DevOps = #ContinuousDelivery + #ContinuousObsolescence?

During my talk at QCon last week we had started an interesting debate about whether DevOps was a subset of Continuous Delivery or vice versa.

We were lucky enough to have Dave Farley in the audience and it was clear from his definition of DevOps versus Continuous Delivery that he felt that CD was the superset and DevOps a component of that set… but he admitted that he if he was writing the Continuous Delivery Book again in 2015 would change the definition of “finished” to embrace the full product lifecycle from inception to retirement.

This aligns nicely with his co-author Jez Humble’s thoughts on being “Product-Centric” that we discussed in an earlier blog post.

“Finished” should mean “no longer delivering value to the client and hence retired from Production”.

DaveDefinitionOfDevOps

DaveOnCD

That was the we joined a new term (live on stage as captured by Chris Massey’s tweet below) – “Continuous Obsolescence”

 MasseyTweet

So what is #ContinuousObsolescence?

Continuous Obsolescence is the process of continuously grooming your product/feature portfolio and asking yourself “is this product/feature still delivering value to the customer?” because if it isn’t then it’s “muda” (waste), it’s costing you money and should be retired.

Continuous Obsolescence is the process of continuously grooming your product/feature portfolio and asking yourself “is this product/feature still delivering value to the customer?” because if it isn’t then it’s “muda” (waste), it’s costing you money and should be retired.

Every product/feature that’s not delivering value costs you by:

  • Wasted resources – every build, every release, you’re compiling and releasing code that doesn’t need to be shipped, and consuming server resources once deployed.
  • Overhead of Regression testing – it still needs to be tested every release
  • Unnecessary complexity – every product/feature you don’t need just adds complexity to your environment which complicates both the software development process and the production support process. Complex systems are harder to change, harder to debug and harder to support. If it’s not needed, simplify things and get rid of it!

I’d argue that DevOps could even be defined as
“#DevOps = #ContinuousDelivery + #ContinuousObsolescence”

If you’re doing DevOps and you’re a believer in the CALMS model then you should be practising “Continuous Obsolescence”… in fact I’d argue that DevOps could even be defined as “#DevOps = #ContinuousDelivery + #ContinuousObsolescence” – what do you think?

Send us your comments or join the debate on Twitter @DevOpsguys

-TheOpsMgr

The DevOps Revolution

“We transformed from a team of employees to a team of owners”– Jim Stoneham, Opsmatic

In a fascinating interview with Opsmatic’s Jim Stoneham Gene Kim revisits Flickr’s innovative 2009 ’10 deploys per day’ presentation.

Comparing different approaches to tackling the rapidly evolving platforms within Yahoo! Stoneham highlights the benefits of integrated working across departments, taking risks in order to learn and involving everyone, at every level with every element of the deployment process.

Working quickly, deploying frequently and developing on the fly means that teams learn faster from mistakes and are able to remain ahead of competitors, as well as responding intuitively to the needs of their audience. Teams are also more involved in the process – collaborating across departments means that everyone learns more and the product belongs to the team as a whole,  because they are all involved in every element of its creation, deployment and improvement.

Sharing knowledge and experience across teams means huge pools of resources at your fingertips. You can monitor your audience and give them what they are asking for as they need it. Working slowly to avoid risks will just lead to missed opportunities and an overall slower development. Frequent deploys and rapid responses to audience needs are vital:

When you move at that speed, and are looking at the numbers and the results daily, your investment level radically changes. This just can’t happen in teams that release quarterly, and it’s difficult even with monthly cycles.” - Jim Stoneham

Check out the full interview; a  genuinely interesting insight into the start of the DevOps revolution.

DevOps: the Way and the Light…

The absolute chaos in the wake of last Friday’s air-traffic control issues at Swanwick seems to have unwittingly shed a light on the failures of archaic large-scale IT systems and highlighted the benefits of a more ‘evolutionary’ approach, as Matt Ridley’s article in The Times eloquently describes it:

GDS…is reshaping the way in which the public sector does big IT projects to make sure cost and time overruns are history.”

Ridley celebrates contemporary approaches to development; implementing change, learning from failure, monitoring and changing continuously to optimise outputs with the user at the focus. In today’s society it is essential for governments to successfully operate large-scale services that are simple to use and which work effectively – as we can see, breakage, at this scale, is disastrous.

Operating continual monitoring, analysis, testing and development on government IT systems means that services are more accessible and less prone to breaking. Improved communication and co-working means that different skillsets are working together; pooling resources to solve problems quickly and to innovate changes as soon as they are required.

This feedback led approach will allow large-scale government systems to develop continuously, fulfilling the needs of the user as they arise and solving problems before they can impact extensively. We are encouraging an environment of communication and integration over silo-led, ‘creationist’ approaches, which have continuously failed in the past.

It is an attitude and a system that is transferrable across a variety of processes; from IT systems development to office management and work ethic. Essentially, DevOps makes the world a happier place…

Leading experts bare all about the DevOps movement

The DevOps movement is rising, and an increasing number of IT professionals are keen to adopt this new way of working in order to achieve optimum collaboration between their Development and Operations departments. The ability to react quickly to customer demands is of top priority to businesses all over the world, and the benefits of DevOps is rapidly becoming widely known as offering fantastic business value.

Rackspace has released an Ebook and infographic, highlighting The DevOps Mindset: Real-World Insights from Tech Leaders to help you realise and implement your own DevOps practices within your organisation.

The Ebook shares valuable insights from practicing DevOps leaders with a key focus on outlining the need for enhanced collaboration, measurement and sharing through all aspects of any business. The DevOps Mindset showcases unique perspectives, challenges and achievements, as well as the catalysts which led them to adopt a DevOps mindset.

By successfully balancing the technical and social side of your development and operational processes you can actively learn and advance much quicker to help achieve your company goals. An unequal development of both sides will result in automation without collaboration and a lack of thought into exactly how your ideas and services will effectively be available to your customers.

DevOps advocate Jim Kimball, Chief Technology Officer at HedgeServ says: “I think the fundamental shift toward DevOps started when we got away from focusing on individual team goals and elevated our conversation to organizational goals and let the teams drive toward them.”

“To achieve true DevOps collaboration, you need your employees to really think and act as one, not just be merged together in name only. By pushing communication from the start, everyone gets a better feel for others’ needs and how they do their jobs.” Said James Kenigsberg, Chief Technology Officer at 2U, Inc.

This awesome Ebook shapes a Q&A format and delves deeper into how this new form of agile collaboration is sweeping its way through the software and IT industries.

You will also be able to take away useful tips for business leaders considering transforming their company culture towards a DevOps methodology.

We think this Ebook from Rackspace is a grade A piece, and an asset to anyone contemplating DevOps or thinking about adopting this innovative way of reaching new levels of productivity.

Recent Rackspace study shows businesses adopting DevOps practices at a remarkable rate

What do you think – is Devops just a fad or is it here to stay? Well, Rackspace recently commissioned independent technology market research specialist Vanson Bourne to conduct this piece of research and answer that very question. 700 global technology decision-makers were surveyed and the study discovered that businesses are now recognising DevOps as an established industry with adoption figures soaring at an extraordinary rate. Companies are now seeing significant business value in implementing DevOps as part of their own everyday practices.

So let’s look at the facts according to the Rackspace DevOps Adoption Study

What was previously recognised as a niche domain and implemented by only a select few, is now seeing widespread adoption and considerably transforming the way IT is viewed across a huge range of industries.

61% of those surveyed, highlighted customer satisfaction as the key incentive for DevOps adoption, enabling businesses to deliver better value to their customers through technology, and improve inefficiency to reduce delivery time to the customer.

While utilising DevOps practices and setting clear business goals at the beginning of every project, 57% saw an increased customer conversion or satisfaction rate.

The official Adoption Study infographic highlights 66% of respondents have already implemented DevOps practices, and 79% of those who have not, plan to do so by the end of 2015.

It is clear DevOps is increasingly being recognised as delivering real business value. A massive 93% reported setting clear end goals for their DevOps initiatives, showing a definite focus on significantly improving customer satisfaction for a long-term positive impact on the business as a whole.

In a nutshell – DevOps allows businesses to consider the ways in which they organise and structure their company to initiate better ways of working. It creates opportunities for businesses to deliver better experiences to their customers faster, broaden the range of services they offer and better serve their business by using data more proactively.

A big thank you to the Rackspace Adoption Study for these incredible figures. It’s fantastic to see this industry expanding so rapidly, and we’re looking forward to seeing what the future holds in this space.

3 more #DevOps litmus tests…

We wrote back in August about 3 “litmus test” questions about #DevOps in your organisation. We’d like to add 3 more questions that focus on the more operational aspects of DevOps.

(1) Does Ops attend your Scrums?

Not every organisation can easily restructure to a DevOps model of having Dev&Ops fully integrated into cross-functional teams (or at least not at first).

But one thing we can do to build a bridge between Dev & Ops is to participate in the Agile/scrum development process.

So does Ops have representation at your daily standups? Are they participating in your sprint planning and retrospectives?

If they aren’t then you fail this DevOps litmus test!

(2) Where’s your Ops repo?

One of the key tenets of the DevOps CALMS model is A for Automation. Automation generally implies code, and code should be in source control.

We generally find that most Ops teams moving towards a DevOps model and investing in automation have their own source code repository to store their code. Some people might argue that automation code related to a specific application or service should actually be in the repo with the application code, which is also a valid pattern.

Either way – the litmus test is “where’s your Ops repo?”. If the answer is “we don’t have one”… you’re doing scripting, but you’re not doing DevOps!

(3) What’s your github username?

Ok, I know that not everyone uses Github (or Git as their DVCS) but you tend to find that most DevOps people have a github account so they can contribute back to the community by sharing their work, contributing to open source projects, creating their own projects or forks etc. I’d argue that having a basic working knowledge of git is just about a “must have” skill for modern DevOps people.

The generic form of the question for Ops people is “what’s your login details and how do you access your ops repo (from question #2 above?”. If the answer is “I don’t have one” or “only the people in the DevOps team have access” you might have created a DevOps silo that might become a barrier to wider DevOps adoption across your organisation.

-TheOpsMgr