Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Pat Romanski, Liz McMillan, Zakia Bouachraoui, Elizabeth White

Related Topics: @DevOpsSummit, Linux Containers, Agile Computing

@DevOpsSummit: Blog Post

The Unicorn Every #DevOps Is Looking For By @TrevParsons | @DevOpsSummit

In my DevOps scavenger hunt I have identified a new type of creature: shared services (aka the unicorn)

Shared Services: The Unicorn Every DevOps Is Looking For

In my hunt for the mysterious DevOps practice, I've been let down. DevOps are hard to find. When you find them, they do not exactly do what you think they should do. Some DevOps teams only execute on automation for dev; while others are operations folks with a new name; and still others are internal consultants helping operations and developers (but not actually doing the work).

In my DevOps scavenger hunt I have identified a new type of creature: shared services (aka the unicorn)

What I have learned about this mysterious creature is interesting.

While we normally think of DevOps as a function that combines both development and ops, we miss that DevOps also requires someone who is not in the weeds of development or operations. Someone who can look beyond the specifics and proactively seek new ways to enhance development processes for increased software quality and releases.

Where do shared services belong?
This responsibility is tricky, both tactically and operationally.

It has a somewhat vague objective, and is not necessarily tied to the results of one specific application. Organizations need to be opportunistic to build such a team. The group would have to behave similar to a consultancy, but focused on strategy and not execution.

Shared services is just this, and it has existed since before DevOps was a thing.

shared services what every devops is looking for

What do shared services employees do?
All the shared services personnel I have talked with had a consistent theme:

  • Provide a library of tools, either the actual tool or the opportunity for it, to operations and development teams.
  • Facilitate the cross pollination across those teams.

This means they have a keen eye on what is possible. They typically do not implement the tools, and they do not have oversight over all of them. For example shared services might recommend a log analysis platform, but the implementation and setup could be owned by IT.

Taking ownership
In this particular example, ownership is changing. Developers are demanding more visibility into the applications relationship with infrastructure. It is problematic to implement both APM and log analysis without the connection. Today they have to request the information directly, which is disruptive both for IT and development.

Shared services can play the messenger.

If the eco-system is large enough this is necessary because operations does not know all of what Development is doing and vice versa. So, having that middle layer is nice. Especially in organizations that try to standardize tooling, which is a challenging in its own right. But, the downside is it does increase the gap, which is contrary to DevOps.

Building in consistency
In organizations where each dev group can choose and implement its own tools, shared services operates as facilitator for the groups inauguration, and a point of validation across other groups.

This functions like you took the strategy of DevOps and moved to its own group, which is pretty neat, but has a bummer of a requirement.

Is shared services only something large companies can do?
Practically yes.

But the idea is something even small organizations can learn from. The dirty little habit of most dev shops is to only focus on a particular release, and the details associated with it.

Because of the need for speed, DevOps tools get implemented, but it should be the other way around.

DevOps should be created deliberately not reactively. Like the oversight of shared services, small groups can learn to adopt the approach of picking tools and processes for the pipeline not the problem. They can do this by selecting an individual to have the oversight, or collectively as a team.

The ideas are spreading
I'm really excited about the shared services idea, and what this is going to bring to so many large (often thought of as barred from DevOps) organizations. When shared services are added as a component, they can bring both strategy and execution under one umbrella. I understand this is idealistic; tactically it is hard to find the talent or time to allow for both strategy and execution.

Shared services is not DevOps in name, but it is the DevOps facilitator, and it has the proper amount of focus on what the organization is doing today, and what they can do in the future.

More Stories By Trevor Parsons

Trevor Parsons is Chief Scientist and Co-founder of Logentries. Trevor has over 10 years experience in enterprise software and, in particular, has specialized in developing enterprise monitoring and performance tools for distributed systems. He is also a research fellow at the Performance Engineering Lab Research Group and was formerly a Scientist at the IBM Center for Advanced Studies. Trevor holds a PhD from University College Dublin, Ireland.

@DevOpsSummit Stories
Hackers took three days to identify and exploit a known vulnerability in Equifax’s web applications. I will share new data that reveals why three days (at most) is the new normal for DevSecOps teams to move new business /security requirements from design into production. This session aims to enlighten DevOps teams, security and development professionals by sharing results from the 4th annual State of the Software Supply Chain Report -- a blend of public and proprietary data with expert research and analysis.Attendees can join this session to better understand how DevSecOps teams are applying lessons from W. Edwards Deming (circa 1982), Malcolm Goldrath (circa 1984) and Gene Kim (circa 2013) to improve their ability to respond to new business requirements and cyber risks.
DXWorldEXPO LLC announced today that Nutanix has been named "Platinum Sponsor" of CloudEXPO | DevOpsSUMMIT | DXWorldEXPO New York, which will take place November 12-13, 2018 in New York City. Nutanix makes infrastructure invisible, elevating IT to focus on the applications and services that power their business. The Nutanix Enterprise Cloud Platform blends web-scale engineering and consumer-grade design to natively converge server, storage, virtualization and networking into a resilient, software-defined solution with rich machine intelligence.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
This session will provide an introduction to Cloud driven quality and transformation and highlight the key features that comprise it. A perspective on the cloud transformation lifecycle, transformation levers, and transformation framework will be shared. At Cognizant, we have developed a transformation strategy to enable the migration of business critical workloads to cloud environments. The strategy encompasses a set of transformation levers across the cloud transformation lifecycle to enhance process quality, compliance with organizational policies and implementation of information security and data privacy best practices. These transformation levers cover core areas such as Cloud Assessment, Governance, Assurance, Security and Performance Management. The transformation framework presented during this session will guide corporate clients in the implementation of a successful cloud solu...
So the dumpster is on fire. Again. The site's down. Your boss's face is an ever-deepening purple. And you begin debating whether you should join the #incident channel or call an ambulance to deal with his impending stroke. Yes, we know this is a developer's fault. There's plenty of time for blame later. Postmortems have a macabre name because they were once intended to be Viking-like funerals for someone's job. But we're civilized now. Sort of. So we call them post-incident reviews. Fires are never going to stop. We're human. We miss bugs. Or we fat finger a command - deleting dozens of servers and bringing down S3 in US-EAST-1 for hours - effectively halting the internet. These things happen.