devopsy.kinsta.cloud

Category: DevOps Culture

  • The Sociotechnical Path to High-Performing Teams with Charity Majors

    The Sociotechnical Path to High-Performing Teams with Charity Majors

    Every DevOps team wants to be successful, but how can you measure this success? What exactly defines a DevOps high-performing team? How can you help your team function at an elite level?

    In this interview, Charity Majors, co-founder and CTO of Honeycomb, explains what it takes to be an elite performer, how DevOps teams can become more productive and how to effectively measure your team’s performance.

    Charity is one of the keynote speakers at this year’s DevOps Experience. During her session, she will walk you through the social and technical strategies that great teams all around the world are using to be happier and more productive.

    For more insights and tips on how to be an elite performer, attend Charity’s keynote session at DevOps Experience 2020 on Oct. 22. To check out the full agenda or to register for free, visit the DevOps Experience website.

  • Bootstrapping DevOps for the Internet Computer

    Bootstrapping DevOps for the Internet Computer

    All startups face unique sets of challenges and issues at each stage of their existence. The DFINITY Foundation, a Swiss-based not-for-profit with the remit to extend the functionality of the internet, is no exception. Like any new organization, we have had to evolve and adapt our DevOps and other practices in response to different obstacles.

    After learning to clearly communicate our vision for an open development platform where software runs directly on the internet, we created a road map to translate this vision into a decentralized architecture with distinct features that could be built and shipped on a periodic cadence. Consisting of five milestones, the road map culminates in a public launch in Q4 of 2020—and we haven’t missed a single deadline despite the disruptions of a global pandemic.

    Incorporating a focus on operational responsibility on top of our focus to ship features without losing speed was a major challenge this year ahead of the release of our developer network, called Tungsten. Sustainably bootstrapping operational responsibility for this release, as well as future releases, was imperative.

    We’ve all heard horror stories about operational teams that run through a checklist in a perfunctory fashion without identifying the root cause of a problem. Even worse, they are quick to give up and are resistant to launching changes, increasing the complexity of their workload.

    Pushing Forward With DevOps

    We were determined that this wasn’t going to happen to DevOps at DFINITY, so we embedded these core cultural touchstones into the organization.

    1: Create SLOs and SLIs for cross-functional clarity

    At the end of 2019, well before there was a service to operate, we started thinking about service level objectives (SLOs) and service level indicators (SLIs). These are critical for providing a common, quantifiable vernacular for R&D and Operations teams to measure how a service should be performing.

    An SLI is a clearly defined indicator for one aspect of a service’s performance, ideally focusing on user-visible service behaviors. The SLO sets the target for the indicator, as well as a window of time over which it is measured.

    To communicate the SLIs and SLOs, training materials were presented across the organization, including speaking with various engineering teams, discussing best practices at management meetings and giving an overview at an organizationwide meeting. In addition, the leadership of R&D teams signed off on the approach.

    To provide clear operational expectations as well as a forcing function, we established an early version of the SLOs as a high-priority OKR.

    As an additional consideration, it is crucial that your SLOs reflect aspects of your service that are visible to the user. As Charity Majors, CTO of Honeycomb.io, noted, “Nines don’t matter if your users aren’t happy.” SLOs are not a one-and-done deal; they need to be updated as the service evolves and as your ability to capture the UX improves.

    Having SLOs in place gave staffers with operational responsibility clear expectations to fulfill. If the service is performing within the SLOs (and if the SLOs are representative of user happiness), then things are running smoothly.

    #2: Engineers developing the software should also help run the software in production

    To bootstrap the team with operational and support capabilities, we needed to ensure that we didn’t create a siloed team lacking engineering skills. Operations in this context is a software engineering problem, which meant we needed to involve developers.

    The same engineers developing the software should have skin in the game in terms of how the software is running in production. If there are problems, these engineers are in the best position to diagnose them and propose and implement the necessary fixes. Getting organizational buy-in for this took some time.

    We emphasized the need for senior engineers to be able to operate the software being built. We didn’t want to fall into the trap of throwing a handful of junior engineers into the deep end without proper supervision or training, so we also established an expectation that all engineers should be able to operate the software irrespective of seniority.

    We built two teams of between five and 10 developers in each of our office locations in Palo Alto, California; San Francisco; and Zurich, which were initially staffed with volunteers across the organization. Each week, one team member at each site managed primary operational responsibility for the service instead of their regular project work, and they knew that the entire staff would help if there were any problems. We plan to rotate new people into these ad hoc teams every six to nine months.

    #3: Create optimally sized, communicative teams

    Operational team size is also important. If the team is too small, people are on-call too frequently. If the team is too large, they will be on-call so infrequently that they will either forget how to operate the production stack or their knowledge will become outdated.

    We share status updates through a daily log and informal shared communication channels such as Slack. There is also a weekly meeting to relay responsibility from one person to another.

    This has helped us identify capability gaps. With team members based across the world, we’ve come to acknowledge that if a problem requires a team’s expertise outside of its working hours, then rolling back first and investigating later is absolutely fine.

    The DevOps team decided early on that we weren’t going to start with 24/7 support, instead providing support during business hours in Europe and the U.S., where the majority of our early-access customers are located.

    We’ve been transparent to the wider organization throughout this process, calling out what is and what is not working well, and how we’re working to improve our processes.

    Conclusion

    We were fortunate that unprecedented global events like COVID-19 didn’t significantly affect our operations. That said, shaping our processes in-person and being physically present for people when they first go on-call would have been valuable, and we definitely felt the impact of losing that. But we’ve successfully bootstrapped our DevOps teams nevertheless, and we look forward to continuing to evolve as a team.

  • Why It’s Time for Site Reliability Engineering to Shift Left

    By adopting a multilevel approach to site reliability engineering and arming your team with the right tools, you can unleash benefits that impact the entire service-delivery continuum

    In today’s application-driven economy, the infrastructure supporting business-critical applications has never been more important. In response, many companies are recruiting site reliability engineering (SRE) specialists to help them improve reliability, availability, latency and a host of other metrics that impact customer satisfaction. These vital new people resources are focused on keeping sites and services running in peak form.

    There are clear limitations to this operations focus, though. A service is made up of many application components that can impact business-critical services. How do you ensure reliability is baked into each app and each code change if your engineers focus only on backend performance?

    Some trailblazers are beginning to tackle this issue head-on, tasking their SREs with taking on new roles that support key stages of the DevOps life cycle. The goal is to take early, proactive steps to ensure quality and reliability are built in from the beginning.

    A Path Pioneered by Test Teams

    To understand why this “shift left” is so important, consider recent revolutionary changes in the software testing function. Not that long ago, testing was considered a distinct phase in the software life cycle, timed to begin well after the work of application developers was done. Testing Centers of Excellence uncovered defects and passed code back to the development team for rework.

    As developers moved to agile sprints, though, this approach to testing quickly became a bottleneck. By the time Centers of Excellence uncovered issues, developers had moved on to other projects. In response, new continuous testing programs emerged, staffed by a new breed of software development engineers who had honed their testing skills.

    These individuals are now embedded with development teams to ensure applications are built better from the start. Open source test automation tools help them test early and often, without impeding agile delivery schedules.

    It’s important to note that Testing Centers of Excellence haven’t gone away. Instead, they have taken on a broader leadership role and are now responsible for coordinating testing across the enterprise in support of continuous software integration and delivery.

    A 3-Level Model for SRE

    There is much that SRE teams can learn from the experiences of their testing colleagues. To produce optimal results, it is important to integrate reliability experts into your organization’s overarching agile framework. Consider adopting the following three-level model that shifts the function to the left and integrates skilled engineers at key points in the DevOps life cycle:

    1. Application level. Embed SREs with development and testing teams to ensure application components and new releases won’t disrupt reliability. These individuals focus on application-level service objectives, error budgets and integration into the DevOps pipeline.
    2. System level. Assign SREs to focus on the applications in your organization’s release train. These individuals support release and launch coordination, evaluate system architecture readiness and ensure your organization meets systemwide service-level objectives.
    3. Enterprise level. Establish a Site Reliability Engineering Center of Excellence, staffed by engineers who oversee the governance of your enterprise architecture. These individuals establish best practices and select the tools and resources required to support your site reliability function companywide.

    An Expanded Toolset

    To support this broadened role, you will need tools that can support your engineers across the entire DevOps life cycle. You will need to be able to see and track issues engineers uncover and to evaluate system-level readiness and performance against your service-level objectives. You will also need a big-picture view that spans activity across the entire enterprise.

    Fortunately, a new generation of solutions is now available to help, powered by artificial intelligence, machine learning and intelligent automation. These resources can help your team process massive amounts of data from disparate toolsets and turn that data into actional insights. As a result, you’ll have all the lifecycle analytics you need to be effective in your new and broadened role.

    SRE and Shift Left: Broad New Benefits

    By adopting a multilevel approach to sire reliability engineering and arming your team with the right tools, you can unleash benefits that impact the entire service-delivery continuum.

    You can build a continuous cycle of feedback, collaboration and governance that spans design, development and the launch and operation of new services. You can better manage configuration changes, service levels and error budgets. You can get a clearer view of application reliability and production readiness to guide planning initiatives and to help you prioritize investments.  And you can build better-informed business cases to move your organization forward. Shifting left is clearly a win-win move.

  • Best Practices for Managing Remote IT Teams

    Best Practices for Managing Remote IT Teams

    With IT teams around the world adjusting to remote working while still struggling to maintain productivity and workflows, ensuring DevOps and Agile practices are in place has never been more important. And while typical DevOps professionals probably have significantly better remote desktop setups than most of their business peers, it’s how IT leaders manage these teams that will make all the difference. One way to approach this is by implementing database monitoring.

    Many DBAs and developers have been working remotely for months now, but as IT budgets grow tighter, they’ll need to do more with less. Ensuring DBAs have the ability to monitor the database from anywhere will be a core part of a continued successful remote working strategy. There are many reasons for database professionals to embrace remote monitoring, whether it’s migrating to the cloud, adapting to new challenges, keeping an eye on multiple instances in many environments or gaining fine-grained access to monitoring data.

    Success Remote IT Team Management

    Here’s a look at some best practices for remote IT teams.

    Easing cloud adoption woes: Cloud adoption is up significantly this year as development teams turn to it, particularly for greenfield projects. But with all of that data migration, database professionals are struggling with being able to monitor cloud-based servers alongside on-premises servers, and having a distributed team doesn’t make it easier. Adopting remote monitoring tools can simplify monitoring of the cloud—once you’re monitoring a remote database server it doesn’t matter where the server is. It’s impossible to say what might happen next month or even next year, but as companies grapple with these cloud challenges, advanced remote monitoring tools can help monitor disparate, hybrid environments from one screen.

    The need for non-production environments: Non-production environments such as UAT and staging are often used to spot problems before deploying software to customers, but it becomes a little more challenging when you can’t simply walk down to the server room, where they’re often housed, and clear up any issues that arise. With remote working and moves to the cloud, consistent database monitoring can help make it much easier to manage non-production servers so that developers can review the systems, understand any potential problems and fix the issues. And although monitoring non-production environments is a good start, errors can still make it into production environments. Setting up database monitoring by configuring the right set of alerts for any environment ensures that teams are always aware of the most critical errors as they’re occurring, rather than finding out after systems become unresponsive.

    Managing access control: When people usually think of “access control,” most immediately jump to the idea of security. But access control is about much more than just keeping people out—it can also mean letting the right people in. Providing developers with read-only access to monitoring tools lessens the load on production DBAs. While the DBA team is handling infrastructure-level tasks, developers can focus on improving the performance and stability of their applications if they have access to monitoring data. Managing this correctly with your developers and DBA teams ensures they have better insights into overall application performance and how their changes affect it.

    Identifying Agents of Change: There’s real value in identifying one or more persons to be an Agent of Change in your organization, especially when working to improve database engineering and delivery. An Agent of Change is adept in both their role as a developer and as a communicator. It’s usually someone from the data processing team who can move into one of the front-end teams and seamlessly offer help both in designing short-term changes and in helping evolve the architecture of the system. Agents of Change are invaluable when you have established silos between development and operations, particularly when there are limited healthy lines of communication between the groups. They work to bridge that gap and can help make a big difference, even for teams working remotely.

    Bringing it All Together

    Remote awareness is critical to keeping development and production environments healthy, but visibility into all of your databases and systems doesn’t need to disappear when nobody is in the office. And considering there’s no telling when people will be able to get back to a normal office routine, remote monitoring becomes much more important. Regardless of location, by actively monitoring databases remotely, companies can spend more time and attention on innovation and freeing up their team for other activities. Look for web-based tools that can monitor hybrid environments seamlessly and allow your software and database teams to do this so that problems can be spotted and resolved quickly. Managing non-production environments and access control are good ideas, as are finding and appointing a team leader who can serve as the liaison between your remote teams. After all, with clearer paths of communication present, your teams can be more productive, too.

  • Should Conway’s Law Be Applied to DevSecOps?

    Should Conway’s Law Be Applied to DevSecOps?

    Strictly adhering to Conway’s Law could lead to less innovation and the inability to keep up in a fast-changing market

    When it comes to determining how an organization should be structured, the 1967 Conway’s Law provides a plausible direction that many software companies could follow. However, in today’s ever-changing cloud environment, it is arguable whether it can be used in DevSecOps companies, a quickly growing organization structure. While Conway’s Law is helpful to consider, it should only be used as a guideline and not strictly followed because it can lead to less innovation and the inability to keep up with the fast-changing market.

    What is Conway’s Law?

    Conway’s Law is a term that originated from engineer Melvin Conway’s 1967 thesis paper to Harvard Business Review. In his submission, he wrote that “any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication methods.” Based on his observations in the engineering world, he believed that the success of a software is based on the organization’s company structure and communication style. As a result of this paper, software companies began to emphasize collaboration and teamwork and implemented it into the company’s work culture.

    How Can Conway’s Law Apply to the DevSecOps Field?

    Conway’s Law has many valid points. The law emphasizes the importance of a company’s structure and the necessary balance of business and design to ensure a viable product, as the quality of a product “comes from within.” However, there is no right way to organize a company, and it should be structured in a way that makes the most sense for an evolving, cloud-based product.

    In the DevSecOps field, many solutions are run by enterprises that are cloud-based. This means that all the data and networks are stored in remote servers, making it easier for companies to constantly develop new technology and improve existing products. This new norm is redefining the way companies are structured today, and traditional standards cannot be followed. If a company strictly follows Conway’s Law, it will be difficult for them to innovate.

    Here are a couple of takeaways from Conway’s Law that can benefit DevSecOps companies:

    Small Teams With Equal Representation

    Conway’s Law explains that the bigger the team, the higher likelihood of miscommunication and tension, causing unproductivity. Many tech companies, such as Microsoft and Amazon, structure their employees in small teams (around 10-15 members) to oversee and specialize in a specific aspect in the company’s product, but aim to achieve the same business goal. This type of structure allows more leeway to experiment different ideas and quicker response time to fast-changing needs.

    Collaboration is Key

    Some argue that following Conway’s Law may decrease the company’s overall cooperation and lead to small team allegiance. While there is a fine line between small work groups and department cliques, collaboration needs to be a core concept embedded in the company’s organization.

    If the organization’s culture is based on companywide collaboration, it will solve these problems, as collaborative processes and platforms prevent cliques from forming and allow teams to be independent, creative and agile. For example, for security teams to successfully collaborate with DevOps teams, they need to intentionally create solutions that can be embedded with existing DevOps pipelines.

    Conclusion

    While Conway’s Law is an important social contribution to organization principles, it should only be used as a rough guideline because following it too closely can stymie innovation in a fast-changing cloud environment. Conway’s Law highlights the importance of company structure and implies that a successful organization is structured with small teams focusing on one sector of the company, and with consistent collaboration established throughout the company to systematize unification and togetherness.

    As organizations compete for the greatest slice of pie, it is critical for leaders to look inward and ensure internal structures and processes are setting their products up for success.

  • Recruiting Pro Tip: Treat External Recruiters As If They Work for You

    Recruiting Pro Tip: Treat External Recruiters As If They Work for You

    The best recruiters are salespeople. Just because you have hired a salesperson does not mean they are going to know how to sell what you have to put out on the market. So many people believe that once you have hired an external recruiter the job is done—they will go out and find the right people for you.

    Sure, most recruiters spend half an hour talking with someone in HR about what they should be telling candidates about the company and the position. They might even have a half-hour chat with a hiring manager. This is not enough—not even close to achieve what you hired these folks to do.

    The technologists you want to hire have other offers or are happy at the jobs they have. To hire them, you have to sell—you have show them how your mission and your work environment are right for them. As the hiring manager, you may be great at this, you may be able to enthusiastically present this to anyone. But just because you can doesn’t mean your recruiters can!

    Here is what you need to remember: Salespeople need to be sold. It’s easy to sell a product you believe in. That belief can’t just be bought—the salespeople you just hired to find and attract that hard to get talent need to be sold, too.

    If you want them to believe in the product, then you need to show them what the product is all about—and, remember: A big part of the product is YOU, the hiring manager. You need to make sure your recruiters care about you, the position and the company.

    Here are four ways to sell the salespeople and get them working harder and more effectively for you:

    1. Bring them in for an office tour. Introduce them to key players and let them get a feel for the culture. If you don’t have an office, then set up a videoconference meeting and let them meet the team and ask questions. Make this an enthusiastic, fun meeting. It’s easier to sell something if it’s tangible, if you have seen it.
    2. Spend at least an hour going over the mission, the company and what you are looking for. Have them give their pitch back to you to make sure they know the ins and outs.
    3. Give them your cellphone number. Show them you care and they are at the top of your list, and be there to unblock anything that gets in the way or their success.
    4. Continue to build the relationship over time: Have regular meetings. Bring them to a company happy hour. Don’t assume the job is done because you started off right. Successful external recruiting is a relationship, not a transaction.

    If you help them understand and care about the company like an employee and show them you care just like you would an employee, external recruiters will work harder and smarter for you than anyone else.

    Looking for the right talent? Please visit recruitops.com and learn how our talented recruiters can help you find the right fit for your team.

  • Linux Foundation Adds Entry-Level Certification

    Linux Foundation Adds Entry-Level Certification

    The Linux Foundation has announced the development of a new entry-level certification exam to complement their existing Linux Foundation Certified Sysadmin (LFCS) and Linux Foundation Certified Engineer (LFCE) exams. This new certification, the Linux Foundation Certified IT Associate (LFCA), targets people just moving into systems administration.

    The certification will focus on the test taker’s knowledge of the fundamentals of system administration. We are in a complex world with a lot of systems administration options, and the LFCA intends to touch a little bit on each of the areas a new admin might run into. The test is still in development, but the areas that The Linux Foundation intends to focus on include:

    • Linux Fundamentals
    • System Administration Fundamentals
    • Cloud Computing Fundamentals
    • Security Fundamentals
    • DevOps Fundamentals
    • Supporting Applications and Developers

    The categories will be complementary, with Linux Fundamentals including user and password management, for example, but security going more in-depth on that particular topic.

    In keeping with being accessible for people with entry-level knowledge of the above areas, this certification will be a single exam. That means a user need not wade through dozens of courses and exams to get started in their chosen area of specialty, and the other two certifications are available when the user is ready to move beyond the basics.

    Currently, The Linux Foundation has the following learning path for these exams:

        Introduction to Linux (LFS101) Training
        Essentials of Linux System Administration (LFS201) Training
        Linux Foundation Certified System Administrator (LFCS) Certification
        Linux Networking and Administration (LFS211) Training
        Linux Foundation Certified Engineer (LFCE) Certification
        Linux Security Fundamentals (LFS216) Training

    The LFCA is designed to fit between “Introduction to Linux” and “Essentials of Linux System Administration” to make a pairing of courses and certification exams to carry a system administrator through their career.

    In the midst of business closings and social distancing both increasing the amount of working from home that knowledge workers are involved in, on-site proctored examinations have suffered. This is unfortunate, as there is a spike in the number of people looking to improve their position through certification.

    Since its first exam, the Linux Foundation has offered online exams through a partnership with a proctoring organization. The approach is simple: Webcam, screen-sharing and chat are available to the proctor to monitor the test taker’s activities. Further, the entire session is recorded, so any misunderstandings can be reviewed. The fact that remote proctoring is standard for The Linux Foundation and the organization has been doing it for years hopefully means that proctoring is unobtrusive, and the test-taker can generally just take their test with minimum technical issues.

    The rush to remote proctored testing has created problems for some organizations; having had years to work it out should mean this is not a problem for The Linux Foundation in general and LFCA specifically.

    So if you have friends/coworkers interested in moving in this direction but are unable or unwilling to work through four years of university to get started, point them toward the LFCA. There are a lot of options, but the LFCA has less overhead than many of the other options and will help them settle on whether they are ready to pursue their dream.

    We’ll circle back and do a more in-depth look when the certification is released because there are two parts to a certification—who it benefits and what prospective employers think. We’ll be interested in seeing how this fits with employers’ needs, and to delve into sample questions when they are available.

  • New ASG Report Looks at COVID-19’s Impact on Software Development

    New ASG Report Looks at COVID-19’s Impact on Software Development

    We are all trying to adapt to a new world created by COVID-19. As the coronavirus continues to spread, the economy and businesses everywhere have been severely impacted, and no one really knows what the so-called “new normal” will be. For now, most organizations have gone remote, not knowing when—or even if—employees will be able to return to their offices.

    While some organizations have been open to the idea of working remotely, many have also struggled to shift to a remote workforce seemingly overnight. For software developers, however, remote work is nothing new. Many developers have successfully worked remotely before the COVID-19 pandemic even started.

    “The Future of Remote Work and Software Development“ research published today by Accelerated Strategies Group dives into the long-term impact of a decentralized workforce on software development and delivery. ASG interviewed 347 industry leaders from around the world to gather and refine data on the impact of COVID-19 on software teams and their organizations’ ability to create software, and the importance of remote work tools and applications during the pandemic.

    The ASG report, commissioned by CloudBees, revealed some interesting trends. The survey found 63% of respondents said digital transformation objectives have significantly or somewhat increased in priority. Business automation (61.6%) and the need for investment in creating contactless services (60.1%) have increased somewhat or significantly.

    More than half of the respondents said the COVID-19 conditions have increased their focus on DevOps initiatives (51.75%) and increased their progress on cloud migration (52.25%). Also worth noting is the growth in companies’ DevOps and Agile adoption, with 46.24% of respondents stating they are using cross-functional teams, 55.64% practicing daily stand-up meetings and 43.23% automating tasks.

    The majority of respondents (59.49%) to the ASG report saw an increase in productivity on software teams since the pandemic started. Forty-two percent of respondents said it has become somewhat easier to complete their work tasks in a timely manner.

    However, feedback concerning respondents’ ability to manage unproductive distractions was mixed: 39.7% said managing these distractions was somewhat or much easier, 36.36% said it was somewhat or much more difficult and 23.48% said they had no change in their ability to manage these distractions.

    When asked to provide insight into the potential negative impact of their remote workforce on productivity, more than one-third (38.6%) of respondents said there was no change, 27.58% of respondents indicated that teams were slowed down significantly or somewhat and 33.83% said things moved along significantly or somewhat faster.

    The majority of remote workers (64.4%) expect to remain working remotely, either permanently or at least three or more days per week, once COVID-19 restrictions are lifted. Only 12.7% said they anticipate returning to an office location full-time.

    For the most part, the transition to working from home has benefited software teams. COVID-19 has not only impacted the global economy, but also business priorities and has accelerated business and software strategies. Though the future is uncertain, and no one has a clear picture of what the “new normal” looks like, there is a huge possibility many software and DevOps teams won’t return to the office—at least not full-time.

  • Upcoming Event: DevOps Experience 2020

    Upcoming Event: DevOps Experience 2020

    The third annual DevOps Experience is just around the corner, and this year’s event will be out of this world.

    DevOps Experience 2020: The Builders Shall Inherit the Earth offers attendees the opportunity to gain inspiration, sharpen their skills and network with some of the best DevOps leaders and practitioners. The conference will take place in a virtual environment with a lobby, an auditorium and an exhibit hall on Oct. 22, at 10 a.m. EDT.

    This year’s event will focus on digital transformation and DevOps adoption from a “bottom up” model. It is the practitioners who are often the unsung heroes of successful DevOps implementations, choosing what tools to adopt, bringing teams together and contributing to the community.

    DevOps Experience 2020 will feature a stellar lineup of DevOps luminaries, including:

    • Kohsuke Kawaguchi, co-CEO and founder at Launchable (keynote speaker)
    • Akash Tayal, U.S. cloud strategy and operating model leader at Deloitte Consulting (keynote speaker)
    • Bob Vuong, principal at Deloitte Consulting (keynote speaker)
    • Loris Degioanni, CTO and founder at Sysdig (keynote speaker)
    • Tracy Ragan, co-founder and CEO at DeployHub
    • Orit Golowinski, senior product manager of progressive delivery at GitLab
    • Jayne Groll, CEO at DevOps Institute
    • Rob Hirschfeld, founder and CEO at RackN
    • Bryan Feuling, solutions architect at Harness
    • Bob Reselman, analyst at ASG
    • Maya Ber Lerner, CTO at Quali

    The breakout sessions and panel discussions will fall under four main tracks:

    • Humans in the DevOps World: DevOps is about more than just technology. Understand the important role that humans play in your organization’s DevOps journey.
    • CI/CD: Learn how to keep the factory running by setting up your CI/CD pipeline to automate software delivery.
    • GitOps: Find out the key principles and benefits of GitOps and best practices for continuous deployment and progressive security.
    • Observability: Insights demand much more than collecting and analyzing. Observability can help developers uncover issues that impede performance and derail customer experience.
    • SRE: What is SRE? Who are SREs? How do we get it? Where do we start? This track will explore the best practices and patterns associated with SRE.
    • Tools: Discover and learn the latest DevOps tools and services that IT teams are using to accelerate delivery, improve quality and get faster feedback.

    Take advantage of the valuable information provided in the educational sessions at DevOps Experience 2020 and learn how to adopt the right tools and practices to harness the full potential of DevOps. To infinity and beyond!

    To check out the full agenda or to register for free, visit the DevOps Experience website.

  • Operationalizing Cloud Native with Kubernetes Virtual Summit Speaker Spotlight: Tracy Ragan, Cornelia Davis, Ashley Ward and Rob Hirschfeld

    Operationalizing Cloud Native with Kubernetes Virtual Summit Speaker Spotlight: Tracy Ragan, Cornelia Davis, Ashley Ward and Rob Hirschfeld

    The Operationalizing Cloud Native with Kubernetes Virtual Summit will bring together Kubernetes and cloud-native community members for a unique learning experience focused on the tools and best practices you need in order to successfully secure and manage Kubernetes. Presented in a virtual reality environment, the event will take place on Oct. 1, at 10 a.m. EDT.

    Operationalizing Cloud Native with Kubernetes - speakers - Tracy Ragan - Cornelia Davis - Ashley Ward - Rob Hirschfeld

    At the The Operationalizing Cloud Native with Kubernetes Virtual Summit, Kubernetes technologists, DevOps and cloud-native experts will be educating the audience on cloud-native technologies and digital transformation with Kubernetes. Tracy Ragan of DeployHub, Cornelia Davis of Weaveworks, Ashley Ward of Palo Alto Networks and Rob Hirschfeld of RackN are a few of the outstanding speakers that will be sharing their knowledge and insights with the community at the Operationalizing Cloud Native with Kubernetes Virtual Summit.

    Recognized as a Women In Technology (WIT) Honoree for her work in DevOps, DeployHub Co-Founder and CEO Tracy Ragan is an expert in configuration management and pipeline life cycle practices with a hyper focus on microservices and cloud-native architectures. Tracy is a well-known DevOps evangelist and DevOps Institute Ambassador. She serves as board member of the CDF, where she is the elected General Member Representative, and she is also the creator of the Continuous Delivery Foundation Interactive Landscape. Prior to DeployHub, Tracy was co-founder and COO at OpenMake Software.

    During her talk, “Achieving Business Agility with Microservices,” Tracy will explain what application teams must do in order to achieve business agility. She will explore how microservices are truly the last mile of Agile practices and an essential component for the creation of a modern software architecture.

    One of our most distinguished speakers is Cornelia Davis, CTO at Weaveworks and author of “Cloud Native Patterns: Designing Change-Tolerant Software.” Cornelia is an industry veteran with almost 30 years of experience in image processing, scientific visualization, distributed systems, web app architectures and cloud-native platforms. She is responsible for Weaveworks’s technology strategy, inclusive of open source projects, commercial products and services offerings. Cornelia is driven by the desire to help enterprises transform their business through the leverage of cloud computing platforms.

    In her session, “The Business Benefits of GitOps,” Cornelia will cover key GitOps principles and practices and tie them to measurable IT outcomes, such as change failure rates and mean time to recovery. These IT metrics are intrinsically tied to digital transformation initiatives. She will also review research that has shown a correlation between these measures and where companies fall on the spectrum from high to low performers in terms of business outcomes.

    Ashley Ward, CTO for Prisma Cloud at Palo Alto Networks, is another of our brilliant speakers presenting at the virtual event. Ashley aids customers in the secure deployment and scaling of cloud native environments. He has over 15 years of experience in the operations and infrastructure architect space.

    During the session “Kubernetes Security – Defense in Depth,” Ashley covers the areas that need attention when securing the Kubernetes stack.

    “Kubernetes can seem complicated and even frightening when trying to secure it,” said Ashley. “I hope that people takeaway an understanding of why and how they can secure their Kubernetes clusters and resources.”

    He will also introduce the audience to the concept of a cloud-native application protection platform.

    Another DevOps and cloud-native expert joining as a speaker at this year’s virtual event is Rob Hirschfeld, founder and CEO at RackN. Rob has been creating software to automate infrastructure for over 20 years. He has been involved in numerous open source efforts including LF Edge (Board), CNCF (SIG Chair) and OpenStack (Board).

    Rob will show how EdgeLab.digital uses Digital Rebar to provide PXE boot, immutable O/S and API-driven automation control of RPis to build Kubernetes (k3s) and OpenFaaS.

    “This session is a ground-up demo of the entire process and background about why it’s important to have a proven reference architecture,” said Rob. “This is designed as a learning environment that can also scale to real edge and enterprise use.”

    Attendees will learn how this easy-to-duplicate-at-home demo creates a true desktop data center using the community edition of Digital Rebar to enable netboot for RPis and install CNCF sandbox project K3s. The same code learned in this demo session can run any COTS infrastructure and is currently running multinational banks in the EdgeLab.

    You can hear from these speakers and more than 30 other industry leaders at Operationalizing Cloud Native with Kubernetes Virtual Summit. To check out the agenda, the full lineup of speakers and to register (for free), visit the Operationalizing Cloud Native with Kubernetes Virtual Summit website.