Tag: ops

  • SDM and the DevOps Delusion of Connected Organizations

    SDM and the DevOps Delusion of Connected Organizations

    How Software Delivery Management Clears Up the Confusion of Embracing and Implementing DevOps

    Since the term was coined back in 2009, it wouldn’t be a stretch to describe DevOps as an impactful if not tectonic shift in software development and delivery in the past two decades. The move to implement DevOps has encouraged, among other things, better collaboration between siloed Dev and Ops teams, more reliance on automation, more focus on culture and better use of feedback loops to refine delivery processes.

    In theory, DevOps has been a game-changer. But, in practice, its usefulness is more difficult to define. As DevOps enters its teenage years, the idea of a fully integrated software delivery function aligned toward a common goal of generating business value is more illusion than reality.

    Are DevOps teams themselves as connected as they should be? The reality is that developers and operations personnel tend to have their own versions of “dev DevOps” and “ops DevOps,” working against each other inside supposedly integrated teams. Though they may have set up deployment pipelines, each side tends to use its own tools, access its own information and follow its own cadences, leading to occasional missed handoffs and delays in delivery schedules.

    Looking across the enterprise, DevOps cultures fray further. A perfect DevOps practice envisions teams in different departments, business units and geographies all in sync, delivering value via software on a reliable cadence. In reality, enterprise DevOps is difficult to pull off because most organizations haven’t implemented shared languages, comment processes and best practices across all of their teams with management buy-in.

    Then there’s the issue of connecting DevOps functions with the rest of the organization. Some definitions of DevOps extend the concept of collaboration to other stakeholders beyond conventional engineering functions, such as quality assurance, testing and security. But how extensively does a DevOps culture tie together the goals, needs, resources and processes of others in the organization that rely on software delivery, such as product marketing, sales and executive management?

    Delivering Better Software

    Gartner describes DevOps as being focused on “rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach.” In other words, delivering faster and in a more organized manner. But has DevOps helped software-first organizations deliver better software? Has it helped them institute the right processes to deliver the right software at the right pace to drive the most value possible to the organization’s bottom line? Paraphrasing the “If a tree falls in the forest …” proverb: If you deliver software and no one is there to consume it, have you truly delivered value?

    Even if you’re doing DevOps relatively well, there’s a level of integration that’s missing from today’s software cultures. It’s the mission to tie together all functions of software delivery—not just those relating to what goes on in the labs. It’s the commitment to do more than just deliver better metrics. It’s the mentality to define everything relating to software delivery as a discipline all its own, like finance or sales—not just serving other disciplines.

    A new technology category is emerging that aims to build on what DevOps has accomplished and extend those gains across the software delivery function. It’s called software delivery management (SDM). An SDM strategy is based on four foundational pillars that elevate software delivery to a core business priority, reflecting the level of importance software has achieved in today’s business environment:

    • Common Data – All information within and around software delivery activity is captured and stored with a consistent domain model to enable and facilitate connections to processes, shared insights and collaboration.
    • Connected Processes – Processes orchestrate software delivery and connect functions together to efficiently bring ideas to market with maximum value and adoption.
    • All Functions Collaborating – All functions and teams within and around the software delivery organization work together to amplify value creation efforts.
    • Universal Insights – Visibility and insights enable understanding and continuous learning from data across, up and down and throughout all functions in the organization.

    Driving Improvements Across Organizations

    Adopting an SDM strategy on top of an existing DevOps culture can help an organization in a number of ways.

    Having disconnected tools, disconnected data and a lack of common language make it difficult for one side of the organization to know what the other wants. Even in mature DevOps implementations, software delivery ends up being a patchwork of different processes for different teams.

    It’s also difficult to determine if our teams are delivering the right end product if there’s no shared visibility and insight. SDM helps by establishing common data and common processes, giving visibility and insights across teams of different maturities, different tools and different technologies so you get all functions to collaborate. That way you can be sure you’re not just deploying more—you’re actually delivering continuous value.

    You can’t manage what you can’t measure. What SDM offers is a model to understand how you’re performing with DevOps by and large, what teams are performing well and what teams aren’t, and how you can leverage those insights to improve.

    Tips for Implementing SDM

    Here are five ways SDM build on the successes of DevOps:  

    • Integrate your tools: Disconnected toolchains make it difficult, if not impossible, to orchestrate a delivery process end to end. Try to get DevOps tools onto a common platform where they can share information across teams and organizational functions.
    • Capture data: Ensure you’re establishing an audit trail and capturing data on events and actions that are taken across that end-to-end process. Then collect those data points in a common data store as normalized objects. Making common data accessible across functions allows you to, for example, reconcile a particular support request to the right user story and commit to the right change that is being deployed out to a server.
    • Don’t fail to communicate: Once you’ve created your data store, establish a strong relationship and regular communication with the business side of the organization. Continuous delivery isn’t just for developers anymore; software delivery functions have to address business needs. That can’t be done without high levels of communication.
    • Establish KPIs: You should have a taxonomy or hierarchy of business objectives you’re trying to achieve with your DevOps implementation. Establish the hypotheses that can achieve those objectives and then integrate the features/user stories or implementation-level entities that will drive you toward them.
    • Leverage observability practices: This needs to be done so you can measure those performances against KPIs. If you believe that updating your user interface will increase the amount of time users spend in your SaaS application, you need to establish what that target KPI is. Then, as those changes are delivered, measure, analyze and adjust to continue to drive those toward the hypothesis.

    Conclusion

    DevOps has taken software delivery a long way and implementing an SDM strategy can take it the rest of the way. It won’t change DevOps, but it could reinvigorate the practice. Deploying both strategies in concert, software delivery management and DevOps can focus less on automation and tools and more on the outcomes and on the people and steps involved in driving those outcomes.

  • The Struggles DevOps Administrators are Up Against

    The Struggles DevOps Administrators are Up Against

    DevOps has quickly gone from being a niche concept to a widespread practice that is gaining traction rapidly in both large and small organizations. As it becomes a key part of many development teams, administrators must work to integrate DevOps techniques, tools and practices into a wide range of teams, from operations to development, support and management.

    The seamless completion of this implementation, together with the overall change in methodology and culture from top to bottom, provides a smoother workflow. The issue, however, is that admins are being asked to do more with less. DevOps administrators from large companies are struggling to keep pace, partly due to the newness of the practices, and in part out of a need to provide a competitive advantage for the business. Additionally, they find themselves in the middle of many different cultural pressures. All of this is leading to problems in fully implementing and reaping the benefits of a fine-tuned DevOps machine.

    That said, working through the implementation of a DevOps techniques will be worth it in the end and to make the transition easier, here are some specific pitfalls that administrators should try to avoid.

    Reliance on DevOps Technology

    One burden that is often faced by DevOps admins is an organization’s over-reliance on technology. In theory, technology is the easy part, but too often organizations become enamored with the newest shiny automation tool and find themselves in a cul-de-sac of isolation, forgetting to bring the rest of their organization with them.

    The wave of digital transformation that many organizations are experiencing can present additional difficulties as new technology is being implemented throughout different business units and administrators find themselves in high demand.

    Automation is awesome, but it isn’t the answer—it’s part of the recipe. The solution requires attention to processes and culture. According to a Gartner study, 73 percent of what organizations should focus on consists of attention to culture and communication, information exchanges and building operations process and organizational consistency. Only 27 percent should be on tooling.

    As the growing emphasis on DevOps places an added burden on infrastructure teams already struggling to cope with the digital transformation in their organizations, unification will be key to success. Ignoring the importance of creating a harmonious culture that embraces DevOps and processes that foster the methodology can be costly. Ensuring that tools are utilized in a smart way alongside people and processes will ultimately lead to more success.

    Building Collaboration Between Dev and Ops

    DevOps trust and transparency is at the core of release management. This level of collaboration and trust ensures that both sides of the equation agree when it comes time to ship software.

    Both sides in Dev and Ops frequently misunderstand the other’s motivations around production control and release management. Stability is king for Ops, and they would love nothing more than preserving uptime in each release, even if it means a blockage of imperative software updates. Dev, on the other hand, wants to move quickly, and they often make assumptions about what is required to support software in production. To help unite the two requires administrators have the ability to fill in the information gap that exists between Dev and Ops.

    In a way, DevOps admins work as the therapist for a severed relationship between Dev and Ops. Bridging the divide between these two departments can, at times, feel like counseling an organization to communicate better. But doing so through integration and collaboration is a surefire way to make life easier for everyone involved. DevOps doesn’t force people to become who they’re not; instead, it promotes cooperation, tolerance and shared responsibilities between the teams. 

    Lack of Transparency

    What many administrators also lack is a way to clearly understand, prioritize and utilize the data they have. From an agile practice perspective, that level of visibility should be established early on in a data reporting structure—project, initiative, etc.—and with the proper software solution. A solution that combines application release, environment, quality and deployment data across the portfolio to drive continuous improvement of software delivery.

    Being able to utilize this data makes a world of difference for delivery teams to be able to quantify, correlate and predict outcomes to help solve problems and make better decisions. The most basic, yet beneficial, insight you can have when making these decisions for an organization is to have the transparency to know that what you are doing is working.

    Creating a Culture vs. Working in Silos

    Application release delays costing hundreds of millions of dollars can be caused by poor management of complex enterprise software releases. A big part of the issue is that the very nature of agile and DevOps is to work in smaller teams, which can naturally create silos. For a given release, there can be many teams and, in some cases such as test environments, teams from different projects can collide due to lack of oversight. This complexity presents significant management problems and, without insights across the entire process, release trains are bound to crash.

    A culture of working in small teams on a single release lends itself to working in silos, and that isolationism often conspires against organizationwide success. This construct needs to be broken, as it produces an additional level of complexity and unification that will be a key point of emphasis for organizations in their road to digital transformation success.

    This unification will be especially important in large organizations that see frequent changes to their software release cycles, sometimes daily. It is imperative for these organizations to avoid silos and favor better communication with pronounced team roles, especially with the added confusion that the rapidly evolving delivery cycle can bring.

    Creating a cohesive and harmonious DevOps culture will benefit everyone in an organization in the long run. To be successful at this, though, it’s imperative that DevOps admins are given the rein to institute the change that they see fit. Admins must educate themselves on the latest technology, learn how to use and monitor it and bring in the rest of the teams so everyone can work together. But the burdens they are up against need to be dealt with on an organizational level from the top down, creating the ultimate DevOps working environment for all.

    — Bob Davis

  • Ops: The Other DevOps

    Ops: The Other DevOps

    Much of the conversation around DevOps, including right here on devopsy.kinsta.cloud, is about helping developers get easier access to production systems, increasing agility by shortening release cycles. Most of the time, this focus on developers leads to a concentration on so-called “Day One” tasks, the Dev side of the equation, to the exclusion of “Day Two” operations—the Ops side of things.

    Cows in a field with farmer
    Photo via Damien Kuhn – https://unsplash.com/@producteurslocaux

    Recent moves in the DevOps market underscore the fact that the weight is still very much on the Dev side, and not so much on Ops. Microsoft buying GitHub is huge news, don’t get me wrong, not least because many people are still stuck in a very Nineties conception of Microsoft, and this acquisition should help clarify that this is not your parents’ Microsoft (full disclosure: my employer, Moogsoft, has a strategic partnership with Microsoft). News on the Ops side of the house, meanwhile, rarely achieves the same prominence.

    The reason for this imbalance is to be found in DevOps’ origin myth. The story is all about developer frustration with risk-averse operations procedures which prevented them from deploying as rapidly and frequently as they would have liked to. As with most good stories, there is a kernel of truth here, but the truth is more complicated. Ops people are risk-averse for good reason: When they mess up, they don’t have a safety net, and they get a lot of very public blame.

    That said, it is certainly true that a reasonable aversion to risk can be taken too far. Couple that with a very human tendency to define oneself by one’s job, and you wind up with people putting hands to keyboards for even basic, routine tasks, becoming bottlenecks for huge processes.

    What Does DevOps Mean To Ops?

    The biggest benefit of DevOps from an Ops perspective is that it has forced that hard conversation about moving from artisanal, handcrafted IT infrastructure, to industrial and scalable models that don’t require a human in the loop for routine operation. This cultural shift began with the famous pets-versus-cattle analogy, but the transition is far from being complete.

    A big sign that there is still work to be done is the relative lack of sophistication around tooling  in IT Operations. There is a lot of talk about software-defined infrastructure and desired-state automation, but relatively little practical uptake, especially when it comes to operating such frameworks day-to-day. These new models will require a wrenching transition from traditional Ops models, with pervasive automation working to augment human sysadmins’ capabilities.

    This is not the old style of automation, with cron jobs and shell scripts, which any BOfH worth their etherkiller has been doing for decades. The new serverless frameworks do away with the last vestiges of persistent coupling of infrastructure components to individual business services. What vMotion promised in 2003 is now coming to pass, with workloads moving, growing and shrinking to support changes in user demand, and infrastructure reconfiguring itself top to bottom in response.

    Key Questions To Ask About Operational Automation

    In this context, operational automation can no longer work on the old model of “set it and forget it.” Every process set in motion needs real-time contextual awareness of what is going on around it and how that is constantly changing. Without that visibility, backup scripts may go on faithfully backing up what used to be a high-priority server, but is now a backwater of the application infrastructure. Meanwhile, the cloud services where the bulk of the application’s logic runs are not meaningfully integrated into the disaster recovery (DR) plan.

    All of these facets need to be reviewed regularly, in terms of need, function and ownership.

    Who Needs This Automation?

    Anything that runs should be linked to some kind of business requirement, however indirectly. “This ensures that our infrastructure can scale and flex seamlessly in response to user demand”: Good. “This keeps our operating systems patched”: A valid goal, but do we need to do it in production if the average lifetime of provisioned operating systems is shorter than the patch cycle? Just patch the templates and you’re done. “We’ve always done it this way, and I’m not sure what might happen if we stop”: Time to set some chaos monkeys loose, and see what happens.

    What is the Function of This Automation?

    We are in the middle of huge technological transitions, and the waves of innovation keep coming closer and closer together. As an industry, we had just about come to terms with virtualization by the time cloud computing came along, but that was far from settled when containerization got underway, and it looks like that may be undermined by serverless architectures before it even comes to its full fruition. Watch out for hidden assumptions in terms of the way you go about a task, and check back in regularly. Ops types should take a leaf from Dev’s book, and regularly consider refactoring their automation to remove cruft and take advantage of new developments.

    Who is the Owner of This Automation?

    Someone has to own every piece of automation, so that they can maintain it over time according to the previous two points, and so that everyone else knows who to call if (or realistically, when) it breaks. Again, developers have been talking about technical debt for a long time: the impact of older, unmaintained code. Meanwhile, sysadmins used to pride themselves on the uptime of individual servers. That attachment needs to move from the individual server to the overall infrastructure and the automation and management that develop over time to ensure its availability and performance. They’re cattle, not pets, remember?

    Ops is the Other DevOps

    As Ops becomes more and more about managing the automation, the distinction between Dev and Ops starts to blur. With Dev roles “picking up the pager” and taking responsibility for production operation of their software, Ops roles develop more and more code to fulfill the promises of those applications. With traditional Ops tasks evolving or even disappearing, new roles will appear. The job of automation architect will become much more relevant than any job that requires someone to ssh into an individual server or router. In this transition, old-school Ops people can learn a lot from what our Dev colleagues have been up to over the last few years.

    One day, the term DevOps will no longer describe developers and non-developers, but two different types of developer, one focused on business logic and one on architectural underpinnings.

    — Dominic Wellington

  • DevOps Chat: Shift Ops Left, Shift Dev Right with Kristian Stewart, IBM

    DevOps Chat: Shift Ops Left, Shift Dev Right with Kristian Stewart, IBM

    In this DevOps Chat we speak with Dr. Kristian Stewart of IBM’s Cloud Event Management team. Kristian has some keen insights into the role of dev and ops and how they interact. Kristian calls it Shift Ops left, shift dev right. An interesting way of looking at things.

    As usual the streaming audio is immediately below and the transcript of our conversation is below that.

    Audio

    Transcript

    Alan Shimel:               Hello, everyone, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Got a really hot chat today and my guest joining me is Kristian Stewart of IBM’s cloud event management team. Kristian, welcome to DevOps Chat.

    Kristian Stewart:         Thanks very much for having me, Alan.

    Alan Shimel:               And I just wanna make sure I got it right – it is Kristian Stewart, right?

    Kristian Stewart:         Last I checked.

    Alan Shimel:               Okay. Well, sometimes my funny French accent throws people off, but, anyway – and, Kristian, I mentioned you’re working with IBM in cloud event management, but give our audience a little bit behind that. What exactly does that mean?

    Kristian Stewart:         Well, let me give you a bit of a background ’cause there’s some history here, in particular with respect to the topic of the podcast, which talks about operation tools. So I’ve been with IBM for ten years. I’m one of the lead architects for a suite of IT service management tools, and my own specialization is in event management, as part of IBM’s Netcool brand, okay? So I’ve been in this industry for 18 years.

    I worked for a small start-up back in the late ’90s – the company was called “Micromoves,” and we were focused on introducing tools for disciplined fault management into telcos, into communication service providers, during the dot-com boom of the late ’90s. And then, in the early ’00s, we pivoted and successfully sold into enterprise, finance, retail, as their IT infrastructures became larger and more complex and as they matured, from an IT operations perspective. So we were acquired in 2006 and we started to work towards applying interesting mathematical and analytical techniques, for increasing the value provided by our tools, and applying machine learning and problems to this space. So that was my background up until about three years ago.

    So what do I mean by “cloud event management”? Well, more recently, as part of the movement of the industry that we serve, as they move into cloud and their investment in cloud has increased, I’ve been working with teams to build software-as-a-service offerings  capabilities we had, till that point, only available on-premise, so it includes alert notification tools, runbook automation tools, and cloud event management. And so our particular interest in DevOps is twofold, right? So our transition itself, from going to shrink-wrapped client service software, that was originally deployed on-prem, has gone through to the development of cloud-native, cloud-scale, public cloud resident offerings, and with our guys embracing paradigms like micro-service architectures, 12-factor apps, and, of course, DevOps.

    And one of the biggest challenges or one of the biggest changes our teams have had to endure is that they now have to operate these deployments themselves, right? So they’ve gone from shrink-wrapped, “Give it to the client. Now it’s their problem,” – well, kind of – through to “Now we’re hosting this for you.” So we’ve had folks from development and QA transitioning to operations roles, and they’re required to apply software engineering skills and work with app developers to ensure that we’ve got robust capabilities in private cloud. And we’re providing 24/7 ops to support these offerings.

    But we find ourselves in a fairly unique position because we’re running operations but as a service product that themselves are designed to help people responsible for running operations for their own apps and services. So it’s just sort of a renewed empathy for our end users, especially as we start to angle our offerings towards teams that are embracing DevOps. Does that answer your question?

    Alan Shimel:               Yeah, and then some. [Laughs] But good stuff, Kristian. Thank you very much. So wanted to talk a little bit today bringing this back home to DevOps, right? And one of the trends that we’ve been seeing over at devopsy.kinsta.cloud recently is, really, around kind of putting the “ops” in DevOps, right? ‘Cause we’ve spoken now to a few folks in the DevOps space from both the vendor and practitioner side, who are really emphasizing the role that ops plays in DevOps. And one of my things about it, though, Kristian, is I get the opportunity to speak to a lot of people like yourself, a lot of people who are heavily invested in DevOps, but I also get a lot – the chance to talk to a lot of people who aren’t and are new DevOps or just dipping a toe in the water and planning their DevOps migration and transformation.

    And one of the things that I try to remind people is that “Don’t leave your common sense at the door,” at the DevOps door, right? Bring it with you, number one. And, while you’re bringing something with you, it doesn’t mean everything you’ve done in ops to this point and all the lessons learned and best practices accumulated get thrown out – you know, the baby with the bathwater. With DevOps, we evolve. We’re not necessarily revolutionizing; we’re evolving. And so building on best practices and time-tested ops practices and methodologies and processes is probably a better solution than, you know, scrapping the whole thing and starting from scratch. And who has the opportunity to do that anyway? What do you say to that, Kristian?

    Kristian Stewart:         Oh, I agree completely. And, you know, amongst our clients, we’ve got a whole array of clients, from telcos to finance to retail, right? You name it. Across those clients, we have people on varying points on the curve of maturity, with respect to adopting DevOps. But what I say to those clients, as they look at those paradigms, is that the business objectives of operations teams haven’t changed substantially, certainly since I’ve been in the business. There’s a lot that has changed, but the business objectives continue to be measured by KPIs like mean time to repair, mean time between failures, and pressure on costs, right?

    So disciplines – so, within a, let’s say, a mature enterprise that have invested heavily in ITIL, they adopt disciplines like event and incident management, and that leans on a key set of capabilities, which are equally applicable when you transition to DevOps. You know, the proximity of your developers to your operations and the smoothing of the processes and the interactions between those organizations, if anything, are enhanced by some of the traditional methodologies and tools. So, you know, to list some of them, you need tools which can consume events from highly heterogenous environments; you need to minimize the amount of management noise that’s presented to the people who have to respond to events; you need to be able to integrate with other systems; you need to be able to help pinpoint probable causes, drive efficiency in operations, do things like apply machine learning and advanced analytics to gain insight from your event and incident data.

    So, if you look at the evolution of these practices, historically, right, ITIL emerged in parallel with the practice of event incident management. It didn’t dictate it. You know, these standards emerged as – sorry, event and incident management emerged as de facto practices, driven by the availability of practical tools to solve real problems, and they still solve those problems. You know, if you look at the way that operations has evolved, look at telecom from the late ’80s and early ’90s, right?

    So, in a telco network operations center back then, you might have had dozens of very highly-skilled people, _____ network engineers, with training on dozens of different management tools, and these guys and girls were expensive, right? I mean, their time cost a lot of money, and then the introduction of event and incident management tools helped transition from that to having perhaps the same number or even more operations staff of a substantially lower skill. And so the first thing event management and incident management did was to try and lower the cost of entry for running an efficient operations team.

    But now, if you look at the changes in IT management now – so I was chatting to a large enterprise just the other day, and, ten years ago, they – so these guys have always been driven by those same metrics – MTTR, MTBF, cost, right? A few years ago, their job was to provision physical hardware, static middleware, and the management of that stuff from an operations perspective. Now these guys are having to provide platform-as-a-service tools, distributed runtime container and orchestration systems, and they still have responsibility for the existing infrastructure – the network, the physical servers,  the legacy monolithic applications. And all that still requires management. So, mainly, they’ve got the challenge of managing hybrid cloud, coupled with extremely tight expectations on time-to-market that working practices like DevOps and Agile software development allow for.

    So I’d say that event and incident management tools are as relative now, if not more so, than they ever were because, when you shift to practices like DevOps and site reliability engineering, you know, back to the olden days where you have ops employing of hundreds of you know, low-skill operators, best practice is transitioning to one where you have a substantially lower number of substantially higher-skilled operations staff. Right? So these guys and girls are highly skilled, but they’re time-poor. You know, your typical operations professional, in an organization that’s embraced DevOps, wanna be concentrating on automation, on liaising with dev early on in the release life cycle, on prepping for new rollouts. They don’t wanna be grappling through log files and sifting through performance metrics to find out what happened just so they can restore a broken service.

    And I think the eventual goal of the kind of tools that we provide – event and incident management – isn’t just to help the operator find the needle in the haystack; I think it’s to hand them the needle. And that’s useful, whether you’re a low-skilled junior operator in old-school operations or a time-poor, hyper-technical site reliability engineer with 20 years’ experience. Alan, you still there?

    Alan Shimel:               Yes. Kristian, I’m sorry. I had a little internet issue. So all really good, but, you know, one of the things I wanted to touch on, Kristian, is the subject of empathy, as part of kind of your DevOps mantra, right? Sometimes, people give cultural things short shrift, but empathy is important in DevOps. And what I wanted to ask about was the idea of “How do we get developers?” Right?

    For a long time, the ops people have sort of had to empathize with developers are doing and what they’re doing in terms of development to help in deployment and stuff, as part of DevOps, but now, putting that on the other foot, right, getting developers to empathize with what the ops folks are dealing with, as part of this DevOps equation. I mean, I’ve heard of some organizations where they’ll actually embed developers on the ops teams for short periods of time so that they get empathy the hard way, if you will, right?

    Kristian Stewart:         Yeah.

    Alan Shimel:               They gotta live it. What do you think about something like that?

    Kristian Stewart:         I think, in terms of getting the development professionals involved, I think – so you mention role rotation, right? And I think that’s one tactic. You know, I like to think of this as much as “shift-right dev,” as it is “shift-left ops,” right?

    Alan Shimel:               Yeah.

    Alan Shimel:               Good. Good.

    Kristian Stewart:         And, actually, you know, it reminds me of the situation in shrink-wrapped software development, maybe 20 or 25 years ago, between development, who were the coders, and QA. Right? So there was sort of a brick wall, prior to Agile software development, where it was throwing a pile of code over the wall. And I think Agile, with that shift-left testing, really helped to remedy that, to the extent that I see, today, developers and quality assurance engineers working really, really closely together and not depending on, you know, reams and reams of documentation to communicate with each other.

    So, I think, with DevOps, I think a similar thing is happening, and I think you need shift-right dev, as well as shift-left ops. So operating an application or a service, I think, has to be a shared responsibility, and I do think that dev need to get skin in the game. So that’s gonna include dev as an escalation point, when an incident occurs. It can also include role rotation. But, for mutual benefit, I think they both need to use the same operations tools, right, so that they see what each other are doing, when an incident or a critical event occurs in the environment. And then they’re motivated to improve the use of those tools for themselves, as well as for the sake of operations.

    I think, you know, a 3:00 AM incident notification, you know, like a page at 3:00 AM, is a great motivator. So, for ops people, it’s an incentive to get runbooks and automatic incident responses written so that service restoration is as quick as possible and, preferably, automatic. With dev, it’s an incentive to make their services or applications operable, right, so they need to get the right amount of instrumentation into the app so that ops can manage an incident or, better still, that some script can, so that neither of them get the 3:00 AM escalation. So I think there’s a – with all due respect to my dev and ops colleagues, there’s a carrot-and-stick approach there.

    Alan Shimel:               Mm-hmm. Yeah, that makes perfect sense. Kristian, I want you to repeat what you said before. We need to shift ops left and shift devs right or did I have that backwards?

    Kristian Stewart:         Yeah, no, yeah, that’s what I said. Shift-right dev and shift-left ops, right?

    Alan Shimel:               Got it.

    Kristian Stewart:         So get them to have a degree of overlap with respect to their responsibilities. And, of course, what they do in response to those responsibilities can be quite different. You know, let me see if I can think of an example. So, for devs, under those circumstances, when they’re being involved in responding to an incident, it can be stuff as simple as being really clear in their application logs.

    So, if you think about events that are generated by, say, a container-based app deployed on Kubernetes, okay, so the event and incident management system is gonna be presented with logs from the app code; they’re gonna be presented with logs from middleware; logs from Kubernetes itself; logs from, potentially, external technologies and monoliths – NFS mounts, databases, legacy apps, network; and they may also be getting alerts from monitoring systems that are watching performance metrics for the running container, so transaction request rate between micro-services, CPU utilization, response time.

    So, if devs can make sure that something as simple as the concept of criticality or severity is included in the logs, that really helps with filtering _____ ops figure out whether or not something’s really a problem. You know, for example, is this event classed as a trace message? A debug message? A warning? An error? Is it known that this is service-affecting? Right?

    Alan Shimel:               Yeah.

    Kristian Stewart:         And, you know, how better to motivate devs to implement those sorts of practices than to make them consume log messages that are completely uninterpretable, right?

    Alan Shimel:               Agreed. Agreed. Hey, Kristian, we’re over time already, but, as I told you before we started, the time here goes quickly. But, you know, boiling all of this down, the last – whatever – 18 minutes down, really, I wanna make the point of – and I loved what you said about ops shift left, dev shift right – that our ops and devs can work together. And, as you said, they each will have different reactions with different roles and responses to given incidents or given stimuli, but they can work together and we can build on what ops has built over the last 50 years of the IT industry. And –

    Kristian Stewart:         Mm-hmm.

    Alan Shimel:               Right? We don’t leave that at the door of DevOps; it’s part of it. And one thing I want – you know, if we can ask people to take that with them. And you agree that’s key takeaways here for them?

    Kristian Stewart:         Absolutely. Couldn’t agree more.

    Alan Shimel:               Fantastic. Hey, Kristian Stewart, IBM, thank you for joining us on this episode of DevOps Chat. Love to hear more in the future about what you and the IBM team are doing around cloud and hybrid and some of the other stuff kicking around. And we’ll have you back again soon, but, for now, thanks for being our guest this episode.

    Kristian Stewart:         Alan, it was an absolute pleasure.

    Alan Shimel:               Great. Hey, this is Alan Shimel, everyone, for devopsy.kinsta.cloud, DevOps Chat. Thanks for joining us and we’ll see you soon on the next chat.

    — Alan Shimel

  • From Waterfall Incident Management to Collaborative IT Operations

    From Waterfall Incident Management to Collaborative IT Operations

    What can Ops learn from Dev in the transition from sequential, reactive IT support to real-time DevOps?

    One of the signature ideas of DevOps is right there in the name: the blurring of the boundary between the historically separate worlds of Development and Operations.

    On the face of it, this seems like a great idea. Developers have always grumbled about how Operations is preventing them from deploying as rapidly or as frequently as they would like. Meanwhile, Operations people have harbored a dark suspicion that developers might code with more attention if they were the ones getting paged at 3 a.m.

    Another of the great things about DevOps is that it is pretty easy to adopt in one area or project without needing to get the entire company onboard before you can get started. This means that you can quickly produce some interesting results in terms of accelerated development times and release frequencies, faster resolution of problems and more time spent innovating instead of firefighting.

    Armed with these results, DevOps evangelists spread through the organization, telling their story and recruiting other departments and teams to join them in the bright future.

    This is Where the Problems Start

    Complex enterprise IT environments are, well, complex. Different teams have adopted different tools and methodologies to do their jobs, and are justly resistant to throwing out something that works for them. Specialists in different areas require their own specialist tools to be able to do their jobs. Because of this, when an incident occurs, all of that agility and collaboration that DevOps brings goes out of the window in favor of something that looks much more like a classic “waterfall” approach:

    • When an event is received, it is routed to one particular team
    • The event is placed in a queue
    • Eventually, someone from the relevant team takes a look at the event and makes a determination of whether it falls in their area or not
    • If it’s in their area, they begin working to resolve the issue within their team
    • If it’s not (believed to be) in their area, they reassign it, either back to the front-line team, or to whichever team they believe to be responsible (often, this is the network team)
    • Repeat until either someone takes ownership and fixes the issue, or it becomes a Major Incident and everyone gets paged at 3 a.m.

    Just to complicate matters, there may be multiple instances of this process going on at any one time, as two or more different teams grapple with what eventually turn out to be different aspects of the same problem.

    Why Does This Happen?

    In health care, there is only so much that can be done by way of prevention. There is always the need to react to patient’s issues, starting from their symptoms. In the same way, the starting point for Operations is monitoring—gathering the symptoms of the IT infrastructure to be able to return it to health as quickly as possible.

    To understand problems with the Ops part of DevOps, we needed to start at the beginning, with those symptoms. We wanted to do this the scientific way, so we polled attendees of Velocity and Monitorama to understand their top monitoring challenges.

    The interesting fact was that across both populations, the main challenge listed by attendees was “alert noise/fatigue/volume.” Simply put, Operators were drowning in alerts to the point that they had completely lost the ability to understand what was actually important, let alone an overall picture of how those alerts related to the service that IT was supposed to deliver.

    This is another parallel between IT and health care, where alert fatigue has long been a concern, and with potentially far more serious consequences than in IT.

    A big part of the cause of the alert fatigue on the IT side is the proliferation of specialist monitoring tools. In the poll, 66.67 percent of people we surveyed have five to 10 monitoring tools in place, and yet 61.90 percent of them are still struggling with that problem of alert noise/fatigue/volume.

    To be clear, those different tools are each very important. Trying to monitor the network with an APM tool is probably not going to go well for you. They only become a problem when it becomes too difficult to build up an overall picture of what is going on, and sharing that between different people to solve problems faster.

    So What Can Be Done?

    Dedicated Operations organizations have long worked to assemble tools and techniques that can give them a complete view of the environment that they are supporting, and of the services that run in it. The accelerated pace of release that comes with DevOps is causing the old models to break down, but fortunately, it also carries in itself the seeds of a new approach to the problem.

    As development moved from the sequential waterfall model to a more rapid, collaborative, and agile approach, operations teams can learn from that transition to come up with a more agile approach to IT Ops.

    What would this look like? The first thing to do is to get rid of the blame-storming and buck-passing: “It’s the network!” “No, it’s the database!” I don’t know about you, but personally, I’ve been in enough of those meetings to last me for the rest of my life, thank you very much.

    Let’s All Go Fishing in the Data Lake

    Instead, a common perspective is needed, so that everyone can quickly agree on what is going on and what needs to be done.

    This does not mean throwing out all of those specialist monitoring tools! They are there for a reason. Rather, gather all of those symptoms in one place where the whole team can collaborate to make sense of them more easily. These days, it should be easy to get information in and out of the various components of your toolchain (and if it’s not, that’s a glaring warning sign that maybe it’s time to migrate off that particular tool).

    This will, of course, produce a huge pile of data, so it’s not sufficient to stop here with the creation of a “data lake.” Things disappear into lakes and are never seen again—in which case, why did you bother gathering them in the first place?

    What you need is a way to make sense of what is going on in the lake, and show that to the right human operators. In the same way that developers resent sitting around waiting for the Change Advisory Board to meet, operations people get frustrated and bored just staring at a screen waiting for something to happen. If instead you can use automatic techniques to assemble all the related symptoms of a single issue together in one place, that will give you a good starting point to resolve that underlying issue quickly.

    Brainstorming, not Blamestorming

    This is where the collaboration comes in. Again, people are doing this already, but they are doing it in a disconnected way. The tools have evolved, from email and IRC, to Slack and Google Hangouts, or even (heaven help us all) WhatsApp. What has not evolved is the usage model; it’s still ad-hoc and reactive, and requires lots of copying and pasting.

    Operations people can learn from what their developer colleagues have built or adopted. Kanban boards are a great technique for tracking open issues and who is working on them. ChatOps is a fantastic way to integrate human-to-human communication with human-to-machine communication. Integrated collaboration tools capture knowledge that otherwise is stuck in people’s heads or inboxes, unavailable to their colleagues.

    I’m an Ops guy at heart, but I can recognize a good idea when I see it. Our Dev colleagues have come up with quite a few that we could stand to adopt in Ops. Let’s learn from what they already know to work, instead of trying to reinvent the wheel.

    — Dominic Wellington

  • DevOps Chat: Rundeck, Putting the Ops in DevOps, with Damon Edwards

    DevOps Chat: Rundeck, Putting the Ops in DevOps, with Damon Edwards

    In this DevOps Chat we speak with Damon Edwards, co-founder and chief product officer of Rundeck. What I like to say about them is, Rundeck putting the Ops in DevOps. But Damon needs no introduction to those who have any familiarity with DevOps. He is one of the early leaders of the DevOps community and continues to evangelize DevOps around the world. In fact, he is speaking at our DevSecOps event at RSA APJ in Singapore July 25, which you can find here.

    It has always been a hope of me personally to have Damon as a guest on DevOps Chat. Besides being a great interview, Damon and Rundeck are a great story of an open-source project growing organically, spawning a great commercial business. This is harder than you think and Damon tells us a bit about it in this interview.

    As usual, the streaming audio is immediately below and the transcript is below that. Enjoy!

    Audio

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel, editor in chief of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. We’ve got a really, really special guest for this DevOps Chat, it’s one of my heroes in the DevOps movement from when I first started researching what DevOps was and it’s about. I’m thrilled to have him appear on our DevOps Chat today, none other than Damon Edwards. Damon, welcome.

    Damon Edwards: Thank you, Alan. Thank you for having me and thank you for those kind words, I’m excited to be here.

    Shimel: Thank you. So Damon, I’m going to guess a lot of people in our audience have heard of Damon Edwards, instrumental in putting together DevOps Days, especially DevOps Days at Silicon Valley kind of drove that for a number of years. You had several different companies, both open sources and consulting, and probably maybe even more than all that, Damon, you have appeared—I don’t even know if you keep count any more—at how many different DevOps Days events or other DevOps related events where you’ve spoken at. I mean, do you know? Have you kept track?

    Edwards: I don’t know, [Laughs]. I know it’s less than John Willis, because he reminds me of that on our podcast, but DevOps Café, I’m going to give a cross plug for that. We just had you on, Alan, as a guest, and you were fantastic. Yeah, I kind of lucked into just sort of right place/right time. We were really interested in how do you move fast—we called it Dev2Ops ourselves internally, our consulting business we used to call DTO Solutions that we have. And it was really all about how do you help organizations move faster? For a long time, scale was the problem. Hey, how do you deploy, hook into a thousand servers, right? A thousand servers used to be a big deal. And then it suddenly came to be that, hey, we can deploy anything to anything, that’s not really—deployment scale is not really the problem, speed is the problem. That organizations can’t move fast enough, that the pipeline is jammed, that the organization is kind of stuck in cement. And the organizations that are able to free themselves and decouple themselves and move in this new and fast way had a strategic advantage, were really kicking the butts of the big traditional companies that were kind of locked in place.

    So we really started asking ourselves, why is that? Our customers started asking us, why is that? And that really got us into lean and all those things. And at the same time, John Allspaw gave his big talk at Velocity, I saw that, you know, fell in with John Willis and Thatcher Dubois and the rest of the crowd and the DevOps movement was born. And we kind of became known as the folks who are great at taking the design patterns that you see on stage at the big high flyers and translating them to the big enterprises out there. So that was DTO Solutions.

    Then along the way we had a side project called Rundeck that was an open source tool, I’ll get to that in a second, but it really just took off. And after awhile, enough people called us about Rundeck, we really got excited about it, and there are two reasons why we decided to jump with both feet into Rundeck. The first being that I feel like operations is a DevOps frontier that’s not truly explored yet. I think in a lot of big organizations the dev side, they’ve got dev talking better to QA, they’ve got the build pipeline going, the little dev test cycles are going a lot faster. Maybe deployment’s happening a lot faster. But these DevOps principles haven’t really entered into full operations mode yet. A lot of big operations organizations just haven’t been able to transform themselves, and we saw DevOps, especially we saw Rundeck as a tool being used just to do that. So as a way to, number one, I think we were always product guys at heart, we wanted to see where we could take it. But number two, I really feel it’s helping push the DevOps movement to a new place.

    Shimel: Yeah, I agree with you. And Damon, just again, adding a little color, you actually have a video up somewhere, it’s kind of a brief history of DevOps. For any of our listeners who really want to know kind of how DevOps got started, Damon has a great video on that that I’d highly recommend. But let’s jump into Rundeck. Damon, as you mentioned, it was a side project to what you were doing with DTO. It was open source, wasn’t it?

    Edwards: Yeah, Rundeck’s core is it’s an open source product, an open source community. I Think last time we did some sort of estimate. There’s around like 25,000 different open source users out there. So it kind of became this silent—for us, we woke up one day and said, wow, a lot of people are really using Rundeck, and they were calling us saying, “Hey, we really want to do more with Rundeck,” and that led to the formation of what’s now Rundeck Inc.

    And if you want to talk about what Rundeck actually is, fundamentally, from a technology perspective, it’s an orchestration and scheduling platform. Right now a lot of orchestration happens within different silos, so there’s container orchestration, there’s configuration management orchestration, all kinds of different things like that. There’s enterprise job schedulers. But we noticed that as folks are transforming their operations organizations there was this layer that needs to span all of those different silos of tools, all the different islands of automation that they have, all the different systems that they have. They want to create procedures, operational procedures that span all of those different silos. And they want a place where they can define those procedures using whatever scripting language that they want. They want to be able to define the work flow, they want to be able to set security around it, that’s huge, because what a lot of people are doing in those procedures is not just helping their operations teams be more efficient and effective but they’re starting to open up more of a self-service model. Self-service operations is the big design pattern that I think is really driving us forward.

    Which is, all these people that need to do operational things throughout my organization, and as I start to transform my organization, how do I safely let them do things that could be deployment but it’s often remediation activity, diagnosing things, just doing operational things that I need to do, how do I let an ops team define those and be in charge of those and say who can do what, when and where, but allow other people to participate? And by participate, I mean two things. One is give them the button or the API to hit themselves to do the operational things that they need to get done, but also give them a mechanism to which those different teams, often in different business units, can define those operational procedures for the things they’re creating themselves, then have a standard mechanism to hand it off to operations where ops and security can vet them and then that ops and security vetting process can then turn around and give access to those other teams. So it’s like how do we let the operations decouple, let more people participate in operations, and do it all in a safe, sane and secure and audited and logged way? That’s where Rundeck shines.

    Shimel: Got it. I mean, Damon, you opened a bunch of different things in here I want you to kind of flesh out a bit. So number one is this whole idea of ops, right? My personal opinion is for too long with DevOps there was a very developer-centric focus of DevOps, and really, at the end of the day, ops is where it’s at for a lot of different reasons, especially in the world we’re living in. And you’re clearly working in there. But we’re not looking to recreate silos, right? There’s a place for the development team, right? They interact within Rundeck, if you will, with the ops folks, right? This isn’t for ops only kind of thing.

    Edwards: Right, right. If you look at organizations today, again it kind of goes back to our statement before about how scale is no longer the problem but organizational speed was the problem that caused the DevOps movement. And if you look at what’s going on with operations it’s a very similar thing. It’s not scale of the infrastructure as much as it’s complexity and scale of the organization that causes the problems. So in a lot of large enterprises, most every large enterprise, you have this central place called operations. Just kind of put the teams out of the way at this point, just think about the action of running all these things. You have all these different streams of activity that come into this central place, and that has to all hang together to form this enterprise. That is operations. That is the business. That’s where all the money is made. All these streams of development activity that come into that, essentially they’re part suppliers, so the next version, the next cogs in the machine that has to run, but it all has to hang together or we aren’t making any money, unless you actually sell software, which very few companies do these days, your running the service is the business. So operations is very important. But in that same vein, that operations, because things are so tightly coupled and it all falls to this one often central team, that becomes a huge bottleneck and a big problem, and it really ends up stunting or blocking the DevOps. That decoupling transformation that these organizations want to go to, they get blocked by the sort of calcification of the classic operations domain.

    And so we see these high flying organizations, what they’re doing now, the high performers, what they’re doing is a frame of how to uncap and decouple all of that operational activity. And in doing so, they’ve kind of realized there are three key pieces to what you’re working with. There’s the ability to—who defines the procedures? Who defines the procedures for the things that they’re going to be running. The second is, who can push the button for those procedures, button meaning through a GUI or through an API. And then third, who has the secondary or the operational, the management control of that action?

    Traditionally that all kind of fell to one group or one team and they’re grossly outnumbered by the rest of the organization and that became the big ops bottleneck. Their whole mindset was all about let’s protect ourselves from being overrun. Let’s protect ourselves because people are pushing things at us that they don’t really know how it’s all going to hang together, they don’t have that responsibility for defining things. So ops was in a very, very tough position and doing their best. We see these organizations doing a bit of a Tom Sawyer paint my fence or a jujitsu move by saying, hey, let’s redefine who does what where. Let’s allow that definition. Let’s allow those teams. They created these things, let’s allow them to participate in the definition of these operational procedures. And then let’s also, once it comes back to us, let’s let them push that button as well—for some things, not everything—maybe just certain non-destructive things, or maybe certain teams can deploy but certain teams we don’t want to deploy because it’s a different type of system or different security requirement. And you can move those things around and ultimately you can keep that third piece, the management and the compliance and the audit security control, with that traditional operations organization, or traditional operations skillset or management skillset who wants to control those things.

    So in this self-service design pattern it’s about dividing those three things up—the definition of the automation, the execution of the automation, and the management security compliance control over it—and allowing those to be moved to the parts of the organization where it makes the most sense for the flow of the business, speed, taking advantage of the labor that you have. It’s that mindset that these operations organizations are using to transform their organizations. When we saw that happening we were like, wow, that’s something really cool, and we jumped in with Rundeck Inc. with both feet.

    Shimel: Absolutely. Let’s talk a little bit about Rundeck Inc. as you called it. So Damon, was it about nine months, maybe more, maybe a year ago now, you and your—I’m drawing a blank, I apologize –

    Edwards: Alex Honor.

    Shimel: Right, Alex Honor, you and Alex have been doing Rundeck for as long as I know you. But about nine months or a year ago you brought in sort of a professional CEO, someone who I’ve known for years, a tremendous person based out in the Valley, Stephanie Fohn, as your CEO. And it really went from being Rundeck’s a side project of DTO Solutions, to Rundeck Inc.

    Edwards: Yeah, we jumped in full feet. We luckily landed Stephanie, it was a big coup for us. I think she described our situation “an embarrassment of riches,” and I wasn’t sure if she was emphasizing on the embarrass or the riches part. We started what’s now Rundeck Inc. as kind of an experiment to see, hey, what’s going to happen? It was Alex, myself, Greg Schuler, as lead developer of Rundeck. Alex is the founder of the Rundeck project. We had a small team going, we had some engineers scattered about, and things were working. But next thing we looked up and we had a whole bunch of large enterprises that were paying us for the early version of Rundeck Pro, which is sort of an enterprise enhanced version. There’s all kinds of features and extra plugins that really matter if you’re doing this stuff at scale. The open source is really defined for if you’re just a team and you need to define buttons and push buttons, then the open source is fully featured and there for you. Rundeck Pro is really about kind of adding things around and on top of it that the boss cares about, that big organizations care about.

    So we looked up and things were doing well. Stephanie came in and said, hey, we’ve really got something here and I want to be a part of it. So it was a big score for us. She is very well known on the security side of the house, a number of great successes there. She’s kind of found that operations and security is a very similar mindset, very similar set of people, and she’s really taken to it. Yeah, it’s been great, she’s brought in even more professional people.

    Shimel: It’s grown up to a company.

    Edwards: Yeah, we’ve got over 50 enterprise customers so far and we’re growing fast, so it’s a pretty cool, pretty fun ride.

    Shimel: Damon, your role now in Rundeck Inc., if we can call it that, is you are CTO and obviously cofounder, but CTO and evangelist, but your hands are still getting dirty talking to customers and helping.

    Edwards: Yeah, I’d say that’s mostly what I’m doing. Actually, Alex is the CTO, I’m the, I guess, Chief Product Officer, or head of product, these names that, you know, it’s a typical start-up, right? I focus a lot on the evangelism, a lot on the product side, a lot on helping customers figure out, A, well, figure out what they’re doing with Rundeck, and then also, B, help them figure out what they want out of Rundeck and driving that forward. So I’m still intimately involved with the DevOps community and out on the road doing that because I believe this is the next frontier, this is where you have to go. Straighten out your deployment pipeline and getting automated testing in there is a great thing, but if you’re any organization of any scale, this is the next major issue. You need to transfer operations otherwise you’re not really meeting the full DevOps vision. And the companies that are, have a distinct advantage over you.

    Shimel: You know, Damon, to me, DevOps is still very much like right out of the goal, where you solve one bottleneck only to find the next bottleneck. And that’s what we do is we keep knocking them down. And as you knock one down, another one further down the road shows itself. And I think that’s what we’re seeing in DevOps, is as we knock down bottlenecks in the CICD arena and configuration management arena, ops becomes where the next series of bottlenecks are, and that’s what obviously Rundeck is hitting in there.

    I wanted to talk a little bit, Damon, about a particular subset of this, and that’s DevSecOps. I think you almost inadvertently maybe backed in to the wonderful world of as we call it now cyber security or InfoSec or whatever you want to call it. Inherent in that ops mission is the idea of deploying securely and keeping a secure infrastructure up and securing your apps. And this is something that Rundeck is spending more and more time, more and more resources, more and more of the focus that I’ve seen anyway is involved around this DevSecOps mission. Comment on that?

    Edwards: Yeah, I’d say it’s sort of the intersection of security and operations. Really security, operations and governance. That if you think about what’s going on now—especially, well, two big trends. There’s the digital transformation trend, which is really just saying all of my systems need to be interconnected now for a consistent customer experience, that’s something the business wants. And then there’s all these new server lists, containers, the new API world where everything’s an API. So now we’ve got to define these procedures that span all of these different systems that used to be stand-alone stovepipes. And, everything’s turning into an API, so I’ve got to have a way to secure that, I’ve got to have a way to figure out who’s who and who can do what. So we kind of fell into that in terms of people use Rundeck as that tool, to say, hey, I’ve got my Chef automation over there, I’ve got some Kubernetes stuff over there, I’ve got some legacy stuff over there, I’ve just got a bunch of scripts I need to run over there, I’ve got these different Amazon services I need to hit, Akamai and these kinds of things. So they’ve got all these different things, buttons they need to push, and they each have their own logins, each of their own sort of way of managed security policies.

    So they look at Rundeck and say, hey, this is a place where we can enforce policy, or enforce this authentication and enforce the security controls. By defining these Rundeck jobs, it becomes a nice abstraction for that to say they can just call all this stuff, it’s real easy to string it together, and then I can define who can do what and where, and I’ve got the full access. In a lot of ways we call it like the key card and the camera. You can define who can do what through Rundeck, sort of the key card in your office building. But then there’s also a bunch of cameras, right? Not that we don’t trust you but we have to prove that you didn’t do anything bad with your keycard. So the kind of keycard and camera metaphor, we talk about that internally, but we should probably talk about that more externally. It’s something that we see a lot of people implementing with Rundeck in this new world. It’s a way to satisfy the security and governance demands but also do the new ops stuff.

    Shimel: Damon, we’re a little overtime already but I wanted to just quickly mention that you’re going to be appearing at RSA APJ, which is the largest info sec or cyber sec related show in the Asia Pacific region. We’re putting on a full—we meaning Sonatype, DevOps Connect and a few others—are putting on, Rundeck is a sponsor, is putting on a DevSecOps day there, and you and John Willis are headlining, and for any of our listeners who are in Singapore or around Singapore, that’s on July 25. And on July 26 I think we’re going to try to do a mega meetup group, several meetups, different meetup groups within Singapore. Also at RSA APJ, and you and John will be presenting there as well.

    Edwards: Yes, we will. You guys do a very good event. We’ve done the one here in San Francisco, excited to do the one in Singapore. Singapore is actually a great DevOps community out there with all the banking and finance and whatnot. It’s good work being done there. And the event’s great. It’s not just for security, it’s really looking at the end-to-end pipeline I’d say. It’s more like how do you bring these enterprise concerns into the DevOps story. And I don’t want people to think it’s just, hey, if I’m not in security, I don’t need to go to this. I think it’s really good for anybody who works in the enterprise and wants to think about the nuts and bolts of how do we get this stuff done so we can move fast and be secure or sure in what we do.

    Shimel: Absolutely. And you mentioned RSA, Damon, actually I’ll have some news about that hopefully within the next week—RSA San Francisco next year is April in San Francisco and I think we’ll be doing a DevSecOps day there as well. I think you presented, we’ve done three or four of these, I think you’ve presented at all of them, actually.

    Edwards: I’m a supporter. I’m a supporter of the Alan Show.

    Shimel: Well, you know what, to me it’s about bringing these two tribes together. It was something that Gene Kim and Josh Corman tried to do and I’ve tried to help, and Mark Miller and the Sonatype folks. And Damon, you know what, it’s paying off because I spend a lot more time in security just because of my background, and I’m hearing from—I’m not getting the pushback I used to get from people about DevOps any more. They get it. Or they’re starting to get it. God hopes. Anyway, Damon Edwards, we’re way past our time, but that’s okay, it was worth every minute. Thank you for being this episode’s guest on DevOps Chat. We will see you in Singapore. You know what though? For people who want information about Rundeck, where can they get more information?

    Edwards: Rundeck.com. There’s a free trial of Pro. You can always use the open source. We’re on IRC, we’re available, so we’re around. Feel free to reach out to us and we love talking about this stuff.

    Shimel: Cool. Damon Edwards, co-founder, chief product officer of Rundeck Inc., and also DevOps evangelist extraordinaire. Thanks for appearing on DevOps Chat and we’ll speak to you soon.

    Edwards: Thank you, Alan.

    Shimel: All right. This is Alan Shimel for devopsy.kinsta.cloud, DevOps Chat, and we’ll see you soon on the next chat.

    — Alan Shimel

  • DevOps: The Innovation Power Couple

    DevOps: The Innovation Power Couple

    If “Dev” and “Ops” are the power couple of tech, “DevOps” is the holy matrimony that takes innovation from trainwreck to fast and repeatable. At most businesses, however, Dev and Ops still sleep in separate rooms and agree only on their mutual contempt.

    Dev (Development) and Ops (IT Operations) usually are divorced or ready to serve the papers because their incentives clash. In Ops’ opinion, Dev is an idiot—always out late drinking with friends, he comes up with wild ideas and wants to implement them immediately. Dev can’t make anything work on real servers and can’t write scalable, stable code.

    To Dev, Ops is a total code-blocker—she makes Dev go through “change management boards” and slows down progress. She lets the competition get to market first. So every day, Dev and Ops have an angry shouting match that ends in tears.

    I wish I were exaggerating. My coworker Brandon Cipes once walked into an interview for a product development position. The interviewer broke down crying because the relationship between Dev and Ops had gotten that nasty. They refused to meet with each other, let alone be in the same room.

    When Dev and Ops have a dysfunctional relationship, they struggle to communicate, collaborate and get results. Their organization will fail at innovation because it lacks the cultural, technological and procedural base to do otherwise.

    The missing base is DevOps. It’s a unified strategy for Development and IT Operations, and implementing it can have the following effects:

    1. Communication Becomes Unavoidable

    Normally, Dev and Ops play “telephone” because they’re physically separated and have too many points of communication. Emails, IMs, grudgingly accepted meetings and passing conversations ensure Dev and Ops never get the full message.

    DevOps fixes communication by assigning Dev and Ops personnel to the same teams. They sit in one room and work in a single squad (a.k.a. a pod or team) of no more than eight to 10 people. If they turn their heads, they see each other’s beautiful faces. Until promotions or career change do them apart, they can’t avoid talking and working toward common goals.

    In essence, DevOps puts “cross-functional” teams together and thereby eliminates hand-offs. Fewer points of contact, less telephone, better communications.

    1. Collaboration Gets Automated

    For many Dev and Ops teams, “collaboration” is another word for bureaucracy. It’s TPS report-ish stuff characterized by change review board meetings and laborious documents that tell Ops how to deploy new code. Dev and Ops might accidentally (or intentionally) withhold information from each other.

    In DevOps, collaboration is automated. Instead of change review board meetings, you use version-controlled software. The hand-offs from Dev to QA and QA to Ops are done by machine. A script deploys the code for Ops so there’s no risk of misfiring.

    “Collaboration” is no longer an ordeal or choice. Documenting and sharing the squad’s collective knowledge is wired into the process.

    1. Fast and Stable Releases

    Normally, a software deployment is like a sloth trying to cross US 101: slow, awkward and soon to be roadkill. That’s all thanks to bad communication and bad collaboration.

    With DevOps, you catch problems before they go live. Test automation prevents any need for manual checks. One person corrects the problem in a matter of minutes whereas before, a team of five might spend eight hours tracking down and fixing one bug. Ops feels confident that tested code won’t cause havoc.

    Thus, the upshot of DevOps is speed and stability. Before, Dev and Ops delivered maybe a few times a year and faced regular breakdowns. DevOps can deliver multiple times daily without a hitch.

    Say ‘I Do’

    DevOps is a cultural, procedural and technological transformation. As in a marriage, both partners are responsible for good outcomes. Linked as they are on one squad, Dev learns to care about stability and Ops begins to value innovation.

    If “agile” is about making businesses nimble and quick, DevOps is about applying agile principles to technological development and operations. Ultimately, it’s about beating your competition to the next big thing.

    Dev, easy on the drinking escapades. Ops, live a little. Tie the DevOps knot and make some innovation babies.

    About the Author / Zubin Irani

    Zubin Irani is co-founder and CEO of cPrime, a full-service consultancy that focuses on agile transformations and project delivery solutions for hundreds of software teams, including more than 50 of the Fortune 100. Connect with him on LinkedIn.

  • Swarms: Adapting Guilds To Scale Agility

    Swarms: Adapting Guilds To Scale Agility

    In my first article in this series, “Using Guilds to Combat Information Silos,” I reviewed the adoption of guilds at xMatters. As our company has grown, we’ve used guilds to keep critical information from languishing in silos—as often happens when an organization scales. Guilds have helped our engineers apply their creativity and critical problem-solving skills to other channels and contribute to areas outside their normal scope. It’s a win-win situation for everyone who participates—and especially for the company.

    Implementing guilds began as a grand experiment. We quickly learned a lot about what enhances or hinders a guild’s success, making adjustments and adding a necessary dash of protocol along the way. But, as is the case with any growing organization, new needs and pain points challenged us to adapt and tackle them. One attempt to solve a critical problem led to an entirely new team model: a body we call the Swarm.

    The Swarm arose as a result of key changes in our release protocol. We used to be very focused on getting new features out the door as fast as we could. As it turned out, many of our customers prefer a more predictable schedule. So we gave our customers  flexible options by maintaining continuous delivery of code to production, with flags to stage larger features or more visible changes. Now, customers who wanted more predictable updates could opt for a quarterly release model while others could continue to access features as they became available and were being iterated on.

    While the quarterly release model improved our rhythm for customers, it also created stricter deadlines. A project that just missed a quarterly release could get delayed by almost another full quarter before our customers could start using it. Throwing more engineers at a problem doesn’t necessarily solve it faster—but, being the engineers we are, we thought about ways to parallelize the problem.

    We knew that guilds were very good at collaborating around a shared problem, so we adopted temporary guilds, which “swarmed” around a shared problem, completed work at an accelerated pace and disbanded. Centered around a specific initiative with a definitive start and end, multiple teams from Dev to Ops collaborated to complete a defined project. For instance, we might form swarms to create new product features, and their lifetime would span a finite number of sprints across multiple teams until completion. Due to its nature of focusing on new product features, swarms differ fundamentally from Guilds in that they are typically not self-forming; each one is an entity intentionally designed for a specific purpose.

    We began our swarms experiment with a large architectural change to roll out a new format for our customer hostnames, which involved six Engineering and Ops teams. We realized immediately that this would be an incredibly challenging undertaking on our tight deadline. A slew of teams was working on different stacks in different programming languages, so there were many competing visions and different contextual understandings of the end goal. It became very apparent that the swarm could not be left to operate in a completely flat hierarchy, as a guild usually does. We needed a leader to help ensure there was no duplication of work, things weren’t falling through the cracks and necessary dependencies were completed in the scrum storywriting between teams.

    Having someone take care of all the logistical problems is one thing, but we realized that in-person communication between all the teams in the swarm is absolutely necessary. We tried staying in the loop with each other by defining a process of posting updates from each team in our swarm’s Slack channel, but this was not enough to keep the project on track. Mattius, one of our very talented operations leads, initiated regular in-person meetings across all the teams, which led to far greater clarity. It was absolutely crucial to have all of the teams together and face to face on a regular basis.

    In the end, swarming on this massive endeavor allowed us to get the project delivered a week before the deadline. It was a challenging and imperfect first run, but it absolutely paid off.

    I leave you with these three recommendations:

    1. Create each swarm with a clear purpose and deadline;
    2. Have a leader to enforce consistent communication; and
    3. Have regular face-to-face interactions.

    The lessons we learned were invaluable for refining (and continuing to refine) our approach to tackling projects for faster release, and we’re continually working to improve and enhance this model. Good luck with all your future swarms.

    About the Author / Nick Fletcher

    Nick Fletcher, Engineering Manager at xMatters, started designing and developing websites back in 1998, when the World Wide Web was the Next Big Thing. In the time since that first website, he’s mastered all the aspects involved in creating great products: design, development and strong leadership. Connect with him on LinkedIn.

  • VMs, Containers, Cloud, Cluster: Scheduling Differences

    VMs, Containers, Cloud, Cluster: Scheduling Differences

    Scheduling is a large part of making the data center go, and more to the point of making the virtualized (be it VMs, cloud, containers, or clustering) portion of the data center work.

    While there are a lot of variables to virtualization performance, scheduling impacts performance all of the time. And yet we only really talk a lot about it in clustering (where a robust scheduler on par with an OS scheduler is required).

    There’s a reason for that, and it is worth exploring.

    (Side note: I was talking about this blog with Lori while I was writing it, and she reminded me of when we took our Masters’ courses, the Operating Systems class used Homer Simpsons greedily wanting donuts as our scheduling project. So whenever we think scheduling, we mentally hear one of the many Homer processes being denied a donut and going “D’oh!”)

    For virtual machines, scheduling is largely forgone in favor of other resource utilization. Virtualization only cares about CPUs and memory requirements when the virtual machine is created. You tell it then, and the only time you worry about it again is if you demand more CPU cores than the physical hardware can provide—and in some cases, CPU virtualization will allow you to keep spinning up VMs even after that. Only the real scheduling mechanisms actually can be at odds with each other in a heavy load situation. The host OS scheduler, for example, could swap out your VM’s active thread at the same time the guest OS has raised the level of importance for an app to “insanely high, do it now.” Although this only begins to show if basic rules about servers and loads are ignored, it does happen.

    You get the same issues with private clouds. Why? Because even though everyone in the marketing world pretends it isn’t true, private cloud and VMware ESXi essentially are the same underlying toolset. And usage patterns in the enterprise show not only does everyone know that, but also the differences are less substantial than any of the organizations involved want to admit. Not that they are the same code, but in practice, they do the same things.

    The one place where these two (and public cloud for that matter) really make use of scheduling is when automatically responding to spikes in usage that threaten to bury a system. However, solutions to usage spikes are not part and parcel of these systems; they are crafted by DevOps (or Dev, or Ops) folks who work at places where dropped connections are lost money and, thus, a quick response of growing the pool of available servers and then later shrinking it is important. But because they are using their own metrics to determine the need, more of these systems are implemented in application provisioning tools than in cloud or virtualization software. We could argue about where this functionality actually belongs, but not really where it is implemented today.

    I kind of bled into public cloud there, so will address it. When people talk about it being more “agile” or “adaptive,” they mean “with this quasi-scheduling code we wrote to spin up instances at need.” It doesn’t matter if the “code” is a python script or an Ansible playbook—they did the scheduling, not the system.

    That leaves clustering software (such as Mesos). Because clustering software treats many machines as one big thing, it requires a scheduler to manage the resources. In the case of Mesos, the central scheduler really isn’t that smart, and I think that is a genius implementation. It knows what resources (CPU, memory) each machine has available, it knows what resources have been assigned from that machine, and for each of the “frameworks” (think of them as job executors; though that’s a bit simplistic, it’s perfect for this discussion) what it needs to get its work done. Then it does a best match, offers resources to frameworks and waits for more resources to come available from finished executions.

    So in the world of VMs, if you have 50 unique applications that need resources, you create 50 VMs to service them. In either cloud environment, you do the same. It is a joke we like to make that because of microservices, containers are treated like VMs, except if you have 50 unique applications, you create 500 containers, but the reality is that they are exactly like VMs in many use cases, and make 50 containers when containerizing existing apps. Taking a look at MesoSphere’s 2016 survey of clustering users, you can see that a fair number of clustering users are using containers with Mesos and DC/OS, while many of them are not doing it exclusively with microservices.

    Source: MesoSphere user survey, August 2016

    In the clustering world, you have what presents as one big monster machine that is going to run these applications as resources come available, so if your 50 applications require fewer resources than the cluster offers, they simply execute in parallel; if you don’t have enough hardware to run them, unlike with VMs, you can just queue them up and, assuming the cluster isn’t over-burdened, eventually they all will run.

    This gets more interesting when containers are added to clustering (a common environment), because then you do have discrete containers, but the scheduler still manages how many resources are available/in use, and the container architecture allows the app to carry its requirements with it across the cluster.

    Why do we care? Because you know what your workloads are and which scheduling methodology is more important to your organization. If there are 50 applications that all have steady resource needs and run all of the time, then virtualization might be right for you, but if the organization’s workloads are shifting constantly and resources need to be cycled at a high rate, clustering might be right for you. Either way, knowing what’s out there is never a hindrance.

    — Don Macvittie

  • DevOps Leaders Share 2017 Reflections, Predictions

    DevOps Leaders Share 2017 Reflections, Predictions

    As the New Year kicks off, it is a time for reflection and a chance to look ahead and plan for what is to come. While many are making personal resolutions pertaining to their physique, job performance or travel plans, there is a lot of chatter in the software delivery space around what DevOps will look like these next 12 months.

    Looking back on 2016, suffice to say it was a big year for DevOps. There was no lack of resources for those in any phase of a transformation, with global conferences touting its name to weekly (if not daily) podcasts and webinars designed to share the latest expertise with the community. However, as DevOps moves from buzzword to phenomenon, it will be held to even higher standards and scrutiny, becoming ever-more polished and perfected as challenges are faced and overcome. But don’t just take my word for it.

    Electric Cloud recently hosted a live, online video podcast featuring notable DevOps luminaries discussing their own reflections and conjectures. The panel included Nicole Forsgren, CEO and chief scientist at DORA; Robert Stroud, principal analyst at Forrester; Chris Riley, analyst at fixate.io; Manuel Pais, author at InfoQ and SkeltonThatcher; Alan Shimel, editor in chief at devopsy.kinsta.cloud; Sam Fell, VP of Marketing at Electric Cloud; and yours truly. This article highlights 16 different insights from our discussion with these great minds in DevOps. Here’s to what has been, and what is to come!

    • Expect to see a trend toward strategic DevOps transformations in 2017, according to Forsgren: “I think there’s going to be a huge trend moving forward to do really careful and strategic assessments about where you are, intentional prioritization and strategy about understanding what your constraints are, so that you can do strategic capabilities development moving forward.”
    • Riley hopes 2017 will be the year we stop talking about DevOps and start doing it: “In 2017, we’re going to stop defining DevOps, and we’re going to hopefully use the word a lot less. We’re going to be real about what it is and getting it done. It’s going to be a lot less talk and more doing.”
    • I emphasized that having good architecture in place is crucial to successful DevOps: “What’s starting to happen is that you’re going to have a really hard time doing DevOps well with a crappy architecture, whether that be a crappy architecture for your pipeline or crappy architecture for your application. Application architecture matters in your ability to do DevOps well.”
    • Stroud emphasizes the importance of experimentation in DevOps: “Organizations [will] look to drive mainframe R&D in a DevOps methodology—not just mainframe development, but also supporting velocity in rolling it out to production, with organizations moving from one or two major releases a year, to now experimenting with both quarterly and monthly releases using DevOps practices and experimentation and techniques.”
    • While tools and processes play a major role in a DevOps transformation, we must not forget to maintain a culture of empathy, emphasizes Shimel: “Have empathy for your fellow workers, empathy for your fellow humans. Don’t think because you’re the dev, that what you’re doing is more important than what the ops guy is doing.”
    • DevOps certifications are the future, according to Pais: “I think we’re seeing more and more DevOps education and certifications. I know, for example, there’s an IEEE standard for DevOps being worked on.”
    • Sweat the small stuff, advises Fell: “It’s never been truer than in this accelerated cycle that we’re seeing with productivity and all this awesome value being created from relatively minor, incremental improvements in process, in tooling, and all the stuff that we do, and the feedback that we’re getting.”
    • I believe 2017 will bring major disruption in the FinServ community: “We will see some, hopefully, interesting disruption in the financial technology area, because the financial institutions have always treated technology as a key differentiator. Now, the problem they have is that their culture, by and large, sucks.”
    • Some wise words from Stroud: “Strategy without execution is wasted time. We have to execute. We have to be prepared to fail. We have to be prepared to come and share our experiences.”
    • Measure, measure, measure is Forsgren’s DevOps focus in 2017: “What’s going to be my goal is having all of us think about measuring in smart ways, so that we can actually do these experiments that are small, that allow us to fail, because big massive failures are scary, but those are the ones that are easy to measure with crap measurements. Because when you fail big, you know you failed big.”
    • In 2017, we will see a breakdown of DevOps tools’ silos, per Shimel: “It’s really ironic that in something like DevOps, where the idea was to break down silos between dev and ops, dev and QA, and QA and security, but what we’ve done is we’ve built new silos of DevOps tools.”
    • Pais on the trends he sees in early adopters of DevOps: “For the majority of organizations that have already been doing DevOps for a while, they’re now focusing on what’s the best way to organize teams. Moving, often, from having just specific people who know about continuous delivery, DevOps and so on, to actually getting platform teams that embed all the services that they want the development teams to use.”
    • Oddly enough, development teams are still more likely to adopt DevOps than operations teams, explains Stroud: “One of the data stats we pulled has to do with DevOps adoption in development versus operations. Isn’t that ironic? Because the name DevOps is dev and ops. We still see significantly more DevOps adoption in development than operations, but the good news is the gap is closing, based on the Forrester data.”
    • Containers will continue to be a major player in 2017, says Riley: “Where I believe there will continue to be growth is container-native tooling, container-native security and container-native release automation.”
    • The reality is, there are still a lot of organizations not doing DevOps, remarks Fell: “We are living in this bubble, happy bubble, of everybody gets DevOps and we’re all Agile. But we talk with folks that we talk to who are just like, ‘Yeah, we do nightly builds, and we’re really looking forward to doing continuous integration.’ Your jaw drops, like, ‘Wow. Yeah, that’s a good idea. You should do that.’”
    • And, finally, I share some sage wisdom to keep in the back of our minds: “If what you’re doing on any given day isn’t moving that ball forward, what is the point? I think we need to focus a little more on that.”

    Bonus 17th quote for 2017, from Shimel: “I think the story of 2016 is DevOps has gone mainstream. We’re seeing pockets of DevOps come together as bubbles, but we still have the majorities in front of us, going forward.”

    For more reflections and predictions, watch the full episode:

     

    About the Author/Anders Wallgren

    leadership-anders-wallgrenAnders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings with him more than 15 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products.  Anders holds a B.SC from MIT.  Connect with Anders on LinkedIn or Twitter.