Welcome!

Microservices Expo Authors: Pat Romanski, Elizabeth White, Liz McMillan, Yeshim Deniz, Carmen Gonzalez

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

@DevOpsSummit: Blog Post

The DevOps Equation: Agility + Empathy = Quality | @DevOpsSummit #DevOps

Derek Weeks interviews Jeff Sussna on the importance of designing for service and responding to the unexpected

I had the chance to catch up with Jeff Sussna ahead of his keynote address on continuous design, scheduled for DevOpsDays Atlanta, April 26-27. Jeff discussed the importance of designing for service, responding to the unexpected, and the importance of building empathy across teams.

Derek Weeks: Today, I'm really happy that we have Jeff Sussna joining us for the latest in this series. Jeff, why don't you introduce yourself?

Jeff Sussna: Sure. Thanks for having me. I'm an independent consultant. I've been around since rocks were young or the 80s, whichever is older. My particular background is that I have built systems and led organizations across the entire development, QA and operations spectrum. So, I'm a little unique in that respect.

My current focus is on helping IT organizations and digital businesses really bring together their ops and design thinking so they can not only go faster and not only be more resilient, but also provide more customer value at the same time.

DW: Let's talk about that a little. How is continuous design - a subject you have written a lot about - coming into play? How can it help us be more resilient?

JS: Just to explain a little about what we mean by continuous design. It's basically bringing together the entire organization and a unifying design in operations. It's taking what we are doing in DevOps and expanding it to include product, design and support. It lets the whole organization really have an agile conversation with a market and with its customers.

The issue that we face is that we live in a service world now. The point is no longer delivering products like cars coming off an assembly line. It's much more about responding to our customers and having relationships with them. This is happening in a world that is more and more complex, while less and less is in your control. We can't figure everything out in advance. We have to have the ability to respond to the unexpected. We have to be able to do that at every level.

____

"This is happening in a world that is more and more complex, while less and less is in your control."

____

I will give you a couple examples of things that are perfect illustrations of this:

I recently wished a friend of mine happy birthday. The reason I did that was because there was a notice on my calendar that said it was her birthday. It was wrong. It wasn't her birthday. I had no idea where that notice came from. Did it come from Skype? Did it come from LinkedIn? Did it come from email? I had no idea.

We face that in IT too. Systems are becoming more complex. We develop microservices. We use public and private clouds at multiple levels. We're no longer in a situation where we can control things. We have to be able to respond and respond at all levels.

____

When we make design and operations unified and continuous, we are able to say, "Where did we think we were going? Where would we need to go? And, what do we do next?"

____

What I talk about in my book, in my workshops and in all my work is that this needs to happen at every level. It's not just a matter of designing for failure inside the data center or inside the infrastructure. We also have to do it at other levels.

Here is another example:

I was trying to get paid recently by a large enterprise client in Europe. They were trying to wire money internationally; my bank wasn't really set up for it, and they were having problems. They just kind of gave up. I kept getting these messages saying, "Sorry, we tried paying you and it didn't work." That was the end of it.

I started to get frustrated, and my client within the enterprise started to get frustrated to the point where they sent a scathing email to our AP department (which they cc'd me on) saying, "Why can't we take the lead to get this guy paid?"

That's an approach that is based on resilience in the sense of assuming that something can go wrong and figuring out what he can do to fix it when it can go wrong. As opposed to the traditional approach where we've been trained to push certain buttons and take certain actions. If those actions don't work the way they are supposed to, well, I guess that is someone else's problem.

https://www.youtube.com/watch?v=ISSMHmwIMtA

DW: This brings to light some recent conversations I had with Paula Thrasher at CSRA. She was talking about developing systems and how to make them more resilient. She is using pictures as part of her conversations with people to help visualize their work. What work steps are there? What work is flowing? What is communicating with what?

Are you taking similar approaches with continuous design in how you work with clients to pursue it?

JS: Well, I try to introduce them to the principles, and I also try to introduce them to a set of practices which actually comes out of Mark Burgess' work on promise theory. It is really a conceptual model for how we think about success and failure and how we think about service. For example, Amazon helps you get everything you need in your life from shaving cream to batteries to snow tires to books as quickly and easily as possible. In order to keep that promise, they make a whole variety of other promises. Some of which filter all the way down to a promise to be able to go over change to production as quickly as possible.

Once you take that mindset, the interesting thing about a promise and the reason we use that word is because it is very intuitive. We all know what a promise is. We all make promises to each other every day. On the other hand, when we think about it in terms of service, IT or whatever, it may seem a little odd. The thing about promises is that, on the one hand, we are making commitments to do things, and on the other hand, promises sometimes get broken. That is actually good because it forces us to think. If I promised to pay my vendor, what do I do if I'm not succeeding in paying my vendor?

____

"The thing about promises is that, on the one hand, we are making commitments to do things, and on the other hand, promises sometimes get broken. That is actually good because it forces us to think."

____

It's sort of flipping our mind. Again, we are doing this in the DevOps world where you start thinking about things like mean time to repair (MTTR) instead of mean time between failure (MTBF). We shift from how do we create a situation to how do we create a situation in which nothing will ever break - which becomes less and less possible. We then need to shift to a situation where we can respond more and more quickly.

We go to executives and say we don't want to worry about how often stuff breaks anymore, and they freak out. We have to teach them and we have to teach ourselves that we can't prevent things from breaking. Instead, let's be able to fix them so quickly that maybe no one notices. My focus is on really helping people shift their mindset from thinking about ourselves to thinking about who we are helping. And from thinking about what we are doing to thinking about how well it succeeds and how well it overcomes problems.

____

"We have to teach them and we have to teach ourselves that we can't prevent things from breaking. Instead, let's be able to fix them so quickly that maybe no one notices."

____

DW: You talked about delivering on promises as quickly as possible. How does continuous design account for doing things as quickly as possible but making sure the quality is there at the same time?

JS: In two ways: One way is that when you do things in small increments, you are able to find problems more quickly. This is classic; it comes out of Lean. It comes out of integration. It's pretty basic stuff for our community now that it's much easier to find and fix a bug five minutes after you change a code than five weeks after you change the code.

When you put things like Linux, Agile, DevOps and design all together, they all focus on incremental feedback loops where you very quickly discover the gap between what you think you're accomplishing and what you're actually accomplishing. Secondly, when you take this all to the way to the marketplace and you make it part of the relationship with your customer, you can reduce a tremendous amount of waste.

The way to think about continuous design is: It's all about steering. Think about a boat that you're trying to sail across a bay. You can't just point the boat at the other side and say go because the winds are changing, and you're going to have to respond to things that you can't predict. If you sail for 20 minutes then discover you had pointed in the wrong direction, you're going to be way off course. You're then going to generate a tremendous amount of energy getting back on course.

What continuous design says is just an extension of continuous integration and continuous delivery taken all the way though the business. When we steer continuously, we steer efficiently.

____

"What continuous design says is just an extension of continuous integration and continuous delivery taken all the way though the business. When we steer continuously, we steer efficiently."

____

DW: I know you're going to be keynoting DevOpsDays Atlanta coming up in April. Chris Corriere, one of the guys on the organizing committee, tells me that you're leading a full-day workshop on continuous design before that. Maybe you could tell some of the people that are attending DevOpsDays Atlanta why they should be there a day earlier for your workshop and what things you're going to address during that time.

JS: To some degree, what I am going to address is everything we have been talking about for the last ten minutes or so - relative to DevOps. I think the key thing is - and we need to think about it - we need to think about more than just going fast. One of the big misunderstandings that I see with DevOps is this notion that it is primarily about delivering application changes to production faster. That's only half of it. We really need to think about it from the perspective of providing service.

____

"One of the big misunderstandings that I see with DevOps is this notion that it is primarily about delivering application changes to production faster. That's only half of it. We really need to think about it from the perspective of providing service."

____

You know what we are talking about is essentially developers and operations people providing better service to each other. As a result, they can deliver better service to the business.

Where we talk about microservices, you know that word service is in there for a reason. If all you do is you kind of shatter your organization and shatter your architecture into a bunch of little pieces, you still have to figure out how those pieces come back together into something coherent. The answer to that is taking a really deep service-oriented approach. That is very much what my workshop is about. What does that word even mean, and how do we do it?

DW: You mentioned thinking about interactions as delivering better service to one another within the organization. How does empathy come into your thinking around DevOps and continuous design?

JS: I'd like to say agility plus empathy equals quality. What I mean by that, in particularly empathy, I think it's important to take a minute and clarify. When we talk about empathy, we are not talking about wallowing in someone else's pain. We're not even necessarily talking about things on an emotion or feeling level. It's very simply the ability to see things as if from another's perspective. I will give you a prime example of where that comes into play and how it's important and how it helps.

____

Agility + Empathy = Quality

____

When I work with clients, I tend to look at their process using their organization from the product beginning to the support end. Oftentimes, I see support getting the short end of the stick. I see places where they get phone calls from customers with features that they don't even know exist yet. They sometimes get talked down to by development or product or even operations. They say things like, "Well, you're just supposed to support the stuff. You're the young people. You're the less experienced people."

When we have the ability to see things from their perspective, we can think about how support is actually experiencing our delivery process. If we don't think about them when we go through the process of delivering new features, they will be lost. Them being lost will show when customers call for help. That will significantly affect customer satisfaction and then even beyond.

The reason we need to empathize with support is so we can empathize with the customer. Oftentimes, when we build something, we don't think about the notion that our customers might have trouble with it. On the one hand, we have the illusion that if we design it and we build it really well, they won't have trouble. We can't perfectly predict who they are, what they need or what they will encounter. There's an inevitability to the idea that they are going to need some amount of help.

DW: I think that is probably the best description of empathy within a DevOps environment that I have heard anyone talk about. Jeff, it has been a great conversation. Thank you very much. I really appreciate it, and we look forward to seeing you at DevOpsDays Atlanta coming up.

JS: Thanks. It has been great talking to you, and I am really looking forward to the conference. It will be fun.

If you want to learn more about continuous design from Jeff, be sure to join us at DevOpsDays Atlanta. I will also be at the event giving an Ignite Talk entitled "Real Heroes Draw Pictures" focusing on lessons learned from the 31 DevOps and Continuous Delivery Reference Architectures assembled.

More Stories By Derek Weeks

In 2015, Derek Weeks led the largest and most comprehensive analysis of software supply chain practices to date across 160,000 development organizations. He is a huge advocate of applying proven supply chain management principles into DevOps practices to improve efficiencies, reduce costs, and sustain long-lasting competitive advantages.

As a 20+ year veteran of the software industry, he has advised leading businesses on IT performance improvement practices covering continuous delivery, business process management, systems and network operations, service management, capacity planning and storage management. As the VP and DevOps Advocate for Sonatype, he is passionate about changing the way people think about software supply chains and improving public safety through improved software integrity. Follow him here @weekstweets, find me here www.linkedin.com/in/derekeweeks, and read me here http://blog.sonatype.com/author/weeks/.

@MicroservicesExpo Stories
Building custom add-ons does not need to be limited to the ideas you see on a marketplace. In his session at 20th Cloud Expo, Sukhbir Dhillon, CEO and founder of Addteq, will go over some adventures they faced in developing integrations using Atlassian SDK and other technologies/platforms and how it has enabled development teams to experiment with newer paradigms like Serverless and newer features of Atlassian SDKs. In this presentation, you will be taken on a journey of Add-On and Integration ...
Culture is the most important ingredient of DevOps. The challenge for most organizations is defining and communicating a vision of beneficial DevOps culture for their organizations, and then facilitating the changes needed to achieve that. Often this comes down to an ability to provide true leadership. As a CIO, are your direct reports IT managers or are they IT leaders? The hard truth is that many IT managers have risen through the ranks based on their technical skills, not their leadership abi...
The essence of cloud computing is that all consumable IT resources are delivered as services. In his session at 15th Cloud Expo, Yung Chou, Technology Evangelist at Microsoft, demonstrated the concepts and implementations of two important cloud computing deliveries: Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). He discussed from business and technical viewpoints what exactly they are, why we care, how they are different and in what ways, and the strategies for IT to transi...
Without a clear strategy for cost control and an architecture designed with cloud services in mind, costs and operational performance can quickly get out of control. To avoid multiple architectural redesigns requires extensive thought and planning. Boundary (now part of BMC) launched a new public-facing multi-tenant high resolution monitoring service on Amazon AWS two years ago, facing challenges and learning best practices in the early days of the new service.
All organizations that did not originate this moment have a pre-existing culture as well as legacy technology and processes that can be more or less amenable to DevOps implementation. That organizational culture is influenced by the personalities and management styles of Executive Management, the wider culture in which the organization is situated, and the personalities of key team members at all levels of the organization. This culture and entrenched interests usually throw a wrench in the work...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm.
As software becomes more and more complex, we, as software developers, have been splitting up our code into smaller and smaller components. This is also true for the environment in which we run our code: going from bare metal, to VMs to the modern-day Cloud Native world of containers, schedulers and micro services. While we have figured out how to run containerized applications in the cloud using schedulers, we've yet to come up with a good solution to bridge the gap between getting your contain...
As organizations realize the scope of the Internet of Things, gaining key insights from Big Data, through the use of advanced analytics, becomes crucial. However, IoT also creates the need for petabyte scale storage of data from millions of devices. A new type of Storage is required which seamlessly integrates robust data analytics with massive scale. These storage systems will act as “smart systems” provide in-place analytics that speed discovery and enable businesses to quickly derive meaningf...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In his Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, will explore t...
DevOps has often been described in terms of CAMS: Culture, Automation, Measuring, Sharing. While we’ve seen a lot of focus on the “A” and even on the “M”, there are very few examples of why the “C" is equally important in the DevOps equation. In her session at @DevOps Summit, Lori MacVittie, of F5 Networks, explored HTTP/1 and HTTP/2 along with Microservices to illustrate why a collaborative culture between Dev, Ops, and the Network is critical to ensuring success.
With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend @CloudExpo | @ThingsExpo, June 6-8, 2017, at the Javits Center in New York City, NY and October 31 - November 2, 2017, Santa Clara Convention Center, CA. Learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.
Everyone wants to use containers, but monitoring containers is hard. New ephemeral architecture introduces new challenges in how monitoring tools need to monitor and visualize containers, so your team can make sense of everything. In his session at @DevOpsSummit, David Gildeh, co-founder and CEO of Outlyer, will go through the challenges and show there is light at the end of the tunnel if you use the right tools and understand what you need to be monitoring to successfully use containers in your...
What if you could build a web application that could support true web-scale traffic without having to ever provision or manage a single server? Sounds magical, and it is! In his session at 20th Cloud Expo, Chris Munns, Senior Developer Advocate for Serverless Applications at Amazon Web Services, will show how to build a serverless website that scales automatically using services like AWS Lambda, Amazon API Gateway, and Amazon S3. We will review several frameworks that can help you build serverle...
The IT industry is undergoing a significant evolution to keep up with cloud application demand. We see this happening as a mindset shift, from traditional IT teams to more well-rounded, cloud-focused job roles. The IT industry has become so cloud-minded that Gartner predicts that by 2020, this cloud shift will impact more than $1 trillion of global IT spending. This shift, however, has left some IT professionals feeling a little anxious about what lies ahead. The good news is that cloud computin...
SYS-CON Events announced today that HTBase will exhibit at SYS-CON's 20th International Cloud Expo®, which will take place on June 6-8, 2017, at the Javits Center in New York City, NY. HTBase (Gartner 2016 Cool Vendor) delivers a Composable IT infrastructure solution architected for agility and increased efficiency. It turns compute, storage, and fabric into fluid pools of resources that are easily composed and re-composed to meet each application’s needs. With HTBase, companies can quickly prov...
An overall theme of Cloud computing and the specific practices within it is fundamentally one of automation. The core value of technology is to continually automate low level procedures to free up people to work on more value add activities, ultimately leading to the utopian goal of full Autonomic Computing. For example a great way to define your plan for DevOps tool chain adoption is through this lens. In this TechTarget article they outline a simple maturity model for planning this.
While DevOps most critically and famously fosters collaboration, communication, and integration through cultural change, culture is more of an output than an input. In order to actively drive cultural evolution, organizations must make substantial organizational and process changes, and adopt new technologies, to encourage a DevOps culture. Moderated by Andi Mann, panelists discussed how to balance these three pillars of DevOps, where to focus attention (and resources), where organizations might...
The rise of containers and microservices has skyrocketed the rate at which new applications are moved into production environments today. While developers have been deploying containers to speed up the development processes for some time, there still remain challenges with running microservices efficiently. Most existing IT monitoring tools don’t actually maintain visibility into the containers that make up microservices. As those container applications move into production, some IT operations t...
For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
Software development is a moving target. You have to keep your eye on trends in the tech space that haven’t even happened yet just to stay current. Consider what’s happened with augmented reality (AR) in this year alone. If you said you were working on an AR app in 2015, you might have gotten a lot of blank stares or jokes about Google Glass. Then Pokémon GO happened. Like AR, the trends listed below have been building steam for some time, but they’ll be taking off in surprising new directions b...