Tag Archives: DevOpsDays

DevOpsDays does London – 2016

After two years off, this week saw the return of the DevOpsDays London. Since that double header in 2013, when London hosted the event twice – to coincide with the O’Reilly Velocity conference – there have been more than 50 DevOpsDays events globally.

This year’s event was an interesting combination of seasoned DevOps professionals who’ve been on the speaking, engineering or consulting circuit long enough now to be considered “veterans” and a gathering of “green horns” – who were either about to start or just starting their DevOps journey. For many, judging by the show of hands, this was their first DevOpsDays experience.

Against a back drop of a much swisher and larger scale venue than the eclectic St Mary Ward House venue which hosted previous DevOpsDays London – came the wide array talks and open spaces sessions.

Compared by a team from Barclays and Accenture, the opening session came from the wonderful Bridget Kromhout from Pivotal. The tone and content of her presentation, set the scene perfectly as she reflected on some DevOps 101 fundamentals, reinforcing the cultural elements and setting out that DevOps is not just about automation. There was also a clear message to both vendors and consultancies that DevOps is something you have to practice and not something you simply just buy in.

Next came the equally impressive, Joanne Molesky from Thoughtworks. Her insightful talk, from someone who didn’t start life as a hardcore technologist, set out her view on why large organisations are struggling to adopt the organisational change needed to successfully practice DevOps, noting that this change is not mandatory and neither is survival, but that today, the biggest risk faced by all business is not to change anything. Her advice included moving from a project to a product centric focus, and reminding us of Deming’s PDCA model – Joanne asked us to consider that measuring value and learning from failure be key to our DevOps journeys’.

Kris Saxton’s refreshing talk Bi-Model IT and Snake Oil, provided a strong and damming case against adopting the notion that your organisation needs an “us” and “them” approach within IT. His view that Mode 1 – Slow & Steady versus Mode 2 – Agile & Lean, as defined in the Bi-Model view of organisations, not only doesn’t work, but is counterproductive, kills innovation and creates a poisonous culture within organisations. Both the tone and content of his talk were superb and I highly recommend you consider his views carefully, if your organisation is discussing Bi-Model IT today.

photo credit: @bridgetkromhout

Fuelled by caffeine, the audience was next treated to a timely and extremely impressive tech talk, which included one of the slickest demo’s I’ve ever seen delivered at a conference. Casey West from Pivotal delivered his view on a Minimum Viable Platform, complete with an implementation in Cloud Foundry. Casey set out his 6 point Minimum Viable Platform which included;

  • Dynamic DNS, routing and load balancing
  • Backing services broker
  • Infrastructure orchestration
  • Health management, monitoring and recovery
  • Immutable artifacts repository
  • Log aggregation

For lots in the audience, they were finally getting a dose of the DevOps technology they’d come to see after a morning of culture and practice focused presentations and Casey didn’t fail to deliver.

Thiago Almeida, Tech evangelist at Microsoft, took the last formal presentation slot of the morning, with the very impressive story of DevOps transformation at Microsoft and some lessons learnt from collapsing silo’d development, test and operations people into cross-discipline, self-managing features teams. As part of the new focus, he highlighted how feature teams have become obsessed with understanding customers and the benefits this has brought in delivery high value solutions. What’s impressive in this story, is not simply the scale of what Microsoft have done, but more the speed at which they have managed to achieve their DevOps transformation.

photo credit: @ClaireAgutter

One of the big takeaways from this talk, was how DevOps had delivered a better work/life balance and this was highlighted in the #Microsoft staff survey. Burn out, is such an important and under discussed subject in our industry that is was great to see a major enterprise organisation highlighting the importance of finding better ways of working.

The morning session was concluded with a set of well delivered Ignites, Claire Agutter covering DevOps & ITSM, Ben Wootton describing Vendor vs Partner relationships in DevOps, and finally the highlight – “four things I learnt about DevOps when my car was engulfed by flames” by John Clapham. John’s entertaining talk did have a very serious undertone of lessons learnt with a key message being “Don’t just plan for disaster. Expect it. Plan for it.” Wise words.

After lunch, DevOpsDays familiar open spaces sessions took place. The diversity of talks offered didn’t fail to disappoint, and there was certainly something to appeal to technical and non-technical alike. Although the large conference space didn’t well suit open spaces, the organising team did a decent job of adapting the venue to suit, however it proved difficult for these sessions to really get flowing, partly because of the noise in the room from conflicting sessions and partly as some sessions had more than 50 people. Having said that, the participation in the talks was faultless and the content was great, even if some did struggle to understand that sessions start when they start, end when they end and can deviate from the original topic. Community events do require some moderation, but sometimes it’s difficult for some to adapt to the free form nature of these sessions, which allows discussion to ebb and flow. It was therefore a slight shame, that the formality of presentations was again introduced in the afternoon, but Justin Cormack did a good job of bringing security to the forefront, maybe such an important topic should have been central to the theme and given more prominence.

photo credit: 

The evening event provided a great opportunity to continue some excellent conversations well into the night. Here the venue came into its own with a large open space, bar and restaurants, making it easy for the discussion to continue without interruption.

photo credit: 

Day 2 kicked off with Kris Buytaert regaling tails of the 6.5 years of DevOpsDays. His talk allowed him to reminiscence on the history of the event, but also to outline some of the core ethos and characteristics that have made this event so successful globally.

Next came a new comer to the DevOps space by the name of Gene Kim. For his first time giving a talk on DevOps, Gene’s perceptive talk on the impact on DevOps becoming mainstream, seem to contain an awful lot of scientific materials and fact. For someone, so new to the industry his ability to gain such insight was simply astounding. Contained in the metrics, was the cold hard fact that this DevOps thing is delivering even more business value than we ever thought possible and that being 200x faster is creating decisive winners and losers in the marketplace. His talk covered many lessons learnt and examples from across the industry, all of which has culminated in his second book the “DevOps Handbook”, which we hope to see released shortly. Well done Gene, it seems you might have a bright future in this space.

As someone, said – “only Gene Kim can follow Gene Kim on stage” and so it was with the panel session up next. With representation from Barclays, Thoughtworks, Deloitte and Pivotal the all-star session was set to be ground-breaking. Disappointingly, poor audio and moderation combined to make this session pretty unengaging, and it failed to deliver the expected energy and open interaction from the crowd.

After the break, Gareth Rushgrove took back control of the energy and the crowd with a punchy and engaging talk on Rates of Change, Microservices and Platforms – a tale of devops coevolution, and it was tonic to those suffering a bit of day 2 conference fatigue. The clean and simple presentation was laden with facts and metrics – backed up with a good dose of science. With reference to culture, process and technology Gareth demonstrated that there are good practices for team structure, concluding that there are no single perfect team patterns for DevOps but that there are many bad patterns. The http://web.devopstopologies.com/ provides some excellent discussion on Team Structures that might be Right for DevOps to Flourish.

He continued by explaining the bi-directional relationship, as defined in Conways law, that software you use or build can be changed by changing your organisation or that your organisation can be changed by changing the software you use. He continued by exploring the coevolution, a concept rooted in biology, which considers systems as comprising both a “technical” and “social” system. The joint optimisation of both systems, leads to better results and Gareth drew direct comparison to DevOps as an example of this optimisation, stating that organisational change or technical improvement alone provide sub-optimal improvement. In short, DevOps requires both cultural and technical optimisation, to recognise the full benefits.

Jeromy Carriere closed the last formal session of the day with his talk, Enterprise Ops Rising, highlighting numerous operational and security challenges organisations are faced with when deploying systems microservices at scale in the cloud, balancing against a drop of standards, compliance and legacy code. Jeromy, touched on both technical and cultural aspects of employee empowerment, drawing in the topic of fear and touching on blameless post-mortems.

Photo credit: @squire_matt

A series of entertaining Ignites followed the highlight of which was defiantly Oliver Wood taking us to an entirely new place with his talk “You don’t scale” looking at “HumanOps”. Oliver covered the extremely important subject of Burnout and Health. “We adopted the slogan ‘go live or die trying’ because we are idiots.” was a highlight from his inspirational talk.

Photo Credit: 

Open spaces sessions in the afternoon saw a smaller number of topics than day #1. The sessions covered certification, security, post mortems and maturity assessments, with @michal_wojciech concluding that “all organisations need to bring their IT security teams to a DevOps conference”.

Overall it was an immensely enjoyable two days, and the massive amount of hard work the organisers had put in clearly showed as the event was run smoothly, with tons of positive feedback on content and discussions. The event however had taken on a much more “enterprise” feel, which was a slight shame given that this community event is a month before the DevOps Enterprise Summit. Unfortunately a low point of the event was the abandoning an entire Q&A session following one of the best talks of the conference, to allow the vendors their pitch slots. I think the audience and nature of the event should consider a more lenient approach to the schedule. In fairness the quality of speakers, discussion and venue overshadowed any negatives and it was a thoroughly enjoyable 2 days at a great conference.

As Caroline Donnally said, “Sign of a good conference is leaving it with a head buzzing with all the new stuff I’ve learned and can write about”

photo credit: @johnC_bristol

Thanks @DevOpsLondon2016 – we had a blast.

Meet the DevOpsGuys @VelocityConf & @WebPerfDays

This week is a full on conference-fest for the DevOpsGuys!

@TheDevMgr will be doing a lightening demo at Velocity Conf on www.worldwidepagetest.com (a global testing front-end for www.webpagetest.org)

Then the @DevOpsGuys will have “Office Hours” at Velocity at 10.45am on Thursday.

@TheOpsMgr will be hanging around Velocity all week while furiously sorting out last minute details for WebPerfDays London 2013 (which is now Sold Out but there are some tickets still available for the “After Party” on Saturday night I you want to come and hang out post-Velocity).

We’ll be around in the Hilton Metropole bar on Wednesday night if you want to come over to say hello. Just listen out for the loud Aussie and Welshman and that will be us…

This week in DevOps #3

Hey, it’s that time again and this week I start with an apology as we missed a week due to the awesome DevOpsDays London and a not so awesome bout of Tonsillitis.

DevOpsDays London

DevOpsDays London – easily the best conference/unconference I’ve ever attended. Great people, great speakers, OpenSpaces was awesome, food was good and to top it all off – free beer. Sadly, I missed the Saturday due to illness (not caused by the free beer, or the Wales Vs England rugby game).

Highlights;

  • @niekbartho gave a solid opening presentation, monitoring his heart rate as he went. Some good real world advice and a story from the trenches is always a nice touch. I felt the story was a little more focused on continuous delivery, rather than DevOps. Niek did clarify the term “Snowflake Server” very nicely as being “a server having configuration as unique as a snowflake, and no one has a clue how it was built!” Thanks Niek.
  • @johnC_bristol  gave us an insight into key cultural aspects of DevOps and how they monitored them at Nokia. It was a really interesting insight into how culture affects DevOps with some real information to backup theory. John completes a study with involvement of over 50 employees and presented some interesting findings.
  • @DavidMytton gave a great insight into bootstrapping a startup. Some good advice on life hacks relating to Startups relating to mobile usage, travelling, etc. His advice was wide ranging, but our favourite item was on task automation. “Do it once, Learn, automate!” — Thanks David. The ServerDensity team have produced some content DevOps Dayers which is worth a read.
  • In the final presentation before the ignite sessions, Deri Jones enlightened us on using metrics to calculate lost sales. His content focused on ensuring that all the great metrics captured by DevOps should be translated back to business measurements.
  • The ignite sessions brought some great fast paced presentations. I really enjoyed @simonvc on “How schemaless databases fit into the continuous delivery world”. His thoughts;

My final thoughts on DevOpsDays; awesome people, awesome event format but even at a DevOps event, it was surprising how many different ways people interpreted the terms DevOps. Here a just a few;

  • DevOps  … is a movement, a philosophy, a way of thinking.
  • DevOps  … is a person who can perform both Dev and Ops roles.
  • DevOps … means cross skilling people.
  • DevOps … is continuous delivery.
  • DevOps … is a team of developers and operation staff.
  • DevOps …is a culture movement.
  • DevOps … is monitoring.

I have my views on what DevOps is and more importantly is not. It seems that there is still some teaching to be done!

Thanks to all those at DevOpsLondon 2013. It was great to meet you.

What we found this week

  • Citrix outfits NetScaler with troubleshooting tools to help sysadmins troubleshoot the cause of poor application performance from multiple data centres, cloud services and networks. NetScaler can emit performance data in the AppFlow format, which third-party diagnosis tools such as Splunk.
  • The benefits of DevOps are numerous. First and foremost, there is more collaboration and trust within an organization. Where are you on the timeline? Where do you want to be?

Tweets of the Week

  • @patrickdebois: Mgmt wants us to replace shell scripts to become devops, /me Do they work now? Yes /me I suggest you find your real bottleneck.
  • @rposbo: Loving that there’s no DevOps Manifesto; just get everyone on the same goal, automate what you can, don’t be evil!
  • @withneedle: Pro tip: Changing everyone’s title to “#devops engineer” will not magically make it so.
  • @DevOpsBorat: In startup we are only use technology if is cover in blog of expert devops on benchmark is run on own laptop.
  • Interesting Idea. The Twelve Factor App is a methodology for building software-as-a-service apps  that can be applied to apps written in any programming language, and which use any combination of backing services.

This week in DevOps #1

TWIDO

We hate acronyms, but this one’s kinda catchy. This Week in DevOps (TWIDO) [[[ yeah, yeah, we promise not to use it again]]], is going to be a Friday round up of stuff we found interesting this week.

We’d love you to contribute, if you have articles, research, tweets on any other stuff you’d like to share, please get involved.

#1:  Q&A From Building a DevOps Team That Isn’t Evil

Q: How have auditors been ok with a devops model where devs have access to prod? e.g., continuous testing, automation, version control, logging, etc?  is one single dev allowed to push a code chg thru the entire process?

Few public companies allow a developer to go from change to production, or access production databases directly. There may still be roles with responsibility for building new features and others that operate on production. The goal is enhance the flow of knowledge between the people in those roles, and for there to be some joint responsibility. For instance, logs may be exposed to developers without giving access to the production box. I think the team at Stackify is trying to make a business around exactly that.

http://architects.dzone.com/articles/qa-building-devops-team-isnt 

Commentary

DevOps does not equal developers managing production. It’s aimed at promoting understand and collaboration between groups.  Thanks to Eric Minick from DevOps Zone and UrbanCode for supporting this.

#2: IT stability and business innovation are not enemies.

Q: DevOps promises a more responsive, more collaborative IT department that can realize business ideas faster. So what is holding back its widespread adoption? What’s the challenge or downside?

DE: There was a movie called “Charlie Wilson’s War” that had a great line between Tom Hanks, playing a U.S. Congressman, and Philip Seymour Hoffman, playing a CIA agent. Hoffman asks, “Why is Congress saying one thing and doing nothing?” Hanks replies, “Well, tradition mostly.”

All jokes aside, tradition is a powerful thing and hard to break. Tradition, or “what we’ve always done,” in IT is no different. There was a thread on Slashdot just this past month that asked whether developers should be allowed to deploy their own applications. You should have seen the outcry. The sheer number of commenters who shot down the idea as pure heresy was shocking. And the richest part of all of their denunciation was that the mob said over and over that the idea would “never work at a real company with real revenue at stake.” I thoroughly enjoyed sending that to John Allspaw, who runs all of technology at Etsy, and Jesse Robbins, who was in charge of risk and disaster planning for operations at Amazon. Etsy does over $600 million of transactions per year, and Amazon does about $50 billion in revenue. In both companies, developers are the ones who deploy and own the uptime for their own code. John’s reaction to the thread was a simple yet priceless one: “OMG.”

http://dev2ops.org/2013/02/

Commentary

Empowering development, operations and even QA teams to take ownership of code deployment is crucial for DevOps teams. It ensures that developers work with operations to understand the impact of change and take accountability/ownership for the “uptime of thier own code”. It also ensures that operations understand what changes are coming and how best to support the change. Uptime is a shared responsibility  with the environment the code executes within and the code that is executing both factors that must be managed correctly. 

#3 – StartOps: Growing an ops team from 1 founder

Bootstrapped startups don’t have the luxury of a full team of ops engineers available to respond to issues 24/7, so how can you survive on your own? This talk will tell the story of how to run your infrastructure as a single founder through to growing that into a team of on call engineers. It will include some interesting war stories as well as tips and suggestions for how to run ops at a startup.

http://devopsdays.org/events/2013-london/

Commentary

We are really looking forward to this track at DevOps Days London. DevOpsGuys are attending. Would be great to meet some of you.

#4: Engineering running the production environment

http://devopsreactions.tumblr.com/post/43882100705/engineering-running-the-production-environment

Commentary

Both funny and awesome! Nuff said!

#5:  Top 10 Practices for Effective DevOps

Practice 1: Active Stakeholder Participation

A fundamental philosophy of DevOps is that developers, operations staff, and support people must work closely together on a regular basis. An implication is that they must see one other as important stakeholders and actively seek to work together. A common practice within the agile community is “onsite customer,” adopted from Extreme Programming (XP), which motivates agile developers to work closely with the business. Disciplined agilists take this one step further with the practice of active stakeholder participation, which says that developers should work closely with all of their stakeholders, including operations and support staff–not just business stakeholders. This is a two-way street: Operations and support staff must also be willing to work closely with developers.

Practice 6: Integrated Deployment Planning

From the point of view of development teams, deployment planning has always required interaction with an organization’s operations staff; in some cases, via liaison specialists within operations typically called release engineers. Experienced development teams will do such planning continuously throughout construction with active stakeholder participation from development, operations, and support groups. When you adopt a DevOps strategy, you quickly realize the need to take a cross-team approach to deployment planning due to the need for operations staff to work with all of your development teams. This isn’t news to operations staff, but it can be a surprise to development teams accustomed to working in their own siloed environments. If your team is not doing this already, you will need to start vying for release slots in the overall organizational deployment schedule. Furthermore, to support continuous deployment, release engineers will need to increase the number of release slots available to agile teams that are disciplined enough to continuously and consistently meet the quality requirements for release.

Practice 7: Continuous Deployment

Continuous deployment extends the practice of continuous integration. With continuous deployment, when your integration is successful in one sandbox, your changes are automatically promoted to the next sandbox, and integration is automatically started there. This automatic promotion continues until the point where any changes must be verified by a person, typically at the transition point between development and operations.

Continuous deployment enables development teams to reduce the time between a new feature being identified and being deployed into production. It enables the business to be more responsive. However, continuous deployment increases operational risk by increasing the potential for defects to be introduced into production when development teams aren’t sufficiently disciplined. Successful continuous deployment in an enterprise environment requires all the practices described earlier.

Commentary

Overall we found this article rather in conflict with itself. It’s interesting how the author views Operations and Development as separate stakeholders within a process. The principles of DevOps are to break this view and to combine Development and Operations as a single entity and in this context they should be considered a single StakeHolder.

We fully agree that Operations should be managers of production with development participation, as Developers should be mangers of development with Operations participation, but on deployment we differ with the author. It’s easy in our view. If operations are a bottleneck to deployment, expand the role of “release engineers” to encapsulate the entire team. Anyone should be able to take accountability for and action deployment if the correct principles and practices have been applied.

The author also battles with Continuous Delivery principles. “release engineers will need to increase the number of release slots available to agile teams”. If you adopt a continuous delivery process your actually going to reduce the number of release slots, to one. One continuous release slot. Hence Continuous Delivery.

http://www.drdobbs.com/architecture-and-design/top-10-practices-for-effective-devops/240149363

#5: Tweet of the Week

Every #ITmanager, no matter how strong he is, lies to himself about his #DevOps initiative. I will find your lie. I will break you