Welcome!

@DevOpsSummit Authors: Liz McMillan, Pat Romanski, Dalibor Siroky, Jignesh Solanki, Dana Gardner

Related Topics: @DevOpsSummit, Linux Containers, Containers Expo Blog

@DevOpsSummit: Blog Feed Post

Will 2017 Be the Year of DevOps NoOps? | @DevOpsSummit #Agile #DevOps #ContinuousDelivery

With DevOps for digital natives evolving to NoOps, this blog tells you what established companies like yours must do to compete

Will 2017 Be the Year of DevOps NoOps?
By Ron Gidron

If DevOps continues on the same trajectory into 2017 as it has been on for the past few years, specialized Ops teams could quickly become redundant. Instead, DevOps for digital companies will evolve to require only developers who nurture their own code into production. So how do established companies like yours keep up with this level of agility when you rely on a combination of legacy and digital apps? Read on to find out.

NoOps for Start-Ups?
The belief that we need a specialized ops team is often incorrect. Instagram built a $1 billion business without an ops team - when they sold to Facebook for that amount they had no ops people whatsoever.

DevOps means dev and ops surpass merely working closer together; they reach into each other's disciplines and learn. This leads to a cross-pollination of skillsets, meaning everyone understands the whole app lifecycle better and where their role sits within in. This idea is nothing new and should be encouraged in any profession, whether IT, medicine, law or anything else.

If DevOps continues to blur the lines between the two disciplines, then ops practices could all be performed by careful developers. This will add agility by reducing the need for cooperation; DevOps is encapsulated in one staff member.

For companies that do grow from scratch in today's DevOps world, the need to disrupt and be agile in development means that specialized ops staff should only be added when absolutely necessary. A more agile solution would be to hire development staff that care about how their code is deployed.

When Are Dedicated Ops Really Necessary?
One downside to this model is that in reality, the devs that show knowledge and willingness to perform ops work might eventually be swamped with work from colleagues. This leads to the best and most versatile staff members becoming frustrated and unhappy, ironically even becoming a bottleneck for everyone else. Perhaps the company begins to grow on a scale that is beyond the knowledge of these diligent devs, and they get out of their comfort zone.

What is important in this situation is not simply to hire an ops person to take care of all this work. Ideally they would do a minimal amount of actual ops work, and instead act as mentors for devs looking to learn the ops side of DevOps, which in theory should be all of them. For this reason it's important to hire someone whose skillset varies from that possessed by the team already, to bring something new to the company and spread that knowledge. Bring a dev a fish and he will eat for a day, but bring him a fishing rod and...erm, well you know where I'm going with that!

But What About Legacy Organizations?
The reality is that not all companies are digital start-ups that only have to worry about publishing pictures. Most rely on legacy apps and/or on security and reliability to succeed, especially in the the world of finance for example. Perhaps in verticals that prioritize security, dedicated ops teams will always be needed.

For established enterprises that want to adopt a NoOps model, how do they do this in practice? Just sack all their ops staff one day? In an international, 24/7 world with Continuous Delivery of applications becoming more widespread, downtime is almost unheard of. So reverse engineering a NoOps scenario without significant downtime would be difficult.

However, your company must adapt to compete with the level of agility offered by your digital competition. Reputation and history have been overtaken by functionality and apps as the number one consumer requirement, and a reputation built over decades can be quickly tarnished and forgotten if that company fails to digitally transform. Just ask Blockbuster.

The Answer is AgileOps
Development is already agile and is geared up to be. When that agility is not transferred to operations, silos are reinforced rather than broken down, particularly if ops are using different deployment tooling or automation mechanics. To keep up with digital natives, we need to focus on making ops agile. This is the real challenge of DevOps in 2017.

Typically, these days the development part is now project/pipeline driven: CI -> QA -> provision -> deploy, but then it runs into ops, which is still largely interrupt driven, and ops can't keep pace. They find it impossible to keep to a set plan as they must respond to all the requests coming in from other teams. They're fighting fires every day and cannot find the time to think make practices more agile.

So how we can help make ops agile?

Automated Provisioning
Computers do what you say, not what you mean. Self-service orchestration of key processes that consume much time when done manually, like server provisioning, prevents ops getting involved at all, leaving ops to do tasks that require brainwork.

Consistent Continuous Delivery Automation
In Jez Humble's book Continuous Delivery, he argues you need the same automation mechanics for every environment, something that is capable of spanning multiple environments. So the likes of Jenkins, although tempting as it is open source, is not suitable. An Application Release Automation product that sits across the whole toolchain, including all dev and ops tools, gives the necessary consistency and breaks down silos.

Consistent automation transcends employees, who can move jobs or department etc. The system stays in place to give business continuity; it is repeatable. So when you on-board new employees they have a standardized working process to follow, rather than trying to figure out what is supposed to happen from information aggregated from multiple colleagues. You don't lose agility from complex, ad hoc handovers.

If in 2017 you must compete with digital natives capable of working without dedicated ops teams, then your ops need to be as agile as possible.

Read the original blog entry...

More Stories By Automic Blog

Automic, a leader in business automation, helps enterprises drive competitive advantage by automating their IT factory - from on-premise to the Cloud, Big Data and the Internet of Things.

With offices across North America, Europe and Asia-Pacific, Automic powers over 2,600 customers including Bosch, PSA, BT, Carphone Warehouse, Deutsche Post, Societe Generale, TUI and Swisscom. The company is privately held by EQT. More information can be found at www.automic.com.

@DevOpsSummit Stories
As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being software-defined – from our phones and cars through our washing machines to the datacenter. However, there are larger challenges when implementing software defined on a larger scale - when building software defined infrastructure. In his session at 16th Cloud Expo, Boyan Ivanov, CEO of StorPool, provided some practical insights on what, how and why when implementing "software-defined" in the datacenter.
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
The need for greater agility and scalability necessitated the digital transformation in the form of following equation: monolithic to microservices to serverless architecture (FaaS). To keep up with the cut-throat competition, the organisations need to update their technology stack to make software development their differentiating factor. Thus microservices architecture emerged as a potential method to provide development teams with greater flexibility and other advantages, such as the ability to deliver applications at warp speed using infrastructure as a service (IaaS) and platform as a service (PaaS) environments.
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together ... and maybe even getting some relationship help along the way. And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud hosts. This BriefingsDirect cloud services maturity discussion focuses on new ways to gain container orchestration, to better use serverless computing models, and employ inclusive management to keep the container love alive.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.