devopsy.kinsta.cloud

Tag: developers

Where’s the Heat? Talking DevOps, Use Cases and More

Transitioning your organization from a traditional IT infrastructure into the world of DevOps is certainly a journey. Sometimes a long one, with many obstacles, but undoubtedly a voyage with a worthwhile prize at the end. Many organizations just embarking on their DevOps journey find themselves wondering, what use cases should they attack first? And who is driving these initiatives?

Recently, Amy DeMartine, senior analyst at research leader Forrester, and Wesley Pullen, general manager and vice president of Deployment Solutions at Electric Cloud, participated in a discussion to answer these questions and discuss how to orchestrate the DevOps tool chain, how to approach application release automation, and how DevOps fits in the greater scheme of compliance and auditability. For folks just beginning their DevOps journey—and IT pros who have been walking the walk for years—there were some great takeaways from their discussion.

DeMartine started off the discussion with something so basic that many folks often forget to consider it before starting their journey. But it is one of the most fundamental and important steps before beginning to explore DevOps; that is, answering the question, “What is DevOps?”

Here’s a great definition used by Forrester:

DevOps provides a set of practices and cultural changes—supported by complementary tools—that automates the software delivery pipeline, enabling organizations to win, serve, and retain consumers better and faster than ever before.

Part of this is the idea of taking the huge monolithic releases of the past and breaking them up into smaller and smaller pieces—at least on the agile development side of things. Then infrastructure and operations folks get involved and complete the continuous delivery life cycle by automating builds and testing and making sure releases are consistent and fast. Finally, there is collaboration among development, operations and security to make the product even more successful than before—and in all of this, you are creating feedback loops and building quality as well as consistency.

So now that you’ve got an established idea of the fundamentals of DevOps, let’s dive right into use cases. One of the most often-cited use cases is the idea of governance. People venturing into DevOps love the idea of moving faster and delivering more quickly than ever before, but find themselves asking, “How do you do that safely?”

It’s helpful to look at this using the visual of an upside-down triangle, with governance at the top. It applies to all companies and gives them the ability to control their releases all the way from development to production. Part of the benefit of using DevOps is that all of these tools you are using are creating log files, which essentially are breadcrumbs that give you an easy way to follow an audit trail. If you’re using a standard technology stack across a single application and apply it to multiple applications throughout your organization, you have the ability to look at governance across all of these various applications through the same lens.

On the next level of the triangle is compliance, which, depending on your industry, can mean a variety of things, but they are usually predefined and concrete. Finally, the bottom of the triangle is the audit aspect, which is where the best practices of DevOps become the most important.

DevOps Drivers

Ultimately, there are three different drivers of use cases that we see in DevOps, each with unique needs and perspectives. The first of these drivers are folks involved with infrastructure and operations. We often see projects and initiatives coming down from CEOs, CIOs and other senior executives in which the operations staff is driving the initiative and ultimately is responsible, so the initiative gets the budget. This is very hot in financial services.

Another driver are members of IT ops, DevOps and enterprise architects. These members often are focused on cross-team, cross-project initiatives. These are the senior architects, developers and operations staff that all are working together on a single solution. They already have the tools in place, but want to drive and orchestrate an end-to-end solution. Whether they are doing a build or need to make a quick change to provision a server, their goal is to consolidate and have a seamless pipeline.

Finally, the development-driven initiatives are coming from senior architects, development leads and QA who are pushing all kinds of different automation aspects, including continuous integration, continuous testing and continuous delivery.

Diving deeper into these heat zones and specific drivers, it’s helpful to look at what these groups are really focusing on. The top automation initiatives within the subgroups of infrastructure and operations folks start with the need to do deployments faster. They need to drive deployment automation faster. They also are interested in release management, or coordination across a release stream for different teams. When an organization has a series of activities across multiple teams, there is a distinct need to release everything at once to make sure it works. This group also is focusing on compliance and audit—particularly in highly regulated industries such as health care, financial services and insurance—and is always driving initiatives in which it’s trying to build out auditing packages.

In cross-team-driven initiatives, members include IT ops, DevOps and enterprise architects who are focused on cross-teams, and the cross-project initiatives primarily focus on end-to-end orchestration. They also are concerned with cloud resource management. When teams are paying for tools, they want to make sure they are maximizing their value and getting the most use possible out of those resources. That can mean scaling up or down in strategic ways to get the biggest “bang for their buck.” Finally, this group also focuses on configuration management orchestration.

Lastly, developer team-driven initiatives are focused not only on items such as continuous delivery, continuous integration and continuous testing, but also on container orchestration. As there is a greater awareness of potential security holes in Docker, it is necessary to place an increased emphasis on container orchestration, particularly with more and more individuals moving to containers. There also is an increased focus on QA lab provisioning. With the incredible growth in the realms of the Internet of Things (IoT) and embedded, these areas are correspondingly heating up for developer team-driven initiatives. One example put forth in the discussion between DeMartine and Pullen was a recent issue around one of the most well-known IoT devices on the planet—the Nest smart thermostat. In January, Nest went down, leaving many people without heat. This is a great example of why development teams want to focus on IoT use cases: DevOps enables rapid fixes for the massive demands of the IoT world.

Ultimately, you can see from these use cases and initiative drivers that DevOps offers an incredibly dynamic opportunity, ideal for meeting the needs and perspectives of organizations from top to bottom—and the incredible growth of DevOps, as the organizational structure for IT organizations across multiple industries proves that out. In fact, DeMartine and Pullen polled the audience during their discussion and found that 61 percent of attendees planned to adopt DevOps practices in the next 12 months, while 83 percent of attendees planned to adopt deployment automation/ARA in the next 12 months.

If you aren’t already considering DevOps for your organization, whether you are and CEO or a developer on the front line, it is worth investigating to see how it can answer your most pressing challenges and use cases.

The full conversation between Amy and Wesley is available here.

About the Author / Sam Fell

Sam Fell is the Head of Marketing at Electric Cloud, responsible for driving awareness and demand for our DevOps Release Automation and Acceleration solutions. For 20 years, Sam has helped companies achieve success by marketing, selling, and implementing DevOps Release Automation, IT Change Management and Application Performance Management solutions. Prior to joining Electric Cloud, Sam held leadership roles at BMC, CA, Marimba and Nimsoft.

Sam holds a Bachelor of Arts degree from Illinois Wesleyan University.

June 10, 2016
DevOpsDays Silicon Valley is Coming!
DevOpsDays Silicon Valley is coming, so mark your calendar! DevOpsDays events are a global phenomenon, bringing together practitioners across roles for two days of scheduled presentations and networking in a community-organized event. You won’t want to miss this year’s conference!

The 7th annual DevOpsDays Silicon Valley is scheduled for June 24-25 at the world-famous Computer History Museum. Silicon Valley is the oldest of the U.S. events and was originally the third DevOps Days ever. The conference, which started in 2010 as a low-key event hosted on the campus of LinkedIn, has grown into a major event.

This year’s lineup includes talks from a variety of perspectives including security! Jennifer Davis, co-author of “Effective DevOps,” will open the conference up with “Devops is for Everyone.”

DevOpsDays Lineup

Here is the 2016 speaker lineup:

Keynotes:
- Troubleshooting Troubleshooters: Debug Your Colleagues for Fun and Profit, by Bethanye McKinney Blount, CEO/Co-Founder
- From Divided to United – Aligning Technology & Business Teams, by Dominica DeGrandis, Director, Learning & Development
- Cost versus Performance: Analytics for Walking the Tightrope, by Elizabeth (Betsy) Nichols, Chief Data Scientist
- The Future of Automation, by Adam Jacob, CTO and Founder of Chef
Presentations:
- Behind Closed Doors: Managing Passwords in a Dangerous World, by Noah Kantrowitz
- At the Intersection of Happy and Healthy: DevOps Meets IoT, by Gail Ferreira
- Heresy in the Church of Docker, by Corey Quinn
- DevOps Army of N – Recovering From Being a Human SPOF, by Jonathan Disher
- (Parental) Leave Actually, by Dave Dash, Nicole Grinstead, Melissa Sandgren
- How to Onboard Entry-Level Talent to a DevOps Culture, by Angel Tian and Sophia Castellarin
- Autoscaling Containers … with Math, by Allan Espinosa
- How I Learned to Change My Mind and Became a Better Engineer, by Ramin Khatibi
- Removing the Stigma of P0w3rship, by Ed Anderson
Ignites Include:
- How Do You Measure Availability? Performance and Availability and SLMs, oh my! by Warren Turkal
- Feature Feature, by Linda Goldstein
- The Elements of Developer Experience (DX) Design, by Stephen Boak
- Reflections of an Operations Burnout, by Jamie Dahl
- Breaking Brooks’ Law with DevOps, by Jason Yee
- A DevOps Team is a Daft Idea and You Should Feel Bad! by Caedman Oakley
- How Can You Scale It If You Don’t Trust It? by David Blank-Edelman
- From WWW to GGG, by Anne Ahola Ward
- How I Learned to Stop Worrying and Love the Protocol, by Pete Sclafani
Following the inspiring talks, each afternoon is dedicated to Open Space, where the agenda is dedicated to small-group, participant-led discussions chosen on the fly. This is the chance to dive into specific topics, ask for help, discuss what you’ve done, find like-minds or just be a fly on the wall and take it all in.

If you are in the San Francisco Bay/Silicon Valley area, get your tickets for the June 24th and 25th DevOpsDays Silicon Valley ($199) before they sell out. We also have a limited number of education tickets for faculty, staff and students ($100). If you live elsewhere, be sure to keep an eye on the main DevOpsDays site for upcoming events. Also, check out DevOpsDays Silicon Valley recorded talks from 2015.

About the Author / Damon Edwards

Damon Edwards is the co-founder and managing partner of the DTO Solutions, a DevOps and automation engineering consultancy whose clients include leading SaaS, e-commerce, gaming, and financial services companies. Damon Edwards is also the co-founder and vice president of SimplifyOps, a provider of support and services for the users of the Rundeck open source project. Damon has spent over 14 years working on both the technology and business ends of IT operations. Damon is also a frequent conference speaker and writer who focuses on DevOps and operations improvement topics. Damon is active in the international DevOps community, including co-organizing the DevOps Days conference series, co-hosting the DevOps Cafe podcast, and a co-author of the DevOps Cookbook from IT Revolution Press.
June 9, 2016
Simulation: The ‘Aha’ Moment for DevOps Adoption

Every IT transformation requires that people, process and technology align and work together to achieve success. As organizations begin to appreciate the benefits of a DevOps approach and look to change to a DevOps model of software development and release, there will be significant pressure on people, process and technology to support that change properly.

The technology and process changes required to enable DevOps to work efficiently shouldn’t be underestimated. Considerable time and investment is required in embracing the automation technologies that support a proper DevOps environment, and in developing the processes that make best use of that technology.

But DevOps cannot work unless your people are ready to change. Development teams and IT operations—who traditionally have worked in silos—must work together, integrate seamlessly and understand not only their roles and responsibilities within the new environment but also the roles and responsibilities of those around them.

And therefore, like every change, the real key to success is your people.

Creating Successful Change

The benefits of taking a DevOps approach are numerous: By moving toward more frequent delivery with reduced elements of change, you lower risk and increase system stability. Although automation is costly to implement, it allows teams to work far more efficiently, increases reuse, reduces errors and brings development teams closer to the customer. New functionality released continually and rapidly can be validated in the market, feedback can be received, lessons can be learned and improvements implemented quickly.

But in making such a radical cultural shift, how do you ensure you change the mindset of people who have been used to working in a certain way? How do you provide your people with the helicopter view of what that future state will be, instill in them your fervor for change and provide them with the understanding and motivation necessary to embrace new ways of working? How do you ensure everyone is rowing in the same direction? Because without that, your change—already difficult and challenging—will become impossible.

The Key to Change

The key to any successful change is communicating your vision to your people. But providing your staff with a clear vision of what that future state could be is enormously difficult. You can outline the benefits of change, explain to them what good will look like, tell them what is in it for them, and all of these are hugely important.

But there is no substitute for allowing people to actually feel what your future state will be like.

Nothing compares to parachuting them into a situation where they can work through the changes required in a risk-free environment, experience the pitfalls and live the successes. As you move them to a fully functioning and productive DevOps environment, you will accelerate buy-in from your team rapidly, and give them a much more profound understanding of your vision and future state.

The Power of Simulation

Simulation training is one of the most effective tools to explain complex concepts and operating models quickly and convincingly. A presentation on DevOps—or almost any other topic—is not a productive method of showing someone the difference it can make to their work or their business. It’s the difference between reading a script and performing a play. More and more, companies are using simulation training as a shortcut to inform, educate and convince their teams of the value of large-scale organizational change—and DevOps is a prime example.

One of the key benefits of the simulation model is that people learn together. Your team learns at the same pace, working toward the same goals—and, as a result, they collectively show each other the value of change. With a traditional change program you need each employee to go on his or her own journey to recognize and adopt your vision. With a group simulation you take everyone present down the road toward a collective “aha” moment. Once that moment has happened you have an instant group of advocates who can go out to the business together and begin to effect change on a much more fundamental level.

Simulation Brings Agility to Adoption

Providing a simulated environment in which to train is not new; it has been used extensively and successfully by the military for decades. Commercial pilots train on simulators to provide them with as close to a real-world experience as possible of some of the life and death decisions they may need to make in an emergency. They understand the power of experiential learning.

Simulating a DevOps model brings that power of experiential learning to your business, allowing you to immerse your people in a concentrated and deeply focused environment where they face the same challenges as they will in the real world.

In one short morning they get to experience building a culture of DevOps themselves, making mistakes, understanding them and learning from them. It demonstrates the business value and positive impact of a DevOps approach in only a few hours, and can accelerate the adoption of DevOps across the enterprise, successfully turning DevOps opponents into advocates.

In a world where the quality of your software can make or break your organization, it is critical to create an environment where developers and operations are not only aligned and more efficient, but also empowered and able to concentrate on developing and releasing products that add the most value to the business.

Rome wasn’t built in a day, and you can’t effect convincing organizational change in a single morning. However, by immersing your team in a simulation, you can take a giant step forward and create a team of advocates who will go out and sell your vision for you.

About the Author/Andrew Macintosh

Andrew Macintosh is a Creative Solutions Director for G2G3. He works with clients across the globe, helping to understand requirements and craft technology based solutions to engage staff and customers, internally and externally. Prior to joining G2G3 Andrew ran a production company and worked within the TV industry for 12 years.

May 23, 2016
‘DevOps is a Lifestyle, Not a Title’

“DevOps is a lifestyle, not a title.” This is a quote from Ron Melanson, of Amazon, and I hope he won’t mind me sharing it here. It struck a chord with me, and this blog explains why.

I have spoken about DevOps on a few occasions. Some audiences are not from a development background, so I explain the “why” of DevOps to them to help set context.

Chances are you are past the “why” stage and into the “how” stage. Even so, it is always useful to think about the “why” part, or even to revisit it—it is important to make sure you really are getting what you want from the DevOps journey.

In my DevOps presentations I vary between the transactional aspects of the “why” and the emotive aspects of the “why.” The transactional aspects are what the tooling can help with, and so that matters to a degree. However, since emotions influence us the most, especially from a lifestyle perspective, it is the emotional aspects that I want to focus on here.

The picture below captures, for me, the essence of why people care about DevOps: they want to be happy at work, and to sleep soundly at night. If you are not where you want to be with respect to those things, then you need to change the way you lead your life.

The DevOps lifestyle is a virtuous cycle

I highlight the “change the way you lead your life” aspect to illustrate contrasts among the differing approaches to DevOps that I have witnessed.

Now that DevOps has grabbed the popular imagination, it is quite common to see job advertisements for people to be part of a DevOps team.

One ex-colleague of mine, hired to lead a DevOps team, expressed some concern about whether that notion actually made sense. He saw his team off in a corner focused on tooling and processes, i.e. the transactional, while everyone else in the organization seemed to be doing what they always did.

When his team suggested a change to a process, or tried to explain how a tool could be adopted, they often were at a disadvantage. The people in development and operations, whose working practices would be affected, had not actually bought into the whole idea in practice, and/or simply did not have the bandwidth to think about it.

Consequently, with little or no time to pay attention to what the DevOps team were doing, there was no engagement from the people for whose supposed benefit the DevOps team was laboring. Thus, there was no driver for changes in behavior. They were all missing the emotive “why” part.

The challenge my colleague faced is common. Hiring someone to do DevOps does allow you to focus on getting people with the skills and experience for the transactional and technical aspects of DevOps. That is necessary, but it is far from sufficient.

If the benefits are to accrue to the people working in development and operations—and, indeed, the wider company and business they serve—then it is those people who have to own the idea, top to bottom.

Owning the idea means rethinking what you are doing, and why—in other words, changing your lifestyle. At least at work, anyway.

May 17, 2016
Preserving Bottom-Up Innovation in DevOps

Balancing top-down control and oversight with bottom-up innovation and autonomy

The driving force behind DevOps adoption in the enterprise is the idea that it will enable faster and more frequent delivery of better quality software. If all goes well, DevOps should result in higher customer satisfaction and lower costs, but the journey to get there can be challenging. Unfortunately, only a minority of organizations that attempt to implement DevOps actually fully deploy it.

There are many barriers to overcome before organizations can realize the benefits of DevOps. One of the main challenges is retaining sufficient top-down control and oversight without hampering bottom-up innovation.

From Start-Up to Enterprise

The root of this problem lies in the fact that many ideas in DevOps were developed in environments with small teams and flexible organizational structures. In such setups, where everyone can see what everyone else is doing, visibility and control seldom are an issue. Adapting this approach to an organization with hundreds of geographically distributed teams, in industries with a lot of regulatory baggage and diverse legacy systems, is an entirely different prospect.

How do enterprise organizations find a structure that enables individual teams to unleash their innovation and maintain a feeling of responsibility without losing oversight and control? If DevOps teams are not empowered to make their own decisions and free to move swiftly, then they’ll struggle to realize the benefits that drive adoption in the first place.

Walking the Tightrope

Individual DevOps teams should be free to make local decisions, but these need to be in alignment with business goals at the management level.

You don’t want to hamper the speed and reliability that automation brings, or the innovation that can come from autonomous decision-making, so you need to find a way to balance tools, processes and team structure to maintain control and visibility. Avoid flying under the radar; instead, aim for maximum transparency in what your DevOps teams are doing. Set goals and measure, because visibility for management will prove that the new approach is working, build confidence and secure more top-down investment.

Connecting the Dots

A large enterprise will have a number of DevOps teams, but they shouldn’t be completely isolated. Requirements such as audit trails, security access logs and compliance controls must be met by all of these teams. There’s little sense in making each individual team responsible for solving the same problems over and over again. Offer a set of standards and tools, but be careful not to shut down choice.

That same logic applies to competence development, so offer your DevOps teams access to best practices and enable them to learn from each other. The size and structure of an enterprise organization does present unique challenges to DevOps adoption, but there’s also opportunity here to benefit from the scale by sharing and collaborating. Sharing and standardizing the right things will eradicate redundancies and free your DevOps teams to focus on improving their products and innovating, so the business derives maximum value from their efforts.

Finding What Works

The right answer will be different for each organization, but there are some things everyone should keep in mind when building or shopping for tooling. It needs to support a large, diverse environment. Look for support for the platforms you use and consider extensibility, so you can add the functionality you need.

A key factor here for orchestration tools—especially those that define and execute your delivery pipelines—is that they must be accessible for management. You shouldn’t need to be a technical expert to dip in and get an overview, or compile a report that provides the insight you need. Ensure you collect diverse metrics and present information in a digestible format so you can find bottlenecks and identify successes and failures and really deliver the best experience possible for the end user.

About the Author / Andrew Phillips

Andrew Phillips is VP of DevOps Strategy for XebiaLabs, provider of software for continuous delivery and DevOps. He is a cloud, service delivery and automation expert and has been part of the shift to more automated application delivery platforms. He contributes to a number of open source projects including Apache jclouds, the leading cloud library, and is a co-organizer of the DynamicInfraDays container community events.

May 11, 2016
Trust, You Must: 8 Tips for Adopting CI/CD

We have done continuous deployment (CD) for four years, and enable many of our customers to do continuous deployment with quality assurance (QA). We’ve helped tons of companies adopt and optimize their CD setups. We’ve found that continuous deployment is all about trust — augmented with processes and infrastructure.

To that point, here are some common tips for adopting continuous integration (CI)/CD that I find myself sharing frequently:

Use a CI Tool

This sounds obvious, but you’d be surprised at how many companies try and roll their own. Don’t. There’s no upside for your company—and infinite downside. We love Circle, but there are plenty of other great options. Most are at least somewhat prescriptive when it comes to workflow, which is important when you’re getting started.

Do Unit Testing

It’s always worth reminding everyone that continuous deployment is simply continuous integration applied to deployments. To do continuous integration, you need good unit test coverage. If you haven’t got a solid base of unit testing and continuous integration already, you’re not ready for continuous deployment.

Have Solid Production Monitoring

Bugs and regressions will get shipped; it’s inevitable. Put a system in place, by looking at the data in production, to tell you when a regression or bug was shipped. Tie this into automated rollbacks, so that if a significant performance or key performance indicator (KPI) regression (i.e., signups per minute) appears, your CD system rolls back to the most recent stable version while your team investigates.

Trust Your Team

We talked about the infrastructure requirements, but if you don’t have trust, then continuous deployment isn’t going to work for you. Trusting your team is about giving your developers the freedom to make mistakes, deploy as they see fit and check each others’ code. It is possible to combine continuous deployment with a culture of hierarchical permissions, but we have yet to see that truly work.

Remove Red Tape from the Code Review Process

Your team should review code changes, typically through a pull request, which goes hand in hand with trusting your team. Developers should be trusted to choose the most qualified and insightful person to review their code. One of the most common mistakes among teams trying to adopt continuous deployment is that they only let one or two “senior” developers review the rest of the team’s code, “bottlenecking” all releases. Don’t make this mistake.

Involve Developers Closely in Production Operations

The most common mistake we notice among companies that don’t make a successful transition to continuous deployment is that their development organizations are siloed. Dev and Ops should be joined at the hip. Have your developers deeply involved in the setup and definition of your CD infrastructure, and half the battle is already won.

Shift Left: Test Early and Often

Your team needs constant feedback. Think of your QA objective as getting the right feedback in the right hands at the right time. When it comes to deployments, this means knowing what’s working and what’s broken as the breaking change is made. The sooner you uncover the bug after it’s created, the easier it is to fix. The best companies doing continuous deployment have comprehensive unit test and integration test coverage that runs before any code hits the staging server.

Treat Staging as Your Holy Place

The final pre-production environment is usually known as ‘staging.’ A common mistake is to have developers ship new code direct to staging, while figuring out if the new code is ready to go live. This is a terrible idea. As soon as more than one developer is trying to ship their changes, your Slack channel will blow up with cussing and recriminations. Isolate the pre-production environments to each project, and enforce the “staging as ready to go live” philosophy. This way, integration testing can happen at a self-defined pace, without anyone else’s release being blocked.

About the Author / Fred Stevens-Smith

Fred Stevens-Smith is Co-founder and CEO of Rainforest QA, a quality assurance-as-a-service startup backed by Storm Ventures, Rincon, Andreessen Horowitz, Morado and Crosslink.

May 5, 2016
DevOps Days London: The Human Factor

Day 2 of DevOpsDays London 2016 kicked off with a presentation from the legendary Gene Kim. The theme that dominated today’s proceedings was the “human factor,” (fitting, as we finished Day 1 with #humanops) nicely started by Gene’s quote from Nathan Shimek: “We need DevOps to make our work humane.”

The second day delved beyond what makes people happy, posing questions regarding what it is to be human, and why automation is not everything when it comes to DevOps. As Gene said, “DevOps transcends the technology stack we are working with.”

DevOps aims to supplant pain with joy and help people find autonomy, mastery, purpose and deep satisfaction in their working lives in technology. Werner Vogel, CTO at Amazon, is often quoted as saying: “You build it, you run it.” But Gene took this further as he explained how a developer had described his most satisfying working experience as coding something and deploying it and monitoring it and fixing it, too. He also touched on the power of shifting left, using Test Driven Development—and its demand that we write the test script in before we even start to code—as an example. That’s building quality in. That’s cross-skilling and cooperation.

It resonated with the audience when Gene said there was one single question that, when answered, tells us everything we want to know about an organization’s DevOps maturity: “To what degree do you fear deployments?”

We came back to this question later in Jeromy Carriere‘s talk about his experiences of scaling at Google. Going the gym for the first time is painful—we have to build muscle memory, he said. We need to practice these processes until they are like breathing.

Gene made a book recommendation: “The High Velocity Edge,” by Steven J Spear. When we do DevOps we are aiming to transform into a dynamic learning organization. We should not expect but be required to talk about problems. No fear, no blame. Everyone in an organization should be trained to run a blameless post-mortem—or a healthy retrospective, if you prefer. As Claire Agutter put it: “Improving daily work is more important than doing daily work.”

Gene then outlined the DevOps Enterprise Summit London event coming up at the end of June and the extraordinary stories of experiences people share about their DevOps journeys during DOES events. He said: “Often the transformation leader was putting themselves in personal jeopardy.”

I can testify to that. It takes courage, optimism, conviction and tremendous amounts of energy to be a change agent.

The human theme continued into the panel discussion as the COO of Technology at Barclays explained how its command and control structure, waterfall-ruled development and volume of changes resulted in total gridlock. He said that the big challenge is trying to re-engineer the organization to behave differently: “Changing HOW we do our work is the hardest thing.”

Changing human behavior is very challenging indeed; as Joanne said, measurements have to change and we have to focus on customer value. Gareth Rushgrove also majored on the human angle in his talk on DevOps and microservices. He said: “Microservices are as much about people as technology,” and, “Which comes first: the software or the team?”

Essentially, DevOps and microservices help us to make lots of small bets—spreadbetting, if you like—spreading risk and accelerating feedback. And we need small teams to be able to do microservices and move away from monolithic applications.

One particular Ignite talk stood out from the rest, and won the hearts and minds of the audience: @coldclimate from Server Density. Through a personal story of a back injury brought on by prioritizing work over looking after himself, the #humanops message: “You are not immutable, you are not highly available!” struck home hard.

So there we have it. My key takeaway from DevOpsDays London 2016? DevOps is less about technology and automation and more about happy, healthy humans.

April 28, 2016
Does the Future of DevOps Lie in NoOps?

Why DevOps is more a bi-directional rather than a simple top-down approach

DevOps is one of those buzzwords that nearly everyone wants to discuss these days. However, it often is interpreted as an extension of Development’s influence to the detriment of Operations teams.

So much has changed in the past few years that it is conceivable we will see another major shakeup: Could Operations teams disappear altogether? Or to put it another way, is “NoOps” the future of IT? While DevOps promotes faster delivery of new digital services and a blurring of the lines between Dev and Ops, in reality, is Dev consuming Ops entirely?

Before DevOps was called DevOps, the two disciplines were growing further apart. Agility has been driven by Developers since the turn of the century, with the famous Manifesto for Agile Development. Meanwhile, Operations formalized repositories of good practices into frameworks such as ITIL or COBIT, which were implemented by most large companies in the mid-90s. Those two approaches seem to oppose, as DevOps advocates the acceleration and multiplication of changes and ITIL tends to monitor and control them.

NoOps, or the End of Operations?

If you believe everything you read, then Operations is a dying art. But in practice, Development does not want to be involved with infrastructure, while few organizations would trust developers to manage their data centers, whether physical, virtual or cloud. So breathe easy: DevOps does not mean the end of Operations teams.

On the contrary, Operations remains essential throughout the DevOps approach. Production infrastructure is a complex and delicate stack of technologies, often with a discreet mix of modern architecture and historical applications. It often is impossible for Development to replicate these types of environments. And that is why an application successfully tested in a qualification environment often does not work properly in production. However, it is crucial to validate new developments in a representative replica of the production environment.

So is DevOps doomed to constant failure because of lack of continuity between qualification platforms and production systems? Well, this is probably the case if we merely consider DevOps as a simple top-down approach from Development to Operations. Focusing on producing changes at a higher frequency only shifts and grows a bottleneck that sits in production, without producing the added value expected by the company. As a consequence, DevOps must also be seen as a bottom-up process. In other words, if we consider DevOps, we must also take very serious look at “OpsDev” (OK, it doesn’t flow off the tongue, but you see my point!).

DevOps or OpsDev?

For a successful DevOps approach in practice, Development must position itself as a consumer of turnkey infrastructure environments. Operations then adopts an OpsDev approach and provides infrastructure on demand for all steps of continuous integration, from compilation to qualification, through unit testing.

If DevOps is a radical change in how Development works, OpsDev would also revolutionizing common Operations practices. It comes with more agile “declarative” infrastructures (described and built from source code), an even more sophisticated level of automation and the ability to provide self-service infrastructure for developers.

The adoption of DevOps does not mean that Operations will disappear or will be replaced by Development, but rather the emergence of bi-directional agility that needs to be supported by more sophisticated automation. In fact, DevOps implies OpsDev rather than NoOps. Finally, whatever you consider your release process under the ITIL or DevOps angle, isn’t the end goal exactly the same: delivering zero-default service to customers?

April 28, 2016
Reasons Why Developers Should Test More

When I got started as a professional software developer, I thought awesomeness in development was measured by the lines of code (LOC) per day and how quickly code got to QA for testing. Coding a few thousand lines overnight gave one instant bragging rights, regardless of how well the code worked (or didn’t) in the morning. The more senior guys always acted like they knew better, suggesting that it’s not about the quantity but the quality. But I was too young and arrogant to listen. And, of course, I had to learn it the hard way. My seemingly amazing overnight code would show cracks once under the microscope of the QA team.

True today as it was then, most mistakes are tiny and easy to fix, but even small problems require a tedious set of steps from when a QA engineer finds the mistakes to when the developer fixes them and sends them back to QA for verification. Some bugs are the size of the Mariana trench and require weeks of work and thousands of additional LOC. And, even new code, once resubjected to QA, can generate bugs, therefore repeating the cycle without an end in sight. Of course, by this time projects are late and developers are tired, frustrated and burnt out.

After this happened to me too many times, I realized that maybe I was wrong. Maybe the experienced guys were on to something with this quality thing. They never seemed too tired, and their projects were in much better shape. I decided that for my next feature, delivering quality instead of LOC would be my priority.

I’m sure you think you know what’s coming next. I’m going tell you that I tested my stuff from that day on and it worked perfectly—no more boring bug-fixing. You think I’m going to tell you, you should do it too, right? Well, no. I actually spent a lot of time in my second attempt instrumenting my code better so that I could debug it faster as the need arose. I also spent a lot of time writing my own test tools because I didn’t have one. But I kept moving forward and learned the hard way. Here is what I took away from those moments:

Develop More, Bug-Fix Less

There are two common reasons for developers’ involvement in a project. Developing a new feature or enhancement is about creativity, as it gives one the opportunity to design and implement new things. And then there’s the challenge of bug-fixing, which is all about maintaining existing functionality within older, already-made things. As a developer needs to do both, often at the same time, minimizing bug-fixing time is important to have more time in which to actually be creative and develop new functionality. And the best way to minimize bug-fixing is to test code more, as it’s developed, to avoid the death spiral I describe above. Good initial quality will mean QA will find fewer bugs and it is very likely that the criticality of the bugs found will be greatly reduced. As such, fixes no longer would be a struggle on short notice; shortcuts that generate more bugs don’t have to be used; and developers can focus on new features as opposed to fixing bugs. In all, the reasons are to develop more, and bug-fix less to be more productive.

Be More Reliable

Bugs also are nasty in that they tend to appear really, really late in the game. The Murphy’s Law on bugs should be something like, “The hardest bug is found one hour before the release is pushed to production.” This typically happens because everyone is busy peeling the onion, finding and fixing bug after bug until they get the “system” stable enough for QA to crush it with those large-scale system test cases that expose that one nasty bug. It is an artifact of waterfall development but also happens in agile development, as no agile team can afford running long duration tests in a sprint. So what happens then? Who ends up in crunch mode? The developer. To avoid this, developers need to find and fix the easier bugs sooner, as they write the code. That way, the onion is half peeled once it reaches the QA team. The nasty bug will be found much sooner—if the developer did not find it and fix it already. In short, developers can be more reliable by avoiding last minute bug-fixing. And we all know, reliability in execution is fundamental for fostering trust with management. A trusted developer is the one that gets to work on important, meaningful projects.

Be More Flexible

While in an ideal world the design of a feature is not changed frequently, in real life the exact opposite is true. At some point, even regularly, developers will have to modify the code as the scope of the features keeps changing. Massive code changes such as refactoring, if not done right, can send developers right back to a long, teeth-grinding, bug-fixing period. Avoiding it by testing early, as they change the code, offers a significant advantage—flexibility. Developers would be able to accommodate required changes more quickly.

Agile Development is Critical

Let’s do a quick recap: By simply testing code as it is written, developers can spend less time fixing bugs and more time developing new features, to become more productive, more reliable and trustworthy and even more flexible in implementing changes. This takes us to our final reason for early testing: Agile development is no longer nice to have, but business-critical. All of the attributes described above are quintessential for succeeding in an agile team. Developers are expected to be flexible, reliable and build a lot in short time periods. The days of trial and error, of learning the hard way, are gone. Today, we need to go from design to development to testing to going live in days, not months. Quality is what differentiates products. Developers need to do all of this to be successful.

About the Author/Gabriel Chiriacescu

Gabriel Chiriacescu is the director of Software Development at Ixia, with more than 13 years of experience in embedded software development. He is currently leading the product management effort for the new Ixia Developer solution, an agile test tool designed specifically for developers.

At Ixia, Gabriel has led multiple engineering teams responsible for developing market-leading test solutions in a variety of technological areas, including wireless, broadband access, data center, triple play, authentication and security.

A native of Bucharest, Romania, Gabriel holds a BS in computer science from the Polytechnic University of Bucharest. After living several years in Los Angeles, Gabriel is now based in North Carolina and enjoys discussing CICD, SOA design patterns and the evolution of software development.

April 27, 2016
DevOpsDays London 2016: Making Happy
We haven’t had a DevOpsDays event in London since 2013. The audience size was about the same at this year’s event, held April 19-20, as I remember from last time, but about 85 percent of the audience were attending a DevOpsDays event for the first time. It was great to see so many new faces, and I guess the high proportion of first-time visitors could be a sign of the maturing and proliferation of DevOps thinking.

I’m delivering a webcast April 26 titled, “DevOps for Architects,” so on the way to the event I read this book in preparation. At Ranger4 we ask people a lot: “Are you having a good day?” or, “How do you know you are having a good day?” Something has always discomfited me slightly about this, in the same way that “What does good look like?” and, “Just good enough,” trouble me. Can’t we aim higher? What does “great” look like? In the book, the authors talk about “happy days,” and this makes me happy. And this was the theme I took away from the first day at DevOpsDays London 2016—DevOps makes happy.

Here are a few reasons how:

First up on the stage was Bridget Kromhout, a DevOpsDays organizer I last saw speak at the DevOpsDays five-year anniversary in Ghent in 2014. Her talk was titled, “Cloudy with a Chance of DevOps”—a succinct introduction to DevOps as it looks today with some key takeways:
- “Automation is not everything.” Most people get this now, but we meet a lot of people who started with automation and realized they’d skipped to the end. Start with culture.
- “DevOps is practiced, not purchased.” You might be surprised to find us supporting this, since we make a living out of selling DevOps. But we don’t. We believe that the best way to help organizations transform using DevOps principles is to partner with them—to coach, motivate, guide, challenge and help them move through their journey. This is what we do.
- “It is not necessary to change. Survival is not mandatory.” This is a quote from the “Godfather of Lean,” Deming.
Bridget was followed by Joanne Molesky, the co-author of “Lean Enterprise,” a frequently cited must-read for DevOps enthusiasts.

Key messages from Joanne’s talk were her assertion that technology is no longer the bottleneck, particularly now that conventional business models are under attack. Joanne also cited quantum computing as the key disruptor she sees coming through in the near future. It was particularly interesting to think about what she said about Tesla disrupting not because the company has designed a better, more affordable electric car, but because it is changing the game in terms of how individuals will access the power grid.

Following on from Bridget’s recognition that not all companies are any where near delivering on the velocity promise of DevOps and the subsequent happiness, key barriers Joanne identified include slow decision-making processes and conflicting goals embedded into many enterprises that have been around for a significant amount of time. She described “process madness” and how most enterprises “plan, do” and forget the “check, act” part of the PDCA cycle. She explained how many organizations have created walls of “no’s”—effectively, “Culture says no”; a sentiment shared by many individuals we spoke with after her session.

A popular quote that was tweeted multiple times from Joanne was: “You only fail when you fail to learn.”

Speaking with organizations that are moving to agile and DevOps, many of them talk about their difficulties moving from project-centric thinking to product-centric thinking, a point reiterated by Joanne. She recommended the three horizons framework as a useful tool to plan and enact change while managing the current state. She also had some very useful advice for organizations trying to tackle regulatory requirements: “Understand the intent.” Organizations have a habit of misconceiving and conflating what the regulations say.

“The best code is that which you don’t write”—a bit like the advice to writers: “kill your darlings.” This is about being lean, planning properly and removing extraneous effort.

Close to our own hearts, Joanne also emphasized the importance of measuring the things that matter. Similarly, she pointed out that organizations that have a classic “command and control” structure have no hope of being able to do DevOps. When organizations perform cultural change, they must amplify their feedback loops at all levels. By using principles like holacracy, organizations can understand who the sensors are in their business and learn to hear ideas, how to make the process madness sane and let ideas germinate and blossom.

I frequently quote John Willis:

“DevOps finally proves how IT can be a strategic advantage that allows a business to beat the pants off the competition. This is the moment we’ve all been waiting for.”

For far too long IT has been seen as the guys in the dungeon, (ever seen the IT Crowd?) but as John said, these are exciting times for us in IT. As Joanne put it, we used to say IT supports the business, then we said IT is aligned to the business, now we say IT is integrated to the business or, even better IT is the business. This should make us all happy.

Kris Saxton followed Joanne with a talk we were anticipating highly: “Bi-Modal IT and other snake oil.” We’ve been challenging this term recently, too, so I was happy to find more support that this is an oversimplification of the situation organizations are in and is counterproductive, undermining the type of culture we are trying to create by creating more silos, more “them and us-es.” Put succinctly, Kris said: “Bi-modal IT is poison.”

As Jez Humble recently said:

“Gartner’s model rests on a false assumption that is still pervasive in our industry: that we must trade off responsiveness against reliability… This assumption is wrong.”

Kris said there is a “happy place” where we can have both responsiveness and reliability, velocity and quality, speed and stability. DevOps helps us do this by shifting left, having multi-disciplinary teams, a people-focused culture working to small, scalable scope—and more.

The rest of day one was filled with slots from the many sponsors of the event, a demo from Pivotal, Ignites and Open Spaces. The last three thoughts I’ll leave you with though were:
1. Sponsor ServerDensity used its pitch to highlight health and well-being in IT; #hugops. The company is setting up a MeetUp group in London for HumanOps, emphasizing that DevOps is not just automation and it’s here to make humans happy
2. Microsoft’s Thiago Almeida shared stats on how DevOps initiatives at Microsoft have positively influenced employees’ work/life scores
3. John Clapham spoke on how he set fire to his car and what this taught him about the currency of empathy and how this can be used to improve life at work
Check back for coverage of Day 2 of DevOps London.
April 26, 2016