Welcome!

@DevOpsSummit Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, Elizabeth White, SmartBear Blog

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

@DevOpsSummit: Blog Feed Post

A Developer’s Perspective | @DevOpsSummit #DevOps #APM #Monitoring

Since moving to a model where developers own their services, there’s a lot more developer independence

A Developer's Perspective
By Eric Sigler

"Walking over to the Ops room - I don't feel like I ever need to do that anymore."

In the run up to our latest release of capabilities for developers, I sat down with David Yang, a senior engineer here at PagerDuty who's seen our internal architecture evolve from a single monolithic codebase to dozens of microservices. He's the technical lead for our Incident Management - People team, which owns the services that deliver alert notifications to all 8,000+ PagerDuty customers. We sat down and talked about life after switching to teams owning the operations of their services. Here are some observations about the benefits and drawbacks we've seen:

On life now that teams own their services:
Since moving to a model where developers own their services, there's a lot more developer independence. A side effect is that we've minimized the difficulties in provisioning and managing infrastructure. Now, the team wants to optimize for the least amount of obstacles and roadblocks. Supporting infrastructure teams are geared toward providing better self-service tools to minimize the need for human intervention.

The shift to having developers own their code reduces cycle time from when someone says, "this is a problem," to when they can actually fix the problem, which has been invaluable.

On cultural change:
By having people own more of the code, and have more responsibility in general for the systems they operate, you essentially push for a culture that's more driven towards getting roadblocks out of the way - like each team is more optimized towards, "how can I make sure I'm not ever blocked again" or "not blocked in the future." It's a lot more apparent when we are blocked. Before, I had to ask ops every time we wanted to provision hosts, and I just accepted it. Now my team can see its roadblocks better because they aren't hidden by other teams' roadblocks.

We have teams that are focused a lot more on owning the whole process of delivering customer value from end to end, which is invaluable.

On how this can help with the incident response process:
There are clearer boundaries of service ownership. It's easier to figure out which specific teams are impacted when there's an operability issue. And the fact that I know the exact procedure to follow - and it's more of an objective procedure of, "this is the checklist" - that is great. It enables me to focus 100% on solving the problem and not on the communication around the incident.

On what didn't work so well:
Not to say that owning a service doesn't come with its own set of problems. It requires dedicated time to tend to the operational maintenance of our services.  This ultimately takes up more of the team's time, which is especially an issue with legacy services where they may be knowledge gaps. In the beginning, we didn't put strong enough guardrails in place to protect operability work in our sprints. That's being improved by leveraging KPIs [such as specific scaling goals and operational load levels] to enable us to make objective decisions.

On the future:
[Of balancing operations-related work vs. feature development work] teams are asking: "How do I leverage all of this stuff day-to-day? How do I make even more objective decisions?" - and driving to those objective decisions by metrics.

Everything in our product development is defined in, "what is customer value", "what is success criteria," etc. I think trying to convey the operational work in the same sense helps make it easier to prioritize effectively. We're all on the same team and aligned to the same goal of delivering value to our customers, and you have to resolve the competing priorities at some point.

Trying to enact change within an organization around operations requires a lot of collaboration. It also takes figuring out what the right metrics are and having a discussion about those metrics.


Image: "Magnifying glass" is copyright (c) 2013 Todd Chandler

The post A Developer's Perspective appeared first on PagerDuty.

Read the original blog entry...

More Stories By PagerDuty Blog

PagerDuty’s operations performance platform helps companies increase reliability. By connecting people, systems and data in a single view, PagerDuty delivers visibility and actionable intelligence across global operations for effective incident resolution management. PagerDuty has over 100 platform partners, and is trusted by Fortune 500 companies and startups alike, including Microsoft, National Instruments, Electronic Arts, Adobe, Rackspace, Etsy, Square and Github.

@DevOpsSummit Stories
Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-Ops have limited insight and answers to who, what, when, why and how across the DevOps lifecycle. This impacts the ability to deliver high quality software at the needed velocity to drive positive business outcomes. In his general session at @DevOpsSummit at 19th Cloud Expo, Eric Robertson, General Manager at CollabNet, will discuss how customers are able to achieve a level of transparency that enables everyone from Planning-to-Ops to make informed decisions based on business priority and leverage automation to accelerate identifying issues and fast fix to drive continuous feedback and KPI insight.
More and more brands have jumped on the IoT bandwagon. We have an excess of wearables – activity trackers, smartwatches, smart glasses and sneakers, and more that track seemingly endless datapoints. However, most consumers have no idea what “IoT” means. Creating more wearables that track data shouldn't be the aim of brands; delivering meaningful, tangible relevance to their users should be. We're in a period in which the IoT pendulum is still swinging. Initially, it swung toward "smart for smart's sake," and many brands remain in that corner. But many brands are also gradually opting for more strategic approaches. They're taking a breath and stepping back to examine both existing and potential IoT experiences, asking themselves whether their products lend real value. Once we reach this goal, the implications for personalization are staggering. Consumers will expect devices they use and i...
We all know that end users experience the internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices - not doing so will be a path to eventual business failure. The real and more difficult question, in developing microservices-based applications, is this: What's the best combination of cloud services and tools to use to get the right results in the specific business situation in which you need to deliver what your end users’ want. Considering that new streams of IoT data are already raising the stakes on what end users expect in their mo...
We all know that end users experience the internet primarily with mobile devices. From an app development perspective, we know that successfully responding to the needs of mobile customers depends on rapid DevOps – failing fast, in short, until the right solution evolves in your customers' relationship to your business. Whether you’re decomposing an SOA monolith, or developing a new application cloud natively, it’s not a question of using microservices - not doing so will be a path to eventual business failure. The real and more difficult question, in developing microservices-based applications, is this: What's the best combination of cloud services and tools to use to get the right results in the specific business situation in which you need to deliver what your end users’ want. Considering that new streams of IoT data are already raising the stakes on what end users expect in their mo...
DXWorldEXPO LLC announced today that ICC-USA, a computer systems integrator and server manufacturing company focused on developing products and product appliances, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City. ICC is a computer systems integrator and server manufacturing company focused on developing products and product appliances to meet a wide range of computational needs for many industries. Their solutions provide benefits across many environments, such as datacenter deployment, HPC, workstations, storage networks and standalone server installations. ICC has been in business for over 23 years and their phenomenal range of clients include multinational corporations, universities, and small businesses.