devopsy.kinsta.cloud

Tag: devops institute

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.
July 29, 2021
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.

July 8, 2021
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.
July 7, 2021
Lessons Learned on a Low-Code Journey

The popularity of low-code/no-code tools are on the rise as organizations chase the promise of creating ‘citizen developers.’ The idea of using these tools to empower non-technical developers and/or to free development teams from writing code line by line is certainly compelling.

About a year ago, a friend reached out to ask if I would critically review a book he was writing about citizen development. At the time, the expression was new to me but after reading and reviewing the book, I was intrigued. It challenged me to embark on my own citizen developer discovery. I want to share several applicable lessons I learned along the way.

Intrigued: Citizen Developer Tools Versus Dev Teams

The curious part of me was trying to understand if these were tools that would remove the need for expensive development teams. The previous, well-intentioned attempts had fallen short of their promise—think Computer Aided Software Engineering (CASE) from the 1990s as an example.

Around this time, I discussed the topic with the CTO of a progressive client. His business users would not wait for technical resources when they needed apps to address persistent problems. He was quick to point out that low-code was preferable to shadow IT. The architecture for these low-code/no-code tools meant database administration was in his team’s hands. He was supportive of business units building small tactical pieces of functionality with a clear business case, and he supported them where possible through training and allocating resources to their projects for data integrations and other functions.

The Challenge: Write an App

Encouraged, I decided to challenge myself over one weekend to see if I could write a commercial application. I had studied programming languages like Fortran and C in the 1980s, but I’d never worked as a developer and had never written commercial code.

Start of Day One

I selected a low-code tool at random. I would recommend, however, that a citizen developer engage the IT team rather than choosing at random, as most low-code/no-code tools have an underlying programming language. If your organization is a Java shop, for example, then it would make sense to pick a tool that has the same language—in this case, Java—at its source.

I purchased a six hour training course on YouTube for $20. This would prove to be a wise decision. Learning the tool I selected was not straightforward, but the training course allowed me to pause the tutorials, rewind and repeat to ensure I was understanding concepts and could follow along with the ‘how to.’

First task: write ‘Hello World.’ I recommend that citizen developers start here. If you can do this, then it’s more than likely you can build something more complicated.

Three hours later (of which two were a system error) … it was done.

Clicking on the green button produced the screen below.

At this point, I still had more questions than answers. The GUI for the development tool was point-and-click within a Windows directory structure. There was no command line editor. I was even more encouraged. Could it be this straightforward?

A note: while it took less than an hour to complete the ‘Hello World’ task, I encountered a Windows system error which pointed to a server port error. The vendor’s help desk didn’t operate over the weekend, but their documentation was adequate; it took a further two hours of effort to fix the problem, which arose because my Windows Surface Pro was both a client and a server.

Would an ‘average’ citizen developer have been able to overcome this problem? I’m not sure. I recommend when trying low-code/no-code tools that you also trial the help desk, even if you need to pay for it. While many software tool companies try to force software engineers to work through wikis to solve problems, citizen developers may need more hand-holding.

The next step was to build an application. Most non-technical people tend to describe applications from a graphical perspective and as business functions. This is very much in keeping with how I worked for a further two hours, at which point the ‘Home’ web page looked like this:

Using data from our in-house spreadsheets, I created the data model below with relative ease. I believe a citizen developer would benefit from asking an in-house database expert to review this ‘design’ to save time later when maintaining the application.

This work was undertaken at the same time as I was building a second tier of pages to amend data. So, for example, the automatically generated customer page which allows a user to search, add, edit and delete customer records looked like this:

This was completed in four hours. Once the table was created with the correct columns, the creation of the web pages was automatic. In fact, it became repetitive and I found it was easy to lose my concentration and make errors.

I was learning to save every small change to ensure that the live web and mobile application builds were working. A professional developer would see this as a form of continuous integration for the citizen developer.

I don’t recommend having teams of citizen developers working together, at least at the outset, as it introduces branching and versioning and the concept of ‘breaking a build.’ Professional developers would need to be consulted at this juncture.

End of Day One

I had a real sense of achievement at the end of day one and was eagerly anticipating day two. Citizen developers should note that, at this point, I had produced what developers would call a prototype. It would be possible, upon reaching this point, to approach IT to assign a developer to finish the job. If IT does not have capacity, then keep going.

Start of Day Two

Having designed screens and a database, the next task was to add business logic.

Creating flows of work with rules was a more engaging task, but still accomplished via drag-and-drop or point-and-click. Boolean logic operators like if- then- else allowed me to quickly build logic and attach it to visual elements on the webpage.

This is an event registration flow where data is accepted from a web page and, based on a true or false response, treated differently depending on that response.

As before, the first workflow took some time to learn. There were many ways to both trigger an action and direct the subsequent work. After a further half day, I had produced enough working code that I felt I probably couldn’t learn a whole lot more and the application was roadworthy.

From there, creating the mobile version of the app was as simple as pushing a button. At the outset, I had set a switch for mobile deployment. The web and mobile editions were always in sync, and the GUI was adjusting automagically for the deployment platform. Citizen developers should check on in-house standards for web and mobile app deployment configurations and ensure their selected tool supports them.

End Day Two

Lessons from My Discovery

Organizations that want to adopt low-code or no-code tools will need to ensure IT support and training for business users that want to self-service their app dev needs. I recommend early engagement and frequent retrospectives with IT colleagues.

Business functions should consider ‘easy’ and tactical opportunities for piloting.

Allocate an uninterrupted period of time to focus on the task. Learning a new tool over a weekend was a really good idea, too. There was zero context switching, apart from my wife dropping in with coffee for a chat.

I recommend citizen developers try to be a little bit Agile for these engagements. Using a ‘Plan, Do, Check, Act’ methodology means that you are not ‘all in’ on this—you are simply taking small discrete steps to see if you can solve problems more efficiently than you would if you instead waited for IT.

Professional developers should ensure that any low-code/no-code tools produce code that can be imported into their standard IDE and that the citizen developer’s code is not locked into the tool.

As a DevOps Institute Ambassador, O’Reilly helps empower DevOps Institute community members with the SKIL framework to advance the Humans of DevOps with skills, knowledge, ideas and learning. Learn more about O’Reilly’s work in DevOps here.

July 6, 2021
DevOps Institute Announces Upcoming Virtual Conference Lineup to Upskill IT Professionals, DevOps Practitioners and Decision-Makers
One-day conferences focus on the ‘how-to’ of DevOps, CI/CD, DevSecOps and Observability sponsored by Harness, RedHat, Accurics, GitLab, Splunk and more

Boca Raton, FL, June 24, 2021 – DevOps Institute, a global professional association for advancing the human elements of DevOps, today announced its virtual conference lineup through the third quarter of 2021. Upcoming conferences include SKILup Days and bespoke events presented by DevOps Institute and MediaOps. A SKILup Day is a one-day virtual micro-conference focused on DevOps upskilling, a deep dive into technology trends, and career advancement. These events bring in leading IT experts to upskill DevOps students, practitioners and decision makers.

Learn more and register for upcoming SKILup Days: https://devopsinstitute.com/all-events/

“DevOps Institute virtual conferences provide the Humans of DevOps continuous value as we upskill on the topics that are critical to every DevOps journey,” said Jayne Groll, CEO of DevOps Institute. “The inclusive and interactive nature of these events present new opportunities to connect with other industry professionals, SKILup on important IT practices and advance the global DevOps community.”

Q3 2021 Event Schedule

Open Source: The Evolution with Logz.io

June 30, 2021
Did you know open source is moving faster than ever with new observability projects? Is Kubernetes here to stay? DevOps Institute and MediaOps are proud to present this deep dive into these topics and more at Open Source: The Evolution with Logz.io.

Current confirmed speakers include:
- Jonah Kowall, CTO – Product Strategy and Execution, Logz.io
- Dotan Horovits, Product Evangelist, Logz.io
- Alan Shimel, CEO and Founder, MediaOps
Registration is now open: https://devopsinstitute.com/open-source/

Splunk DevOps ASEAN Day

July 8, 2021
This virtual event presented by Splunk, DevOps Institute and MediaOps, is designed to bring an educational experience to the Southeast Asian DevOps Community. Attendees will learn about the latest in software development and IT operations, increase developer productivity, create better user experiences and reduce operational uncertainty.

Current confirmed speakers include:
- Dave McAllister, Sr Technical Evangelist, Splunk
- Mani Govindan, Sales Director – Observability, Splunk
- Andrew Bearsley, Certified Architect – AIOPS, Splunk
- Jayne Groll, CEO, DevOps Institute
- Donnie Prakoso, Sr Developer Advocate, ASEAN, AWS
- Mike Moore, Sr Manager, Observability Sales Engineering, APAC, Splunk
- Greg Leffler, Observability Practitioner Director, Splunk
- Ram Jothikumar, Sr Manager, Cloud Infra, SRE & QE for Observability, Splunk
- Jakub Barc, Sr Site Reliability Engineer, Splunk
Registration is now open: https://devopsinstitute.com /splunk-devops-asean-day/

CI/CD SKILup Day

July 22, 2021
In software engineering, CI/CD or CICD generally refers to the combined practices of continuous integration and either continuous delivery or continuous deployment. Join this SKILup Day to learn how CI/CD bridges the gaps between development and operation activities and teams by enforcing automation in building, testing and deploying applications.

Event sponsors include Harness, Red Hat, Accurics, CloudBees, Basis, Instana, Redgate, and Moogsoft.

Current confirmed speakers include:
- Dave Farley, Independent Software Developer and Consultant, Founder and Director of Continuous Delivery Ltd.
- James Barter, DevOps for SAP Solution Director
- Grant Fritchey, Redgate Software
- Ravi Lachhman, Evangelist at Harness
- Anders Wallgren, VP of Technology Strategy at CloudBees
- John Jarboe, Developer Advocate, Accurics
- Chris Engelbert, Senior Developer Advocate at Instana, an IBM Company
Registration is now open: https://devopsinstitute.com/cicd-2021/

DevSecOps SKILup Day

Aug. 12, 2021
This full day of learning will examine how DevSecOps is an augmentation of DevOps to allow for security practices to be integrated into the DevOps approach. Sessions will explore how the traditional centralized security team model must adopt a federated model allowing each delivery team to factor in the proper security controls into their DevOps practices.

Current confirmed Sponsors include: Palo Alto Networks, Bridgecrew, Harness, Accurics, HCL, and GitLab.

Speakers coming soon!

Registration is now open: https://devopsinstitute.com/dso-2021/

DevOps: Straight Talk for Government

Sept. 9, 2021

More details coming soon!

Observability

Sept. 23, 2021

More details coming soon!

Become a DevOps Institute Member

DevOps Institute now offers a tiered professional membership model. Membership levels include Basic, Premium, Government/Nonprofit, Educator, In-Transition, and Enterprise Membership options, with a Student member tier to follow. DevOps Institute Professional Membership offers exclusive access to leading DevOps resources, discounted certification exams, DevOps capability assessments, premium content, discounted DevOps simulation experiences, members-only networking opportunities, career center access, and more.

Join or learn more at https://devopsinstitute.co m/memb ership.

About DevOps Institute
DevOps Institute is a professional member association. Our mission is to advance the human elements of DevOps.

We create a safe and interactive ecosystem where members can network, gain knowledge, grow their careers, lead and initiate, and celebrate professional achievements.

We inspire thought leadership and knowledge by connecting and enabling the global member community to drive human transformation in the digital age.
June 24, 2021
Survey Reveals Slight Decline in Level of SRE Toil

The amount of routine toil that site reliability engineers (SREs) perform declined slightly in the last year even though IT environments in general are becoming more complex to manage.

An annual survey of 300 SREs conducted by Catchpoint, a provider of an IT monitoring platform, in collaboration with VMware and the DevOps Institute suggests that the amount of toil—defined as low-level manual tasks—declined 15% in the last year.

Only 22% of respondents claim to be scientifically measuring toil, so, to a degree, the survey results are apocryphal. Overall, the survey, published this week, finds SREs are, not surprisingly, spending the bulk of their time on responding to incidents and outages, followed by participating in postmortem analysis and on-call rotations. The primary sources of toil cited in the survey are too much technical debt, lack of alignment of priorities and goals, lack of appreciation of business value, lack of training and support and lack of collaboration.

In terms of automation adoption, the most common use cases cited are release management, infrastructure management and application management. The tools most commonly employed by SREs are used to monitor infrastructure, networks and application performance. Adoption of artificial intelligence (AI) tools to manage IT operations (AIOps) remains low. The survey also finds respondents are roughly split evenly between centralized (42%) and decentralized (38%) approaches to managing IT. Another 20% said they have adopted a hybrid approach. Lack of visibility across the stack (53%) was the most cited cloud application monitoring challenge.

The survey also finds only half of respondents continually refine their service level objectives (SLOs).

Leo Vasiliou, director of product marketing for Catchpoint, said it’s clear that SREs are becoming more proactive in terms of preventing and containing the impact of IT incidents. The challenge they face is lack of visibility and context as those IT environments become more complex. Complexity is increasing, in part, because of the rise of cloud-native computing platforms running microservices-based applications that have lots of dependencies.

Less clear right now is the percentage of IT environments managed by SREs today. In theory, a single SRE can do the same amount of work as multiple IT administrators by automating processes using various DevOps tools rather than relying on traditional graphical tools. However, SREs are hard to find and retain. It’s also not always apparent to what level of automation needs to be attained to qualify to be an SRE or, for that matter, what certifications may be required. Interest in becoming an SRE is rising, in part, because they typically command higher salaries.

In the meantime, it’s clear organizations will need to find ways to automate the management of IT to a much greater extent. Most organizations cannot afford to hire a small army of IT professionals to manage IT environments that become more complex with each passing day. Everything from DevOps best practices and next-generation observability tools that promise to provide more context to AI platforms will all be part of the mix. The challenge is finding a way to implement those tools before IT management spins further out of control.

June 18, 2021
Learning ‘The Third Way’ of DevOps – Continuous Improvement
I refer to the third way of DevOps–continuous experimentation and learning, as simply continuous improvement. In some sense, there is no way to learn the third way of DevOps because it is, by definition, a moving target. It does make sense to discuss what is needed to create a continuous learning organization for DevOps continuous improvement that builds on mastery of the first way and second way of DevOps.

As indicated in my blog Learning ‘The Second Way’ of DevOps – Continuous Feedback and my prior blog Learning ‘The First Way’ of DevOps – Continuous Flow, it is clear many organizations are struggling to realize well-engineered DevOps, even the first way of DevOps, continuous flow.

The first way of DevOps, continuous flow, is the foundation for DevOps. Once mastered, an organization will naturally want to master the second way of DevOps to achieve the higher level of benefits that continuous feedback offers, when engineered well. Once the second way of DevOps is achieved, then an organization will naturally want to master the third way of DevOps, to sustain and grow their DevOps capabilities.

DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

Learning Continuous Improvement

There are no training resources dedicated solely to the third way of DevOps—continuous improvement. Many of the same resources as the first way of DevOps and the second way of DevOps do have some relevant information, though. Analysis of DevOps results, third-party research sources, industry sources such as publications, articles, conferences and tool vendors roadmaps for DevOps and related frameworks including site reliability engineering (SRE) and AIOps are good sources of information that stimulate self-directed teams to seek the training information that is most relevant to the organization’s DevOps improvements.

Why Is Learning Continuous Improvement Important to Engineering DevOps?

The third way of DevOps—continuous improvement—requires an organizational commitment to continuous learning and mastery at the most advanced level. Typical skills needed include implementation and operation of advanced practices for microservices design and operations, advanced continuous testing, multi-pipelines, value stream management, SRE, observability, DevSecOps and AIOps. Retention and development of highly skilled and hard to find experienced DevOps professionals and SREs makes it important to develop skills in-house.

How Is Learning Continuous Improvement Accomplished?

The following are recommended engineering practices for learning continuous improvement:
- A continuous learning culture encourages individuals to continuously gain knowledge and exchange experiences and ideas for DevOps and SRE.
- Mentoring is an explicit program.
- Retrospectives are structured to thoroughly analyze significant, unexpected events and determine solutions that will prevent the events in the future.
- An active online library of DevOps and SRE training resources is maintained that tracks the latest and most innovative approaches to DevOps and SRE.
- DevOps and SRE teams evolve their skills and advance their careers by engaging with industry thought leaders to continuously update training content.
- Partner with trusted education and training partners ensure the highest-quality learning content and tools are made available to DevOps and SRE teams.
- A portion of DevOps and SRE teams time is allocated for training and education.
- Cross-team sharing of recommended engineering practices is proactively pursued using the concepts of Yokoten—proactive sharing of practices between teams.
What Is Needed to Implement Learning Continuous Improvement?

The following are recommended engineering practices for implementing a learning program for continuous improvement.
- Assign roles and responsibilities to experts for defining a training program for DevOps continuous feedback (e.g., DevOps sensei, training PM, evangelist).
- Conduct a continuous feedback DevOps skills gap assessment.
- Define a training strategy that best address the gaps and fits the needs and priorities of the organization.
- Define a training budget that includes expenses and time allocations per role and skill.
- Determine which skills and roles can be covered by inexpensive self-study resources.
- Determine which skills and roles warrant more costly commercial training.
- Identify training goals for each role.
- Ensure recruiting job profiles match skill requirements for DevOps skills that are most relevant to the organization’s strategic goals.
- Create a continuous learning culture that encourages individuals to continuously gain knowledge and exchange experiences and ideas for DevOps and SRE.
- Build an active online library of DevOps and SRE training resources that tracks the latest and most innovative approaches to DevOps and SRE.
- Engage with industry thought leaders to continuously update con tent for DevOps and SRE teams to evolve their skills and advance their careers.
- Partner with trusted education and training partners to ensure the highest-quality learning content and tools are made available to DevOps and SRE teams.
- Put in place means to make training resources visible and available.
- Set training goals for teams and individuals.
- Put in place incentives and recognition programs for training.
- Track training progress.
Some of the best sources of DevOps training resources are listed below:
1. The DevOps Institute
2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro.
3. Udemy.com
4. Recorded talks and publications of IT Revolution
5. Books such as my own Engineering DevOps, by Marc Hornbeek.

What This Means

The third way of DevOps—continuous improvement—requires an organizational commitment to continuous learning and mastery at the most advanced level. Typical skills needed include implementation and operation of advanced practices for microservices design and operations, advanced continuous testing, multi-pipelines, value stream management, SRE, observability, DevSecOps and AIOps. Analysis of DevOps results, third-party research sources, industry sources such as publications, articles, conferences, and tool vendors roadmaps for DevOps and related frameworks including site reliability engineering (SRE) and AIOps are good sources of information that stimulate self-directed teams to seek the training information that is most relevant to the organization’s DevOps improvements.

Organizations must approach DevOps training strategically and continuously to leverage training resources to best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.
June 17, 2021
Learning ‘The Second Way’ of DevOps – Continuous Feedback

As indicated in my prior blog Learning the ‘First Way’ of DevOps–Continuous Flow, many organizations are struggling to realize well-engineered DevOps, even the ‘first way’ of DevOps – continuous flow.

The first way of DevOps, continuous flow, is the foundation for DevOps. Once mastered, an organization will naturally want to master the second way of DevOps to achieve greater benefits that continuous feedback offers when engineered well. DevOps is an evolving body of knowledge. There is no one-stop shop that covers all roles and the complete range of skills required for DevOps. A DevOps-competent workforce requires an ongoing commitment to DevOps skills development and mastery. Enterprises must approach DevOps training strategically to leverage training resources to their best advantage.

Learning Continuous Feedback

There are no training resources dedicated solely to the second way of DevOps—continuous feedback. Many of the same resources used to learn the first way of DevOps have some relevant information, though. DevOps monitoring, release automation and security tools publications, articles and tool vendors are a good source. A DevOps expert who is experienced with mature DevOps can select the training information that is relevant to the specific continuous feedback tools and feedback metrics used by the enterprise.

Why This is Important to Engineering DevOps

Continuous feedback requires a mature understanding of DevOps concepts and practices. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security.

How Is Learning Continuous Feedback Accomplished?

The following are recommended engineering practices for learning Continuous Feedback.

Roles and responsibilities are assigned to experts for defining a training program for DevOps continuous feedback (e.g., DevOps sensei, training PM, evangelist). Continuous feedback DevOps skills gap assessments are conducted periodically. Dev and Ops training strategies are designed to address gaps and priorities of the organization for DevOps continuous feedback. A training budget that includes allocations of expenses and time allocations per role exists to support continuous feedback. Continuous Feedback goals and SLAs are defined for each role.

Recruiting job profiles match skill requirements for DevOps skills relevant for continuous feedback. Training resources are available and visible to those that need continuous feedback training. Training goals set for teams and individuals include goals for continuous feedback. Incentives and recognition programs support Continuous Feedback training. Continuous feedback training progress is tracked and visible.

What Is Needed to Implement Learning?

The following are recommended engineering practices for implementing a learning program for continuous feedback.

Assign roles and responsibilities to experts for defining a training program for DevOps continuous feedback (e.g., e.g., DevOps sensei, training PM, evangelist). Conduct a continuous feedback DevOps skills gap assessment. Define a training strategy that best addresses the gaps and fits the needs and priorities of the organization. Define a training budget that includes expenses and time allocations per role and skill.

Determine which skills and roles can be covered by inexpensive self-study resources. Determine which skills and roles warrant more costly commercial training Identify training goals for each role. Ensure recruiting job profiles match skill requirements for DevOps skills that are most relevant to the organization’s strategic goals.

Put in place the means to make training resources visible and available. Set training goals for teams and individuals. Put in place incentives and recognition programs for training. Track training progress.

Some of the best sources of DevOps training resources are listed below:

1. The DevOps Institute
2. Partners of The DevOps Institute, such as Learning Tree International and Xellentro
3. Udemy.com
4. Recorded talks and publications of IT Revolution.
5. Books such as my own “Engineering DevOps,” by Marc Hornbeek.

What This Means

To accomplish the benefits of the second way of DevOps—continuous feedback requires a commitment to continuous learning and mastering skills beyond what is needed for the first way of DevOps–continuous flow. Specific skills are needed for implementation and operation of advanced monitoring tools and practices for application performance, database performance, advanced continuous testing, advanced release management, infrastructure performance and continuous security. Organizations need a trained workforce to succeed with DevOps. Organizations must approach DevOps training strategically and continuously to leverage training resources to their best advantage. To learn more about my blueprint for learning all things DevOps, refer to my book Engineering DevOps.

June 11, 2021
How Low-Code/No-Code Can Transform Your Organization

For many companies, IT transformation is no small feat. Between the technology, process and organizational changes needed, it can take time to see a return on your IT transformation efforts and investments. So it’s no surprise that low-code/no-code is starting to be seen as a compelling solution for some.

With low-code/no-code, you can empower teams of ‘citizen developers’ and enable experienced developers to accelerate deployment and reduce IT backlogs. To gain insights on the ways that low-code/no-code can transform your organization, I asked several DevOps Institute Ambassadors for their thoughts. Here’s what they said:

Brendan O’Reilly, DevOps Specialist, Daysha DevOps

Low-code/no-code introduces urgency into an organization. By removing the bottleneck that is scarce development resources, you can reduce the lead time to value.

Mark Peters, Technical Lead, Novetta

Low-code situations are likely best for highly tailored situations, with clearly defined purposes and minimal changes. Low-code can work when your business depends on scaling rather than creating new code. If the business is good enough, and one is adding microservices or more instances of the same expanded for a larger market, low-code can be perfect. Implementing low-code then allows the next opportunity to move from some code to no-code, providing a graphical interface to change architecture, implement policy or change recurring controls through mouse clicks rather than code. This also provides an excellent chance for improved ops control; if one is scaling the number of users, controls can be implemented to ensure the graphical delivery does not hard-code a password into the system, instead of relying on approval checks within an alternative interface.

Vishnu Vasudevan, Head of Product Engineering and Development, Opsera

When an organization practices DevOps, they continuously expand by team, product, platform and application because of different solutions coming into the market. Incorporating a low-code/no-code approach gives enterprises the ability to speed time-to-market and expand engineering capabilities beyond IT.

If you have a low-code platform that can help manage and provide visibility into technology and security compliance, that’s a gold mine for any developers or any organization. For example, anytime a new application comes in, teams can use a template from the previous application and put it over the new application. The same security quality of the audit governance is quickly established as a baseline, and all the developers have to do is focus on coding.

Shriniwas Sathe, DevOps Chief Architect and CoE Leader at Capgemini

Low-code/no-code tools can help change the way that regular employees interact with technology. With no-code tools, every employee, regardless of their background, can create custom applications, websites, forms, etc. With low-code tools, this can be taken a step further by building upon the offerings of a no-code tool by coding in the unique features needed by the organization. This is much less time-consuming compared to traditional development processes, even though it requires a general know-how of coding.

With every employee able to contribute to new applications and tools, there’s a better chance of obtaining unique insights and unforeseen capabilities. You can also simplify processes to an extent where regular employees can benefit from the freedom from tedious and repetitive tasks. There are low-code/no-code tools for most industries, which gives you a choice of either a ready-made solution or one that can be customized to your particular requirements.

Peter Maddison, Founder, Xodiac, Inc.

Low-code development platforms are great at automating important procedures using drag-and-drop editors that allow citizen developers to create virtual models of an app’s business logic and user interface.

A major advantage of having an enterprise no-code platform is the presence of built-in governance capabilities. No matter what an IT team’s size, a central console offers visibility for all applications and environments so that they can keep track of any issues or vulnerabilities.

Business developers can use the solution to create applications that fit their unique business needs. And more than one developer, or a team of developers, can work on the same module at the same time.

Of course, we need to ensure we are providing appropriate guard rails so our citizen developers are not able to accidentally expose data or create additional risks through the solutions they create.

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

June 3, 2021
How to Spot SRE Adoption Barriers
It’s no secret that site reliability engineering (SRE) adoption is growing. The operating model, it seems, is pivotal for digital transformations across the enterprise. According to the Upskilling 2021: Enterprise DevOps Skills Report, 22% of respondents (up 7% from last year) cited SRE as the approach they need to continue automation in 2021.

Common Adoption Barriers

However, for some companies, adopting SRE principles and practices isn’t always easy. Ahead of the upcoming SKILup Day conference focused on SRE (Register for SKILup Day: SRE here), I asked several DevOps Institute Ambassadors and SRE subject matter experts to provide insights into the barriers of SRE adoption. Here’s what they shared:

Marc Hornbeek, CEO and Principal Consultant at Engineering DevOps Consulting and author of the book, “Engineering DevOps”

“The primary barrier for SRE adoption is executive vision and team alignment around a goal to transform to SRE practices. SRE affects the entire organization’s practices, roles and investment priorities. Without an executive sponsor, SRE transformations are not going to go far.”

Stephen Walters, Solution Architect at xMatters, Inc.

“Culture, and in particular, cultural change, is the greatest barrier to SRE adoption. As much as everything about the human race, the things that got us to being the creatures we are today, is about evolution, which is change, and we are not particularly good at it. Or, more specifically, the bigger the change, the more resistant we are to it. It has always been a great oxymoron in IT philosophy that in order to “transform,” you must change, but that transformation is occurring because we are not good at change. So it was with agile in the early days. Organizations wishing to transform to agile (small, iterative change) would do so under a transformation project, which would typically be waterfall (big bang). Big change, big cultural resistance. The key is to implement transformation in smaller, agile chunks. They are more easily accepted and testable, and also easier to roll back or adapt if they do not work or are not acceptable. All of the benefits of agile development apply to agile transformation.

The second greatest barrier is, then, “buy-in,” where the simple answer is, unfortunately, show the end user “what is in it for them.” This will typically override the enterprise-scale view of “what is in it for us?” but, over time, with any cultural transformation, this is one of the things that should change, iteratively, and also be a focus for developing a more holistic and empathetic culture.”

Shivagami Gugan, Chief Technology Officer at CX Tech Unicorn

“Any organization, irrespective of whichever level of maturity they currently exist on today, can adopt SRE and improve their business outcomes. However, the key underlying principles of SRE and its applicability should be understood properly. There is a lot of hype around transformation and the first barrier is about understanding what SRE means within your organizational context. I find most of the time, people try to imitate what highly mature companies like Google or Spotify or some other cloud-born company does, and this usually results in failures. SRE is the purest form of the implementation of DevOps. SRE is about removing the silos in a product life cycle to achieve business outcomes in a safer, faster, cheaper and better manner. If this is understood clearly, the first barrier gets removed.

The second barrier is this complicated vision of boiling the ocean – doing 100% Agile, 100% DevOps or 100% SRE. This doesn’t work, especially when you have heritage systems of records, on-premises services and heritage infrastructure and a whole lot of baggage built over several years (sometimes decades) which is the usual case for most companies. So be very clear in choosing target areas.

The third barrier is when you think SREs specialize in building operational reliability, but do not have anything to do with the development or the deployment phases of the life cycle. Reliability is everyone’s problem – the technical product manager, the developer, the tester, the support engineer; not just the SREs. The reality of the SRE role is to ensure services availability and reliability by supporting the other teams that own these services. SREs are enablers, they are collaborators, and their goal is to ensure that the services are overall resilient, reliable and that incremental value is delivered in a continual manner. When an organization understands that implementing SRE is an underpinning cultural change that affects all parts of the organization, then it becomes easier to remove the main barriers.”

Lisa Chan, Head of Software Engineering & DevOps at PETRONAS

“Not all organizations have the luxury of having an Ops team composed of skilled developers, which is a key success factor for the adoption of the SRE working model. In my case, I’m in an IT organization of 1,800 folks that has supported an oil and gas company since its inception 40 years ago. We serve a captive market of an integrated energy business with more than 100 companies under its portfolio. As a result, there is a legacy landscape of more than 2000+ applications. The IT organization still maintains the common “Dev is Dev, and Ops is Ops” anti-pattern. Even though we are in transition towards a working model that is more collaborative, it is unrealistic to expect our 300 Ops personnel to reskill themselves to be developers, because many of them have traditional skill sets along the typical Ops silos; e.g., networking, database admins, server admins, data center management, call center agents, etc.”

BMK Lakshminarayanan, Value Stream Architect at Bank of New Zealand

“Building the SRE practices and skills within enterprises are always challenging, as some are still embroiled with old ways of thinking. The thinking, associated techniques, available tools and limited skills are constraining SRE adoption in most enterprises.

Renaming the system admins to SREs neither helps nor makes SRE experts. Investing in expensive tools doesn’t help, either. Any adoption and transformation is a gradual process. A typical medium to large enterprise has a few hundred systems, applications and services with various operating systems to support, database platforms to manage and hundreds of application databases to monitor or administrate. To this complexity, add all the dependencies of other services and components, as well. Hence, redefining the SLOs, SLAs and SLIs for these services, automating everyday maintenance tasks, understanding the toil, building resilience and fault-tolerant characteristics within these systems and applications are uphill tasks for most enterprises.”

Identifying Other Common Adoption Barriers

Many other common barriers for enterprises are:
- Availability of up-to-date system and application information in a centralized platform
- Observable nature of legacy systems
- Understanding the dependencies and service levels (Promise Theory)
- Availability of the right tools for the right job
- Skills – old ways do not open new doors.
- Time – time and space for people to upskill, train and experiment.
Want to learn more about SRE and how to overcome these adoption barriers? Join us for SKILup Day: Site Reliability Engineering on May 20. Register here: https://devopsinstitute.com/sre-2021/.
May 5, 2021