Category Archives: DevOps

What does the future of IT Operations look like (in a #DevOps world)?

What does the future of IT Operations look like? As more businesses rely on virtualisation, containers, cloud, Infrastructure as a Service and Microservices is there still a role for IT Operations? How do these teams change to continue to deliver value when supporting Agile Operations techniques?

Is there still a role for IT Operations? Absolutely 100% (we believe that so much we started a company to offer application-centric cloud operations!).

We blogged about this back in 2013 when we said that “Devops Does Not Equal “Developers Managing Production”. We said then:

“Operations is a discipline, with its own patterns & practices, methodologies, models, tools, technology etc. Just because modern cloud hosting makes it easier to deploy servers without having to know one end of a SCSI cable from another doesn’t mean you “know” how to do Operations (just like my knowledge of SQL is enough to find out the information I need to know monitor and manage the environment but a long way from what’s required to develop a complex, high-performing website).” – @TheOpsMgr

This still holds true today.

That said, the role of Operations is changing – Ops has to become more “Application-Centric” and understand the applications that are running on the platforms they provide. It’s not enough anymore to take a narrow view that says “my servers are OK, it’s not my fault the application doesn’t work”. Well, it might not be your “fault” but you share the responsibility for making sure the application is available for your customers. Stop passing the buck!

Operations people almost certainly need to learn to code, since we are heading towards a code-driven, API enabled world.  If you can’t code (or at least have solid scripting skills) you risk being left behind will be left behind.

More importantly, the Operations Engineer/Developer of the future will be filling a role more akin to that of a “process engineer” in a physical factory or logistical supply chain.

A process engineer designs a process and production line that transforms raw materials into a finished product.

The Operations Engineer/Developer of the future will be building Digital Supply Chains and Digital Production Lines.

These Digital Supply Chains will transform raw materials (source code) via continuous integration, test automation, packaging, release automation, infrastructure-as-code etc into applications running in cloud-hosted environments.

The rate of changes flowing along the Digital Supply Chain will far exceed “old school” Change and Release methodologies – you can’t have a weekly CAB (Change Advisory Board) meeting if you’re doing multiple deployments per day (or every 11.6 seconds à la Amazon).

So, just like a physical production line includes statistical sampling, automated testing etc., so will the Digital Supply Chain of the future. We already do this with TDD/BDD, automated testing with tools like Selenium etc but it will become the Operations Engineer/Developer job to ensure that the digital production line delivers release packages of sufficient quality to ensure the stability of the application (and the organisation’s revenue that depends on it!).

Modern supply chains are complex and have many interdependencies on 3rd parties, particularly if you’re operating a “Just-In-Time” (JIT) model. Modern software applications have the ultimate in JIT dependencies due to their integrations with 3rd party SaaS API’s like payment gateways, recommendation engines, authentication gateways, cloud providers etc. Modern Operations Engineers will need to ensure that they design the digital supply chain that can cope with failures in these interdependencies, or at least ensure that they select the right 3rd party partners who can offer the right levels of performance and availability needed for their applications.

In summary, will the Operations Engineer/Developer of the future be “just managing (virtual) servers”? No, almost certainly not.

What they will be doing is designing and building complex digital supply chains with complex interdependencies both internally and externally to the organisation, digital supply chains designed to meet the needs of applications that are designed to meet the needs of their customers, safely, securely and cost-effectively.

The Q&A above is part of material prepared as our contribution to an CA ebook on “Agile Operations”. We wrote our thoughts on 6 questions, of which 4 will be used in the ebook, scheduled to come out in August 2015. You can read the earlier Q&A here –  

What is important for an IT Ops to team more effectively with preproduction teams? #DevOps

“DevOps can present IT Operations teams with new ‘customers’ in development and test. What traditional or new tools and technologies are most likely to be important for IT Ops to team more effectively with preproduction teams? What information does IT Ops need to pass right to left and which tools are most likely to aid in that?”

The short answer is “A whiteboard marker, a pad of Post-It notes and a couple of pizzas” :-)

That answer is a bit tongue-in-cheek, but there is a serious side to it; whilst new tools can be an important part of DevOps (particularly in Automation) you can get started in changing your Culture and improving your Sharing with very simple tools i.e. the aforementioned whiteboard marker, Post-It notes and pizza.

Start to break down the silos by getting key people in a room with some blank walls and whiteboards and start sharing information, mapping out your value stream and trying to find out, collaboratively, where the bottlenecks in your existing processes are. Once you’ve identified your key constraints then fire up Google and start searching for the tools to solve your problems (or visit a site like DevOpsBookmarks).

DevOpsGuys, like most organisations, have our own “Opinionated Stack” – we like the Atlassian Toolset for managing our Agile workflow, TeamCity or Jenkins as our CI tool of choice, Ansible as our configuration management tool for Linux, Powershell DSC for Windows, AppDynamics as our APM tool, Redgate for our Database Lifecycle Management (DLM) and so on. We partner with many of these companies now because we’ve “dogfooded” the products internally and with our customers and they’ve worked well for our use cases. We always “try before we buy” and we “try before we partner” too because, as they say, “your mileage may vary” (YMMV).

This comes back to fostering a culture of experimentation – give something a try and see what works for you. We started off using Atlassian HipChat as our chat tool and we really liked it. Then we tried Slack and we liked that one more, so we switched. YMMV.

One additional point worth mentioning – the premise of the question is flawed!

They aren’t customers they’re colleagues.

There isn’t a silo of “Us” (IT Ops=supplier) versus “Them” (Everyone Else=customer).

We are supposed to be breaking down these silos to create cross-functional, multi-disciplinary, product-based teams. Development, Test, IT Security, Networks shouldn’t be silos any more – they are people in our team, sitting over the desk from us, attending our daily standups, eating our pizza :-)

The Q&A above is part of material prepared as our contribution to an CA ebook on “Agile Operations”. We wrote our thoughts on 6 questions, of which 4 will be used in the ebook, scheduled to come out in August 2015. We’ll post the remaining 2 questions with our answers onto the blog over the next 2 weeks. 

DOGs at Digital 2015

Digital 2015

Last week the DevOpsGuys headed up to Newport’s Celtic Manor to take part in Digital 2015 – the Welsh Government’s initiative to bring digital innovators and business professionals together. The 2-day event saw more than 2,000 delegates and 140 speakers.

DevOpsGuy co-founder Steve Thair says:

“These initiatives are invaluable to the digital sector because they expose the wide variety of digital and technological services that are available in South Wales to business professionals who can use them to take online business services to the next level. It’s a relaxed environment where people can chat and form connections that will have a direct impact on the future of business and technology in Wales.”

The diverse range of speakers at the event included Microsoft, the WRU, Amazon and the DVLA. The opportunity to discuss the needs of businesses directly with those running them is invaluable. This dialogue can lead to collaborative projects and further development of the burgeoning tech industry in the area.

The team are excited to see more events like this one springing up in the near future. Look out for us at the up-coming Agile Cymru in the Wales Millennium Centre on the 7th and 8th of July.


DOGWalking in Brecon



So, aching, tired and happy the DOGs returned from TrekFest 2015 in the Welsh mountains having raised £1,143.00 for the Countess Mountbatten Hospice and SSNAP – two charities close to the heart of the team. That’s 114% of our initial target, so a huge thank you to everyone who donated so generously.

The weather could not have been better for a long, scenic ramble in one of the UKs most beautiful spots; beautifully sunny with a refreshing breeze kept the team going. We completed the trek in approximately 5 and a half hours, just in time for a piece of cake and a glass of celebratory champagne at the finish line.

Everyone had a thoroughly enjoyable time and we’re all looking forward to the next DOG adventure!

The Ops Mgr at QCon 2015


“When you’re in a startup, the divide between Dev and Ops is normally the width of the desk…it’s far easier to collaborate in that small environment. In larger enterprises not only are they in different buildings but they’re in different countries with different cultures and different languages…”

The DOG Ops Manager Steve Thair chats to Manuel Pais at QCon 2015.

Steve Thair at QCon to hear Steve talk about Enterprise DevOps; taking the first steps on the road to DevOps and  cultural change.


Steve Thair’s QCon Talk – now available online



DevOps and the Need for Speed, the talk from our very own Steve Thair is now available online. You can check it out here.

Steve’s just spoken at Krakow’s Atmosphere Conference. Stay tuned for more, coming soon.

Increase your ELK herd with

Originally posted on DevOps Is Common Sense...:

At work, I recently had a need to put in place a scalable logging solution based around the ELK stack.

IssueswithMulticastnetworking aside,  Elasticsearch scales pretty well on its own without the need for any additional overheads, however discovering whether a node is online or not and connecting only to available nodes can be tricky.

Scaling Logstash can be tricky, but it basically involves adding more Logstash servers to the mix and pointing them at your Elasticsearch cluster by defining multiple hosts in your Logstash configuration.

Kibana (like most web applications) can only have one Elasticsearch host defined in the config, so scaling out Kibana is more difficult.

The above raises the question – how do I know which Elasticsearch node to point my configuration at if I don’t know whether they are there or not.

The answer came in the form of  If you’ve not looked at…

View original 781 more words