devopsy.kinsta.cloud

Tag: SKILup Day

  • 12 Ways to Bake Security Into a DevOps Transformation

    12 Ways to Bake Security Into a DevOps Transformation

    Security has become an integral part of any DevOps transformation. According to the Upskilling 2021: Enterprise DevOps Skills Report, DevSecOps achieved a must-have percentage vote of 56% in the automation tool category. Security not only protects the business and its customers, but it enables companies to enforce internal and external policies. 

    While considering how to bake security practices into a DevOps transformation, I asked several speakers and sponsors for the upcoming SKILup Day as well as several DevOps Institute Ambassadors to weigh in with their thoughts. Here’s what they shared: 

    Sponsor, Kendall Miller, president, Fairwinds

    “A DevOps transformation is about building great tooling so that developers can own their services all the way into production. The addition of security is the same thing; it’s building great tooling so that developers can also own the security posture of their services all the way through to production. This transformation is about enabling developers to understand security concerns at the application level. Service ownership is still service ownership—ownership of the operational and security pieces.”

    Sponsor, Guy Eisenkot, VP of product, Bridgecrew by Prisma Cloud

    “The key to a strong DevOps transformation that keeps security at the forefront is selecting and leveraging tools and processes that lend themselves to automation for your specific stack. For AppSec and cloud security alike, automation is the name of the game. But automation is only as strong as the processes it can fit into and the feedback it provides. 

    Security feedback will be futile if it’s not actionable and not given at the right time or in the right place. When undergoing a DevOps transformation, it’s important to keep that in mind when implementing tools and processes. It’s also important that the feedback surfaced is actionable and useful so that engineers can actually learn from and implement secure coding practices.”

    Sponsor, Rob Cuddy, global application security evangelist, HCL Software DevOps

    “The best place to start is with design and make sure that your epics, stories, hill statements and use cases all have security elements as part of them.  A great idea here is making ‘misuse cases’ or adversarial use cases and then testing against them.  For example–a misuse case might read, ‘As a bad actor, I can use a malformed URL to gain unauthorized access to a web server,’ or ‘As a bad actor, I can impersonate an endpoint in a transaction and both send and receive data while impersonating without the other parties’ knowledge.’

    It is also vital to have great SCA–software composition analysis. You cannot secure what you don’t know you have, and this includes open source and third-party tools. In a lot of cases, simple code sharing can inadvertently cause dozens of new dependencies to be added in, and those dependencies can add new vulnerabilities.

    It is important to have security aspects tested and validated throughout a pipeline, but particularly at any points in the pipeline where other checks are also being made. A great place to combine this is in QA and wherever functional testing is being done.  Leveraging interactive security testing (IAST) in an environment like this allows for monitoring to occur and for vulnerabilities to be found while application capabilities are being tested.  This greatly reduces the appearance of false positives and provides real-time information about the security posture of applications.”

    Sponsor, Yasser Fuentes, cloud workload security technical product manager, Bitdefender

    “In short, security should not just be considered at the CI, dev and test phases or limited to vulnerability assessments, since most of the vulnerability scanners and assessment tools DevOps teams use today to go over their CI/CD pipelines rely on either known vulnerabilities, signatures and known attack techniques. As a recommendation, we should emphasize the importance of incorporating tools or solutions which allow developers to identify potential threats and security flaws at the runtime level and which provide visibility beyond the typical anti-malware alerts to suspicious and potentially anomalous process-related behavior.” 

    Sponsor, Joni Klippert, co-founder and CEO, StackHawk 

    “To bake security practices into a DevOps transformation, teams need to reimagine how security plays in the software development life cycle. For many organizations today, security testing blocks applications from being shipped into production or tries to play catch-up once software is released. But it doesn’t have to be that way. 

    Security can (and should) live throughout the pre-production phases of software development. Modern security tools automate security testing in the IDE or CI/CD pipeline, alerting engineers if they have introduced a vulnerability or a vulnerable dependency.

    Making security just another type of test that is run in pre-production means teams can find vulnerabilities faster, remediate on the fly and, most importantly, get back to feature development. Baking security into the DevOps pipeline is what all teams should aim for!”

    Stephen Walters, sales engineer, Everbridge

    “The exact same way that any other practice has become baked in as part of DevOps—by following the CALMS principles. Implementing a culture of inclusion and acceptance; integrating automation into security testing, monitoring, builds and repository management; ensuring the flow and feedback of security into delivery and support is performed in a lean way, adding value and not waste; measuring security as a business value through the use of scorecards and as a success criterion for the business; sharing concerns, lessons learned, new practices and techniques.”

    Dheeraj Nayal, global community ambassador & region head – Asia Pacific, Middle East and Africa region, DevOps Institute

    “A proactive approach is the best method for building in the essentials of DevSecOps. This can be achieved by following some best practices.

    1. Teams should be aligned and in-sync
      The first and foremost step in implementing a DevSecOps culture is to train your teams that security is a shared duty of teams from all three systems. Once development and operations units take on the distributed responsibility of guarding code and infrastructure, DevSecOps becomes a routine part of the development cycle.  
    2. Keep the code simple
      Complicated code can carry more security vulnerabilities. And simple code is more comfortable to collaborate on. All your developers should be capable of looking at each other’s code and know what is happening.
    3. Testing
       SAST (static application security testing) is a key security tool that checks security issues regularly and earlier in the development process which enables it to address the issues more efficiently.
    4. Deployment
      To expedite product delivery and add flexibility to the development process, automated deployments are great. One can review properties across the IT infrastructure and implement secure configurations in a system employing an infrastructure-as-code tool.   
    5. Operations
      Operations teams must collude with security practitioners. They are accountable for controlling infrastructure and network arrangements. Operations and security teams unite to set up manual and automated security tests to warrant compliance with network configurations.”

    Peter Maddison, founder, Xodiac Inc.

    “Two main places: within platform engineering to enable the collection of the data you will need for creating visibility, feedback and learning. Next, it is important to engage the security and compliance teams to determine where you can integrate into existing standards or where modifications might be required.”

    Mark Peters, technical lead, Novetta

    “Security practices can be baked in through the standard DevOps approach, through people, processes or technology. Baking in practices with people means getting folks on the ground with your team who can advocate for security. This can happen through having your security experts spend time with the teams, assigning security to be responsible for teams, or even by selecting champions within those teams who regularly interact with security. The first agile principle, after all, is ‘people over process.’

    That component does not allow one to ignore the process.  Building the correct process implies using test-driven development at the start. Every delivery should be tested and those tests should include security testing. Some common security testing, such as code quality, now occurs so frequently many no longer consider it a separate security practice; merely a routine part of development.

    Finally, one can bake processes in through technology. Many security tools allow shortcutting through metrics, logs and traces relayed on the dashboard. These tools evaluate and highlight where security challenges occur. Tools allow integration through infrastructure and maintaining awareness of what functions occur and when. One of the old military strategies uses the OODA loop by John Boyd: observe, orient, decide and act. Just as with intelligence systems in the military, better awareness of your system through dashboards allows one to observe functions within the network, orient against possible problems, decide on a solution and act before those problems ever reach critical mass.”

    Supratip Banerjee, solutions architect, Principal Global Services

    “There are a few ways we can bake security into DevOps:

    1. Security as a mindset: There is a thought process that security in the development process might slow it down. But we must educate teams that the time and effort it takes to fix a security flaw early in the process is lower than doing it later.
    2. Platforms/environment: Proper configuration/sanitation of deployment platforms/environments is extremely important. Infrastructure-as-code (IaC), configuration-as-code, compliance/policy-as-code, secrets management, etc. can help with the process. Increased use of containers and cloud platforms can keep it clean as underlying infrastructures are managed by the provider.
    3. Automation: Include a lot of automation testing in the CI/CD pipeline. Also add static code analysis, third-party testing, AVA testing, code vulnerability checking, container security, intrusion detection and prevention, APM, etc. as automated processes. Make change management, auditing, etc. regular and as self-operating as possible.
    4. Secure architecture: Make sure security is enabled at the time of the software architecture/design phase. An architecture risk assessment must be a mandatory process to catch any design vulnerabilities before development starts.
    5. Culture of curiosity: Create a culture that emphasizes the importance of security, so everyone is interested and ready to discover if anything goes wrong with security in their system.”

    Amiran Alavidze, director of security and risk management, Tasktop

    “DevSecOps is about culture and enablement and making software delivery teams autonomous and efficient. Training and awareness is a core component of that enablement. This also includes focusing on tools that are developer-friendly and automated so that critical security controls are an inseparable part of how things are done, and allows development teams to take on all the responsibility, without a cognitive overhead of expert-level understanding of the security domain.”

    Sharath Dodda, IT development manager, TD

    “By engaging security early in DevOps with as much automation as possible. All the scans that are possible and relevant should be done well in advance in the pipeline, so that the artifact is cleared of all the findings.”

    Learn more about DevSecOps and similar topics, by registering for an upcoming SKILup Day. Or, start your upskilling journey by learning more about the benefits of DevOps Institute membership. 

  • 7 (More) Security Considerations for CI/CD

    7 (More) Security Considerations for CI/CD

    CI/CD orchestration has become increasingly popular in DevOps practices. It facilitates faster deployment of software and product delivery. Through the use of automation when building, testing and deploying applications, CI/CD bridges the gap between development, operation activities and teams. 

    However, there are many security considerations to keep in mind with frequent deployment. From quality automation to code history analysis, security must be baked into your CI/CD pipeline to ensure your product and processes remain safe from hackers.

    To gain insights on the top security considerations for CI/CD, I asked the speakers and sponsors for the upcoming SKILup Day as well as several DevOps Institute Ambassadors for their thoughts. In this two-part series, I will be sharing their insights. Did you miss part one? You can read it here. Here’s what they had to say in part two of this series:

    Speaker, Ravi Lachhman, Evangelist, Harness

    “CI/CD platforms are core to an organization’s engineering efficiency and typically have elevated privileges to sensitive environments such as production. Since CI/CD platforms typically will be deploying, this makes sense. Delving into the SolarWinds hack with binary artifact signing, etc., can separate security concerns into two parts. One concern would be the security around the actual CI/CD platform and one around the DevSecOps goals inside a CI/CD pipeline. With so many items shifting left, having proper role-based access control (RBAC) is crucial. With the separation of duties for regulated environments and the need for engineers to be efficient, controls that ensure only certain entities can deploy and certain entities can view pipelines is important. Around the DevSecOps movement, container/OSS scanning is still top of mind for many firms.”

    Sponsor, Basis Technologies, Eran Kriegshauser, Basis Technologies’ SAP DevOps Architect

    “The question you should be asking is ‘How do I maintain quality with the frequent deployment tempo demanded by business today?’ We need automation of quality and guaranteed rigor. For example, take promoting security configuration changes in systems, applications and products (SAP). Today, this is done by SAP transports where the change is created in an SAP development system, then imported into QA and, ultimately, into production. How do you ensure that a developer can’t give themselves extra security access through a role modification? Automated analysis and approval workflows must support segregation of duties requirements. Users can’t approve changes they create–the appropriate CI/CD process will not allow it.

    Another area is automatic peer review notification on changes to sensitive enterprise resource planning (ERP) objects. Once identified, the promotion of those object changes are halted until approved by a team lead or change and release manager.”

    Savinder Puri, DevOps Evangelist, Zensar Technologies

    “Infuse as many aspects of security as possible into your CI pipeline. CD is already too late for security—you’ve already deployed the application into an environment.

    Start from the basic static code analysis, security scanners, etc., and then keep maturing. Whatever tools you integrate into CI Server, ensure the corresponding integrated development environment (IDE) plugins are made available to developers. That way, devs can do the first-level validation within their IDE itself, and do it as they code, even before compiling. That’s the practical implementation of the often overused term ‘shift left.’”

    Vishnu Vasudevan, Head of Product Engineering and Development, Opsera

    “Now with cloud migration, emerging technologies and open source technology, companies will have to make sure they have the right tooling to measure and take action based on the security challenges born out of different development activities. 

    The focus will need to be on managing the risk that is tied to the business criticality. Each industry, domain, technology, etc., all have their own independent security goals, and you cannot have one security goal across the enterprise for different technologies and different domains. It is important to evaluate the technology being used and weigh the security requirements accordingly.”

    Stephen Walters, Sales Engineer, Everbridge

    “Inclusion! This is why the term DevSecOps came to be—because, erroneously, security was not included as part of a DevOps transformation, and the same is true for transformation of an SDLC to incorporate security.

    Security has still been treated as a non-functional requirement; an afterthought. If there is one thing we should learn, there is no such thing as a non-functional requirement. Security needs must be considered on an equal footing with all other requirements and built into the design, test, deployment and delivery of any feature.”

    Mark Peters, Technical Lead, Novetta

    “CI/CD pipelines should implement security at every step.  Tests can be automated in tooling to conduct tests of various functions at multiple levels for code accuracy, unit tests through fuzzing and integration or vulnerability testing. Most vulnerability testing in a pipeline is actually patch management, ensuring all commercial and proprietary holes are filled for release software. The first step should be using coding checks to make sure there are not any common problems with the code. While this may seem easy, if you are not managing that basic step, you cannot move ahead to the more complicated areas.”

    Pawel Piwosz, Lead Systems Engineer, EPAM Systems

    “At a high level, I would say that security is still outside the main scope of CI/CD. We should consider a few areas and different angles, here. Security should be not only implemented by CI/CD; CI/CD should be implemented in a secure way. Everything-as-code is a solution here: policy-as-code, security-as-code, drift-as-code, and if we talk about infrastructure, remediation-as-code.”

    If you’d like to learn more about the latest in CI/CD and similar topics, check out the upcoming SKILup Day schedule. Or, learn more about the benefits of becoming a DevOps Institute Member. 

  • 8 Security Considerations for CI/CD

    8 Security Considerations for CI/CD

    In the software development enterprise, CI/CD refers to the combined practices of continuous integration and either continuous delivery or continuous deployment. CI/CD enables organizations to bridge the gap between development, operation activities and teams by the use of automation when building, testing and deploying applications. 

    How do you maintain quality and security with frequent deployments? While CI/CD can improve the efficiency of an organization, there are many security considerations to take into account.

    To gain insights on the top security considerations for CI/CD, I asked the speakers and sponsors for the upcoming SKILup Day as well as several DevOps Institute Ambassadors for their thoughts. Here’s what they had to say in part one of this two-part series:

    Speaker, Grant Fritchey, Product Advocate, Redgate Software

    “There are a lot of security considerations when it comes to CI/CD. As a person focused on data and data management, I’m going to say that the top security consideration is ensuring that you have compliant data for your non-production environments. Just the sheer number of people who will have access to the information means that you have a huge number of possible vectors for a breach if you’re exposing protected information.”

    Speaker, Anders Wallgren, VP of Technology Strategy, CloudBees

    “Secure your software delivery pipelines themselves, not just the software that you deliver with those pipelines. Everyone should have only the level of access they require in order to perform their role.

    Maintain a Software Bill of Materials (SBOM) so you know what you have in production. When a new vulnerability is disclosed, you will have a much easier time deciding whether and how to mitigate it if you don’t have to chase down what you have in production. Your orchestration software should do the lion’s share of the work here.”

    Tracy Ragan, CEO and co-founder, DeployHub

    “CI/CD tools are driven mainly by one-off scripts. There is absolutely nothing secure about one-off scripts. From build through deploy, we need to start thinking of implementing automation and policy-driven tools and dump the one-off scripts.”

    Tiffany Jachja, Technical Evangelist, Harness

    “Supply chain management is a major security consideration for CI/CD. If an entity gains access to a CI/CD resource or component that they shouldn’t, this can lead to vulnerabilities, downtime or even malicious code. For example, in the SolarWinds hack of 2020, attackers legitimized their software malware by injecting it into the SolarWinds build process. This build pipeline produced trusted software artifacts and obtained digital certifications before being released to over 18,000 customers worldwide. After the hack, SolarWinds took action, further restricting access to its build environment and reviewing its build process, but not before it was too late. It’s not only about automating developer and operations workflows but also how we treat and handle CI/CD pipelines.”

    Jamal Walsh, Technical Product Owner, The Very Group

    “You must make sure you implement security tooling within your pipeline; it’s not enough to just use CI/CD to build and deploy applications. Steps in your pipeline should include security testing tools like SAST, DAST, dependency checks, etc.”

    Martin Chan, System Analyst, Global Executive Consultants Ltd. 

    “The most important thing is to define the access control list and rules to control the access in the CI/CD pipeline so that the audit log can easily trace issues. Also, the system should require authentication and define password policies for all users.”

    Bryan Finster, Software Engineer, DoD Platform One

    “Security must be automated as part of the pipeline. Just like any other quality gate, the pipeline must be the single source of truth for security. Any manual process after code is committed increases the effort to deliver. Increased effort increases the size of each change. Larger changes are harder to check for quality and fail more spectacularly. Manual security is just security theater and is easily bypassed or forgotten. That effort is better spent improving the ability of the pipeline to use security as-a-service.”

    Dheeraj Nayal, Global Community Ambassador, DevOps Institute

    “Follow the three security best practices for CI/CD. We usually divide security practices into three parts that you can address with different kinds of solutions. These are:

    1. Secure pipeline configuration
    2. Code and Git history analysis
    3. Security policy enforcement

    All three aspects are equally important.”

    If you’d like to learn more about the latest in CI/CD and similar topics, check out the upcoming SKILup Day schedule. Or, learn more about the benefits of becoming a DevOps Institute Member. 

     

  • DevOps Institute Announces 2020 Global SKILup Festival and First Round of Speakers

    Virtual DevOps festival offers career fair, upskilling opportunities, and a full-day conference, featuring keynote speakers Mirco Hering and Patrick Debois  

    BOCA RATON, Fla. – September 28, 2020 – DevOps Institute (https://devopsinstitute.com/), a global member-based association for advancing the human elements of DevOps, today announced the 2020 Global SKILup Festival, a week-long global event dedicated to DevOps upskilling, a deep-dive into technology trends, and career advancement. The world’s first such unique festival, sponsored by Rancher and AppDynamics, will take place virtually from Dec. 7-11, 2020. Global SKILup Festival runs continuously across global time zones and includes:

    • December 7 – Career Fair
    • December 8-9 – Get SKIL’d Up Learning Days
    • December 10 – 18-hour Global SKILup Day Virtual Conference
    • December 11 -SKILup Recap

    Register for Global SKILup Festival at: http://www.devopsinstitute.com/skilup-festival/

    “DevOps Institute’s Global SKILup Festival is a week focused entirely on advancing the Humans of DevOps – whether by attending the career fair, optimizing learning and certification opportunities or by hearing from top enterprise and industry thought leaders on a wide range of DevOps-related topics,” said Jayne Groll, CEO of DevOps Institute. “As we close out an unprecedented year, we have crafted this week-long event with a variety of activities to celebrate the resiliency of the tech community and help us all move forward with the Skills, Knowledge, Ideas and Learning for the ‘new normal’.”

    The cornerstone of the Global SKILup Festival is the Global SKILup Day Conference on December 10. The 2020 event features Keynote sessions from:

    • Mirco Hering, Global DevOps Practice Lead / ANZ Modern Engineering Practice (Managing Director), Accenture
    • Patrick Debois, Director of DevOps Relations, Snyk

    Additionally, the first round of industry leaders and subject matter experts confirmed to speak at Global SKILup Day include:

    • AJ Ajantha Godahewa, Senior Java Engineer & DevOps  Engineer, Caterpillar Inc.
    • BMK Lakshminarayanan, Solutions Architect, Bank of New Zealand
    • Bryan Finster, Staff Software Engineer, Walmart
    • Eric Robertson, Vice President of Product Management, Onit
    • Helen Beal, Chief Ambassador, DevOps Institute
    • John Willis, Senior Director Global Transformation Office, Red Hat
    • Lisa Chan, Head of DevOps, Petronas
    • Mahfuzur Rahman, Global Change and Release Manager, Pepsico
    • Sean Mack, Chief Information Officer and Chief Information Security Officer, Wiley
    • Sendil Kumar, Senior Software Engineer, Uber
    • Shivagami Gugan, Head of Site Reliability Engineering and Cloud, Emirates Group

    SKILup Festival Schedule

    The week-long festival offers numerous opportunities for DevOps professionals to SKILup, advance their careers, and expand their networks, including:

    • SKILup Careers Fair

    ​​​​​​​Monday, Dec. 7

    Network with HR and hiring representatives and discover DevOps career paths at leading organizations around the globe. Hear from the hiring leaders themselves which skillsets are most important. Explore emerging and available DevOps roles.

    • Get SKIL’d Up Days
      Tuesday, Dec. 8, and Wednesday, Dec. 9
      Get SKIL’d Up Days are dedicated to getting as many DevOps Humans SKIL’d up as possible across the globe. Get SKIL’d up days include but are not limited to training sessions across multiple global regions, live labs, and hackathons.
       
    • Global SKILup Day
      Thursday, Dec. 10
      The second annual Global SKILup Day is back on December 10. Global SKILup Day is a one-day conference that runs continuously across global time zones for 18 hours. The conference features a powerful line-up of ‘how-to’ sessions around the process, people and technical aspects of DevOps – led by some of the industry’s leading subject matter experts. The 2020 agenda will focus on sessions on Site Reliability Engineering (SRE), DevSecOps, Cloud and Cloud Native, Observability, Continuous Delivery Ecosystem, Kubernetes and more.

     

    • SKILup Recap
      Friday, Dec. 11
      The final day of Global SKILup Festival Includes regional fireside chats from our local SKILup Chapters and activities dedicated to recapping the week.

    If you are interested in learning about sponsorship opportunities for the Global SKILup Festival, please contact: CustomerService@DevOpsInstitute.com.

    To access more DevOps resources, connect with more Humans of DevOps and continue your upskilling journey, become a DevOps Institute community member: https://devopsinstitute.com/membership/.

    Share This: The @DEVOPSINST just announced Global SKILup Festival featuring a virtual career fair, various #upskilling opportunities & a global 18-hour conference! Learn more:  http://www.devopsinstitute.com/skilup-festival/  #SKILupDay

    About the DevOps Institute
    DevOps Institute is dedicated to advancing the human elements of DevOps success. As a global member-based association, DevOps Institute is the go-to learning hub connecting IT practitioners, education partners, consultants, talent acquisition and business executives to help pave the way to support digital transformation and the New IT.

    We help advance careers and support emerging practices within the DevOps community based on a human-centered SKIL framework, consisting of Skills, Knowledge, Ideas, and Learning.  All of our work, including accreditations, research, events, and continuous learning programs – is focused on providing the “human know-how” to modernize IT and make DevOps succeed.

    Web | https://devopsinstitute.com/
    Twitter | @DEVOPSINST
    LinkedIn | /devops-institute
    YouTube | DevOps Institute

  • Why is Site Reliability Engineering Important?

    Why is Site Reliability Engineering Important?

    Site reliability engineering (SRE) is one of the fastest-growing enterprise roles and set of operational practices for managing services at scale.

    During the Site Reliability Engineering SKILup Day June 18, I asked a group of the DevOps Institute Ambassadors why SRE was important to them.

    Below you will find some insightful responses, tips and calls to action. If you missed SRE SKILup Day or wish to rewatch any of the sessions on-demand, visit the conference landing page and access the videos for free: https://devopsinstitute.com/site-reliability-engineering-skilup-day/.

    Happy Reading!

    Anshul Lalit
    DevOps Institute Ambassador from Kristiansand, Norway

    “The term SRE surely has been introduced by Google, but directly or indirectly several companies have been doing stuff related to SRE for a long time, though I must say that Google gave it a new direction after coining the term ‘SRE.’ I have a clear view on SRE as I believe it walks hand-in-hand with DevOps. All your infrastructure, operations, monitoring, performance, scalability and reliability factors are accounted for in a nice, lean and automated system (preferably); however this is not enough. Culture is an important aspect driving the SRE aspects, along with business needs. As the norm ‘to each, his own’ goes, SRE is no different. It is easy to get inspired from pioneer companies, but it’s impossible to copy their culture and means to replicate the success, especially with your ‘anti-patterns’ and ‘traditional’ remedial baggage. Do you have similar infrastructure and business needs as the company showcasing brilliant success with SRE? No. Can it help you? Absolutely. The key factor here is to recognize what is important to your success blueprint after understanding the fundamentals of it and find your own success factors considering your cultural needs. Your strategy and culture need to walk together, just like your guiding (strategy) and driving (culture) factors.”

     

    Maciej Jarosz
    DevOps Institute Ambassador from Warsaw, Poland

    “With all of those methodologies and frameworks out there, one can only ponder: ‘Which one should I choose?’ Well, all of those frameworks and methodologies provide something of value, as long as you have an opportunity to actually test some of those concepts in your own local environment. Consider SRE for example: It worked for Google, sure. If anyone doubts it there are at least three books on the topic with the materials, proof and philosophy behind SRE. Even if your company is not the scale of Google you still should take a look at best practices that worked in 2017, 2018, 2019 and that are still working now. Considering the crazy times that we live in right now and the plethora of various free materials, conferences, blog posts, research whitepapers and videos on the topic, what are we waiting for? The knowledge is right here, ripe for the taking. Advancing the humanity of DevOps is just a matter of experimentation, trust and continuous improvement. And with events such as the SKILup Day: Site Reliability Engineering where you can network, exchange field stories, brag about your ‘battle scars’ and participate in some splendid speeches, it’s only easier to jump into the fascinating world of SRE discipline.

     

    Helen Beal
    DevOps Institute Ambassador from Chichester, England

    “I might be a bit biased since I’ve been focused on DevOps for nearly a decade as a consultant, coach and learning facilitator, but for me there are a number of systems of thought that contribute to the DevOps body of knowledge. I stole (with permission!) a phrase I heard from DevOps Institute’s CEO, Jayne Groll, many years ago that DevOps is the ‘harmonious, polygamous marriage of ITSM, lean and agile’ and I’ve also presented at several events over years around the correlations between DevOps and Holacracy. At an event in Munich a few years back, John Willis and I started a conversation about a DevOps Superpattern as he also added his ‘three-legged stool’ of The Theory of Constraints, Safety Culture and Learning Organizations’. For me, SRE is another valuable system of thought that we can learn from and use to make practical changes to the way teams and organizations work to drive higher organizational performance.”

     

    Mark Peters
    DevOps Institute Ambassador from Texas, USA

    “I recently saw a social media image for a shirt which broke out SRE as ‘Simply Restart Everything.’ While not entirely true, the concept of a site reliability engineer is important as another way to link Ops and Dev in the DevOps construct. SREs formalize a position whose job is to connect, to link folks together, and to streamline processes. Increasing reliability means to increase simplicity across multiple workflows. The bigger your organization, the more simple the process needs to be. Unfortunately, many organizations increase complexity, reduce transparency, and create wasted effort as they add more individuals. SREs are important in trying to understand processes from end to end and emphasizing outcomes rather than any particular process stage.”

     

    Sean Davis
    DevOps Institute Ambassador from Georgia, USA

    “Site reliability engineering bridges the gaps between platform design, development and operational execution by providing new perspectives on system reliability. When you link software engineering and systems engineering mindsets with operational engineering, you streamline the support of a product-focused on business outcomes not ticket output. It can be a valuable gambit for the traditional approach that pays off big for companies. By trading off specializations in focusing on operational burden, you gain a larger view of the platform and reduce the efforts required to support the product and spend more time automating and innovating to move towards self-healing and autoscaling products instead of manual, reactionary troubleshooting.”

     

    MIke D. Kail
    DevOps Institute Ambassador from California, USA

    “Instead of the word reliability, I prefer to use and approach it as resiliency, which then includes approaches and contributing members of the chaos engineering group that are hyper-focused on continually increasing the ability to recover from any and all failures, which we all know happen in both software and the underlying hardware. Resiliency also should resonate with the core Development teams as they should strive to continuously improve and collaborate with the SRE teams.”

     

    James Wasson
    DevOps Institute Ambassador from Oklahoma, USA

    “We create pipelines, version control, and infrastructure as code like breathing now. That means we are done, right? The beauty of SRE is that it takes us right to where the value is made. It requires us to go back to the beginning and ask questions about decisions we need to make regarding a system. Site reliability engineers help us remove “resulting” from our processes. With the help of these principles, we begin to make near-real-time decisions based on the impacts to our customers, rather than the results of the past. We spend so much time creating amazing features, determining the velocity of our teams, and implementing the newest framework from that great book, but one of the most helpful questions we get from site reliability engineering is ‘How fast is too fast?’ If our organizations can answer this question early, we are able to make more informed decisions that create extended and meaningful value to our customers.“

     

    Biswajit Mohapatra
    DevOps Institute Ambassador from Pune, India

    “The ever-changing digital and cloud landscape brings in an unprecedented need for collaboration, transparency, resiliency, stability, performance, reliability and correctness. SRE sets measurable engineering goals mapping to service level objectives (SLOs) and enables monitoring and tracking of these quality of service (QoS) parameters. SRE is a set of practices focused on reducing silos by shared ownership, planning for failures using error budgets, small-batch changes with focus on stability, automation of manual tasks and introducing a culture of measurement, monitoring and tracking. The fundamental goal of SRE is aimed at depicting a prescriptive approach to plan, build, implement, measure and achieve DevOps objectives with a focus on reliability and automation at every opportunity. SRE covers several critical areas of cloud platform architecture such as orchestrated automation, responsive operation, optimized performance, just-in-time scaling, modernized environment and predictive event management. It’s time to look at operations through the lens of software engineering practices. Leveraging SRE to design, build, operate and enhance software systems is critical to building the culture of risk-managed and reliable digital footprint for enterprises.”

     

    Mitesh Soni
    DevOps Institute Ambassador from Mumbai, India

    “What vs How
    Interface vs Class
    Abstract Class vs Class
    DevOps vs SRE

    Similarity and difference lie in their positions. Ryan Foland has given a wonderful example to describe What and How: ‘What’ begins at the surface level, and usually describes things in a general sense while ‘How’ describes the process of something or the underlying steps and actions that are done to get results. I find this example a perfect fit for the relationship between DevOps and site reliability engineering (SRE). Both DevOps and SRE have created buzz and confusion and will continue to do so. DevOps is cultural change to transform existing practices with people, processes, and tools for a better quality outcome with speed. SRE is a concrete implementation of DevOps practices or principles. I would like to leave one question here. Let me form the base first: Agile and DevOps complement each other. Agile is like a train compartment and DevOps is like an engine. Is SRE like a train track?”

     

    Marc Hornbeek
    DevOps Institute Ambassador from Puerto Vallarta, Mexico

    “Site reliability engineering (SRE) compliments DevOps by measuring and achieving reliability of applications and services working on production and DevOps infrastructure in a prescribed manner using error budgets, team relationships brokered by an error budget, Ops-as-code, and the use of reliability to control deployments.  SRE emphasizes the following objectives that are important to DevOps engineering:

    • Assure availability of applications and services.
    • Assure error rate and latency meet Service Level Agreements (SLAs).
    • Enable large-scale systems while controlling risk.
    • Create operational cost savings by automation and policies.
    • Improve skills of developers and SREs.
    • Resolve conflicts between Dev and SRE.
    • Improve capacity planning and provisioning.”

    Suma Puligella
    DevOps Institute Ambassador from Virginia, USA

    “SRE encompasses both software engineering and IT operations and bridges the gap between them. It ensures that the organization’s systems are scalable, stable, predictable and automated. SRE and DevOps seem like two sides of the same coin with a unified goal of enhancing the release cycle without any compromises. However, there are some differences between SRE and DevOps:

    • SRE covers architectural and design patterns along with reliability implementation techniques such as reactive programming. Whereas DevOps is a set of practices that combines software development (Dev) and IT Operations (Ops). DevOps also aims at continuous software delivery with high quality, reliability and shared ownership among software stakeholders.
    • DevOps raises the risks for the development team(s) to solve. Whereas SRE’s approach is to find problems and solve some of them themselves. SRE teams set service-level agreements (SLA) that define how reliable the systems need to be to end users. Their main goal is to improve performance and operational efficiency.
    • DevOps is all about the “What” needs to be done, SRE talks about “How” this can be done.

    The bottom line is that it’s all about the data. You need information in order to understand how to measure success and failure and how to gain continuous reliability across the applications.”

     

    Tiffany Jachja
    DevOps Institute Ambassador from Maryland, USA

    “Organizations are finding the best practices for delivering faster and meeting customer demands. Site reliability engineering is about building confidence that our systems work as expected. SRE defines the methods, concerns, and responsibilities needed to maintain or increase the reliability of a system. It improves our ability not only to deliver a product to end customers but also to do so in a sustainable way as an organization. Many workloads can be costly, complicated, or time-consuming for different reasons. These practices provide a foundation for the root analysis of our systems, at the end of the day we want to be able to set key goals, measure systems, and ensure a product or service fulfills its objectives. This is important for anyone with a stake in software development and delivery.”

     

    Uchit Vyas
    DevOps Institute Ambassador from Singapore

    “Site reliability engineering is a discipline that seeks to create reliable IT systems by managing the rate and quality of change, ensuring clients protect themselves from any break in service and avoid being subject to fines and penalties.

    As per my experience, SRE practices are mainly based around the following elements:

    • SLIs, SLOs and SLAs.
    • Monitoring.
    • Toil Definition.
    • Error Budgets.
    • Test Automation.
    • Capacity planning and measuring risk factors.

    SRE implements a lot of the same practices as DevOps, but from an operations perspective focuses predominantly on operational stability and resilience of the production estate.”

     

    Zuzana Homolyova
    DevOps Institute Ambassador from Slovakia

    “SRE works as a kind of connection bridge between development and operations as it cares about every process from the source code to deployment. It really focuses on how to bring scalable and reliable software systems into the real infrastructure, way, application, performance and security. To describe the difference between DevOps and SRE I would say: ‘DevOps asks what needs to be done but SRE asks how it can be done.’

    What is really important is that DevOps and SRE do overlap each other. They share goals to understand how to measure success or failure and how to gain continuous reliability across every application.”

     

    Craig Pearson
    DevOps Institute Ambassador from Newcastle, England

    “I’ve walked the line between DevOps and SRE in organizations and witnessed first-hand both good and bad practices. While there are a lot of SRE success stories, I’d like to focus on the occasional use of SRE as a justification to rebuild the walls around operations/production that DevOps strived for so long to take down. While adopting  SLOs and focusing effort on toil reduction are obviously beneficial, taking a defensive position over the production environment is not. The trigger for this is often an issue impacting production—sometimes major, sometimes minor—or the perception that more audit rigor is needed in this new continuous delivery world. Whatever the trigger, sometimes SRE is proposed as the answer (R stands for reliability, right?) SRE has to shift-left and spread more of the wisdom of production to teams delivering value-adding products and services to that production environment. Deploying value rapidly is crucial. Doing this in a reliable manner is key. Both are valid reasons for introducing site reliability engineering—the future. However, keeping the wisdom of production in a separate (silo?) SRE team and withholding access to production is a backward step.  A touch of back to the future maybe …”

     

    Nadeem Augustine
    DevOps Institute Ambassador from Cape Town, South Africa

    “Having been exposed to DevOps and SRE, I do see a difference between the two roles. I often find the DevOps way of working focuses on how to bring the issues into development and a way to process it between teams. This creates a collaborative way of working in the organization. That is a pivotal part in rolling out DevOps. DevOps is the ‘what‘ that needs to be done in order to bridge the gap between development. Having played both roles as a ‘developer’ and ‘operations,’ you now see how SRE plays a deeper role in assisting the organization in achieving the end goal. As an SRE you focus on the ‘how‘ to resolve issues end to end with the quickest most stable resolution. Having resolved the issues you create a more reliable and repeatable process.”

     

    Daniel Oh
    DevOps Institute Ambassador and CNCF Ambassador from Boston, USA

    “Who would be the most valuable resource to stabilize the cloud platform built on an immutable infrastructure (i.e. Kubernetes) for the Ops team? Here is the evidence that many recruiters continue to seek the roles that are named site reliability engineers (SRE) but also more IT Ops folks want to have SRE responsibilities in their careers.“

     

    Hugo Lourenço
    DevOps Institute Ambassador from Lisbon, Portugal

    “How long does it take to find the product you need? How long does it take to get the product delivered? Does the product/service require training or expert assistance? Do you need other calls +, products +, services +, to make this product / service work? Does the product require external maintenance and you will be accountable to remember the provider when it’s needed? To get support assistance or any other contact with the provider consumes your valuable time. Your time? All these reasons were the reasons why I embraced agile, lean and automation = DevOps, DevOps is the only weapon in a digital era. I’m passionate about building products and services where consumers will pay to keep your company to exist and deliver such amazing products/services!”

     

    Felipe Duenas
    DevOps Institute Ambassador from Quito, Ecuador

    “SRE is more than buzzwords and trends. It is far more about the people and process than the technology that underlies them. While technology certainly can (and likely will) adapt to the concept as it matures and more teams adopt it, you don’t need new tools to align your development and operations organizations around the principles of Site Reliability Engineering. SRE ’embodies the philosophies of DevOps with a greater focus on measuring and achieving reliability through engineering and operations work.’ SREs also ensure that everyone in the company agrees on how to measure reliability, and what to do when availability falls out of specification. This includes contributors at every level, from developers, through team managers and all the way up to VPs and executives.”

     

    Suresh GP
    DevOps Institute Ambassador from Singapore

    “Site reliability engineering is redefining the value of infrastructure operations and its relevance in the wake of DevOps toolchain and deployment pipeline. After a long time, we see that this area of discipline is creating a profound impact on the holistic value chain by building world-class resilience and reliability of products and services with an end-end view. It also focuses on creating a sense of shared ownership and experimentation in challenging the status quo and delivering streamlined customer experience. I see a lot of synergy with Agile, DevOps, Lean, ITSM with SRE that compliments the dimension brilliantly. Last but not the least, cultural change is of phenomenal importance to make this transition happen and be sustainable. The principles and practices are so sound that the legacy environments can still take advantage of it and contribute to velocity increase and improved reliability.”

     

    BMK
    DevOps Institute Ambassador and CNCF Ambassador from Wellington, New Zealand

    “Enterprises who run or want to run a cloud application at scale, need to adapt to SRE practices and disciplines. Merely stating a 99.99% SLA does not help, if you care about your customers and your customers’ experiences with your systems then, yes, we need to level-up our game, we need to understand the nitty-gritty of reliability of our systems, operations and more importantly understand the limitations and constraints within which we need to operate. Some useful pointers: 1) Caution: Do not simply rename your ‘system admins’ to ‘SRE’  2) Upskill your ops folks to code 3) Upskill your dev folks to learn and know more about infrastructure and operations.”

     

    Aparna Balasundar
    DevOps Institute Ambassador, India

    “If DevOps is the extension of agile to build continuous delivery pipelines, SRE is a natural extension of DevOps to build resilient, repeatable, reliable, scalable production systems. Shift left to include the SRE as part of the architecture design, build, deploy favoring long term viable systems. With the cultural mind shift, if SREs have to provide safe and reliable systems, developers have to dedicate building such systems. These joint working partnerships will benefit the overall business goal.”

     

    Simone Jo Moore
    DevOps Institute Ambassador from Occitanie, France

    “Site Reliability Engineering has as many touchpoints across the service value stream as any other practice. I challenge you to map your interactions across your enterprise so the impacts of SRE to the value outcome are clearly visible. Those companies that treat these touchpoints as part of their beating heart competencies versus peripheral consideration, will continue to leap forward. The socio aspect is important here. Technology is a catalyst—people’s interaction with the tech has shifted, is shifting and continuing to shift. Security is embedded; there is no point at which practices (human and automated) do not exist in SRE enterprise-wide. The resources we apply depends on how big and complicated the system is.

    It goes beyond technical feedback to being an advantageous feedback loop for improvement across business objectives with engagement and financial benefit. Think of SRE as a movie, yes I’m a sci-fi fan but think about movies like “Mission to Mars” or “The Martian” and even “Ad Astra.” In each of these, reliability also includes our trust in something being resilient. Even when things don’t go as expected, there are ways in which the system can be adapted to solve problems. Resiliency is about humans rather than technology, but think about the progression of AI. We want AI to become resilient in not about coming back to a baseline but move forward to a new baseline of its own accord. Its point of stasis is never the same yet reliable based on the quality of the engineering. Our point of stasis is never the same either, and the cycle continues.”