Tag Archives: DevOps

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

#DevOps – Start with WHY!

DevOpsGuys presented a short 30 min talk on the “Why” of DevOps last night at the @Magentys Enterprise DevOps event (sponsored by our good friends @Dyn).

The goal of the presentation was to give the attendees some of the reasons why the current models for product development and operations might not be suitable in a rapidly changing, cloud-hosting, mobile enabled world.

One of my favourite quotes from the talk if from a HBR article by John Kotter where he talks about how business needs to change (and not just IT!). We’ll be exploring some of Kotter’s ideas in our #DevOpsMBA series of blog articles over the coming months.

“The hierarchical structures and organizational
processes we have used for decades to run and
improve our enterprises are no longer up to the
task of winning in this faster-moving world” – John Kotter

Image showing quote from Hardvard Business Review on the need to change how businesses operatte
HBR article by John Kotter – Accelerate!

The full slide deck is available below and on Slideshare.

If anyone is interested in having this presented to your teams or management at work to help kick-start your DevOps journey we’re happy to do an “encore performance” on-site (as long as you cover the travel expenses!).

5 useful #Devops lessons about flow you can learn while getting off a plane.

One of our favourite books here at DevOpsGuys is Donald Reinertsen’s “Principles of Product Development Flow”. It’s a compelling argument about the importance of “flow” – small batch sizes, frequent releases, rapid feedback, all the key tenets of continuous delivery and DevOps.

It is, sadly, not the sort of easily consumed management book that might appeal to your ADD-afflicted manager (should you be able to tear his/her attention away from his/her iPhone or iPad).

@TheDevMgr and myself (@TheOpsMgr) were discussing this last week as we landed at Munich airport to attend the @Jetbrains partner conference (we’re huge fans of TeamCity for continuous integration).

As we went thru the process of disembarking from the flight we realised we were in the middle of a real-world analogy for benefits of flow – an analogy that might be readily understandable to those senior managers we mentioned earlier.

Let’s walk thru it.

The plane lands and reaches the stand. Immediately everyone in the aisles seats un-clicks and stands up, congesting the aisle. Once the aisle is congested (=high utilisation) the ability of people to collect luggage from the overhead lockers is significantly reduced – everything becomes less efficient.

At high rates of utilisation of any resource waiting times, thrashing between tasks and the potential for disruption are likely to go up. So that’s Useful lesson #1.

All this activity and jamming of the aisle is, ultimately, futile because no-one is going anywhere until the stairs get there and the cabin doors are opened. This is the next constraint in the pipeline.

Useful lesson #2 – until you understand the constraints you might be just rushing headlong at the next bottleneck.

Eventually they arrive and we all start shuffling off like sheep (or zombies) and walk down the stairs… to the waiting buses on the tarmac.

Useful lesson #3 – if you’re trying to optimise flow you need to look beyond the immediate constraint.

In this, case the cabin door & stairs, and look at the entire system (this is the essential message of systems thinking and the “1st way of DevOps”).

The buses were fairly large and held about 60+ people each (=large batch size), and everyone tries to cram onto the first bus… which then waits until the second bus is full before both buses head across the tarmac. When we reach the terminal the buses park up… and the second bus is actually closer to the door we need to enter.

Useful lesson #4 – don’t assume that the batch size is what you think it is (i.e. 1 bus load). It might be more (2 buses!). Also, just because something looks FIFO doesn’t mean it is…

Once we enter the terminal we then hit another constraint – clearing Immigration control. Luckily we were able to go thru the EU Resident’s queue, which flowed at a fairly constant rate due to the minimal border control. But looking at the non-EU Residents queue that the flow was turbulent – some passengers went thru quickly but others took much longer to process due to their different nationality, visa requirements or whatever had caught the Border Control officer’s attention. Unfortunately, the people who could have been processed faster were stuck in the queue behind the “complex” processing.

Useful lesson #5 – If you can break your “unit of work” down to a relatively standard size the overall flow through the system is likely to improve. This is why most Scrum teams insist that a given user story shouldn’t’ take more than 2-3 days to complete, and if it would it then it should be split up into separate stories until it does.

Luckily we avoided the queue for checked luggage as we only had carry-on and we were able to get in the queue for the taxis instead… so that’s the end of our analogy for now.

So let’s think of some theoretical optimisations to improve the flow.

Firstly, why not only let the people on ONE side of the aisle stand to collect their overhead luggage and prepare to disembark, thereby avoiding the congestion in the aisle? You can then alternate sides until everyone’s off.

Secondly, why not see if you can get a second set of stairs so you can disembark from the forward AND rear cabin doors, and alleviate that bottleneck?

Thirdly, why not have smaller buses, and dispatch them immediately they are full, and thereby reduce the batch size that arrives at Immigration?

Fourthly, why not have more agents at Border Control to alleviate that bottleneck, or create different queue classes to try to optimise flow e.g. EU Residents, “Other countries we vaguely trust and generally wave through” and “countries we generally give a hard time to”. You could even have a special queue for “dodgy looking people from whatever nationality that are about to spend some quality time with a rubber glove”. Or why not create totally new categories like “those we hand luggage” versus “those with checked luggage who are only going to have to wait at the luggage carousel anyway so you might as well wait here anyway”.

These proposed optimisations might be simplistic. For example the reason the two buses leave together is probably because ground traffic at airports is strictly controlled (in fact there is a “ground traffic controller” just the same as an “air traffic controller”). So there are often constraints we might not be aware of until we do more investigation BUT the goal of any DevOps organisation should be to try and identify the constraints, and experiment with different ways to alleviate that constraint. Try something, learn from it, iterate around again.

Hopefully by using a common, real-world analogy for product development flow you’ll be able to convince your Boss to let you apply these principles to your DevOps delivery pipeline and improve flow within your organisation!
Photo credit: aselundblad / Foter / Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0)

DevOps Cardiff kicks off with a bang!

Awesome turnout and great community involvement at our first DevOps Cardiff meetup on Wednesday night!

The pizza and beers immediately after went down very well… as did the next few rounds at the excellent Urban Tap House (well, when I say a few, we headed back to the hotel, via Wok to Walk, at about 1am. I think).

people watching a presentation
@TheDevMgr leads off!

We’re super-excited that a number of people from the Cardiff DevOps community have already put their hand up to talk at future events and if you’ve got something you want to talk about, whether its a 5 min lightning demo to a full 50 min presentation, please contact us.

Thanks also to Dyn for sponsoring and FoundersHub for hosting!

The slides from the night are on Slideshare and embedded below.

The secret of #DevOps success isn’t in the IT literature (yet)!

Can you find “DevOps Success” by reading only IT literature?

The answer is “mostly No, but a little bit Yes”, for a number of reasons.

The main reason is that many of the blogs, whitepapers and webinars around DevOps are ultimately about technology and toolchains. Whilst they might reference the DevOps C.A.L.M.S model in passing the conversation is generally focussed on the A for Automation and the M for Metrics.

CALMS Model image
Culture Automation Lean Metrics Sharing

The seminal Phoenix Project did talk about organisational culture as did Mandi Wall’s O’Reilly ebook on Building a DevOps Culture.

But what both of those books have in common is that they drew extensively from non-IT business literature.

Goldratt’s “The Goal” & TOC, Systems Thinking, Lean manufacturing, Deming and Kanban being major influences on the Phoenix project, and Mandi’s e-book drawing on business-centric cultural/organisational change literature.

“Searching on the Harvard Business Review website for “cultural change” will get you 60+ publications going back nearly 30 years” – Mandi Walls

“Lean Manufacturing”, “Strategic Alignment”, “Organisational Change”, “Culture”, “Business Transformation” and many other topics have been staples of the MBA curriculum in business schools for many years and there is a wealth of resources available online to explore. Reading beyond the IT literature and exploring the wider business context for your DevOps Transformation will, we believe, significantly increase your chances of getting business buy-in and having a successful outcome to your DevOps change programme.

In order to make this easier for you we (@DevOpsGuys) will be publishing a weekly blog post exploring an area of business literature and how it can be used in DevOps.

We’re call it the #DevOpsMBA :-)

So please subscribe to our blog (link on right), follow us on Twitter or search for the #DevOpsMBA hashtag on Twitter to keep informed!