devopsy.kinsta.cloud

Category: DevOps Culture

  • CodeSee Unveils Open Source Hub

    CodeSee Unveils Open Source Hub

    CodeSee today launched a free Open Source Hub (OSH) community through which developers can more easily analyze the codebase that makes up an open source software project.

    Shanea Leven, CodeSee CEO, said that capability is crucial because making it easier to explore open source codebases reduces the level of effort required for developers to understand where to make contributions.

    OSH is based on a namesake visualization tool that CodeSee created. The CodeSee tool makes it possible for developers to see how a codebase has been constructed using graph technologies that scan software repositories and identify components and their relationship to one another. Developers can also use CodeSee to better understand what impact changes to that codebase will have.

    In addition to making it easier for developers to discover open source software projects, OSH also enables maintainers and contributors to create personal profiles through which other members of the open source community can see how their efforts have impacted various projects.

    CodeSee, as part of OSH, is also providing integration with Discord, an online voice, video and text collaboration service, to make it simpler for maintainers and contributors of open source software projects to collaborate.

    Leven said it simply takes too long today for most developers to pore over a codebase to understand where they might contribute. The larger a codebase becomes, the less likely it is a developer will want to take the time required to begin making a meaningful contribution, she noted.

    OSH is arriving at a time when maintainers of open source projects are especially looking for help securing open source software. The core issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. Many of them simply don’t have the time to immediately provide a patch to an application when a zero-day vulnerability is discovered.

    Unfortunately, many IT vendors and large enterprise IT organizations benefit from open source code without contributing anything meaningful back to the project—whether in terms of financing or helping open source maintainers find and remediate vulnerabilities. Not every contribution has to be in the form of code, either. Many open source projects simply need help with documentation which, once provided, should free up other contributors to focus more of their time and effort on application security.

    It’s not clear to what degree business and IT leaders realize how dependent their organizations actually are on open source software. Even when they do, it’s not easy to onboard a developer to any software development project. It can take months before a developer is actually making meaningful contributions to a project.

    Application development, by definition, is now a group effort. The days when a lone developer cared for an entire application are long over. The issue is finding a way for teams of developers to more easily collaborate when most of them have never actually met in person.

  • Quick! Define DevSecOps: Let’s Call it Development Security

    Quick! Define DevSecOps: Let’s Call it Development Security

    For a good long while, DevSecOps referred specifically to vendors like Veracode that did static application security scanning, dynamic application security scanning, software composition analysis and some form of runtime monitoring (usually interactive scanning). Then we realized that DevSecOps was potentially a lot more than that and, like DevOps, we drove the word to encompass all things that shift security left.

    That’s where we are now. But that leaves the DevSecOps market confusing to a lot of people. I propose we rename the tools that specifically focus on code quality to Development Security—even though that name is not perfect and all-encompassing. It’s a better fit than terms in other spaces, like Password Management, which includes two-factor authentication (2FA), multifactor authentication (MFA) and, increasingly, passwordless and secrets management, none of which actually use passwords for the focus of their functionality.

    This way, we can all understand that DevSecOps is the mindset and methodology and Development Security is one piece of implementing DevSecOps.

    There are probably people smarter than I am who have come to this (or alternate) conclusions, and I’m happy to run with their solutions, too—this is just an attempt to make it less confusing for those who don’t live and breathe the security and DevOps markets. If a new person says, “I think we need DevSecOps,” they are in for a journey to actually figure out what they meant and if what they need is actually DevSecOps. We should strive to clarify that so, at the beginning of their research, it is clear that DevSecOps is like DevOps—an overarching term for policies, procedures, mindset and products while the tools that can help with DevSecOps, like those that make up the overarching DevOps toolchain, belong to a market segment named X. In my case, I proposed Development Security because it’s a close fit. What we actually call it is irrelevant, as long as new people understand it is a subset of DevSecOps.

    While you continue to keep the systems spinning and the organization online, when you research these products, use phrases like, “I’m looking for Development Security tools that fit with a DevOps environment.” Markets are largely named by vendors and pundits but, in the end, all these people want to talk in terms their customer base recognizes. So, if enough of you ask for Development Security, that’s what they’ll all start calling it. Effective immediately, that’s what I’m calling it. It is a distinctive set of functionality that all orgs who do internal development need, so let’s give it a distinctive name. And yeah, drop me a line if you have a better name. I’m tied to making it easier, not to a specific term.

  • DevOps Connect: DevSecOps — Building a Modern Cybersecurity Practice

    DevOps Connect: DevSecOps — Building a Modern Cybersecurity Practice

    Malicious actors are constantly looking for new ways to gain access to sensitive data and corrupt systems. As software supply chain attacks are on the rise, security has become a top priority and a growing area in the regulatory and standards landscape. DevOps teams need to approach security as an ongoing part of the software development cycle by implementing DevSecOps practices at scale to improve the security of their software supply chain and ensure the components of the application code are trustworthy.

    At DevOps Connect: DevSecOps Virtual Summit, on July 12, we’ll share exclusive content from our RSAC 2022 event to help DevOps teams integrate security in their process from the start. Internationally recognized DevOps and security leaders will examine the supply chain risk landscape, market trends and practical solutions, and provide strategic insights on emerging regulatory topics.

    Attendees will gain valuable insider knowledge, tips and tricks they can share with their team and immediately put into practice to build a modern cybersecurity practice within their company.

    Things You’ll Learn

    The agenda features a mix of DevOps and cybersecurity topics, including:

    • AppSec and DevSecOps best practices
    • SBOMs and security regulations
    • API, open source and supply chain security
    • Cloud and Kubernetes security risks
    • Pentesting at scale
    • The three ways of DevOps
    • Shift-left security
    • Open Zero Trust
    • And more

    Meet the Speakers

    The speaker lineup features some of the foremost innovators in the DevSecOps community, including:

    • Jim Zemlin, executive director at the Linux Foundation
    • Chenxi Wang, founder and general partner at Rain Capital
    • Jennifer Czaplewski, senior director of cybersecurity at Target
    • John Willis, senior director of the global transformation office at Red Hat
    • Caroline Wong, chief strategy officer at Cobalt
    • Priyanka Sharma, executive director at CNCF
    • Dr. Amit Elazari, director of global cybersecurity policy at Intel Corp
    • Cherilyn Pascoe, senior technology policy advisor at National Institute of Standards and Technology (NIST)
    • Larry Maccherone, DevSecOps transformation architect at Contrast Security
    • Tracy Bannon, senior principal at The MITRE Corp
    • And many others

    Visit the Exhibit Hall

    In addition to the sessions, attendees can visit the virtual exhibit hall to interact with partner sponsors including Sysdig, Sonatype, Check Point Software Technologies, Prisma Cloud, SUSE, Qualys, Traceable AI and more. The expo hall will be open throughout the event, giving attendees the opportunity to chat with the sponsors and download information at any time.

    Registered attendees will also receive a link to access the virtual environment on-demand. To see the full agenda and to register for free, please visit the DevOps Connect: DevSecOps Virtual Summit website.

  • Creating Career Opportunities in Quality Engineering

    Creating Career Opportunities in Quality Engineering

    Software testing is the thread that connects code to customers, ensuring that the code created by development teams works for users and supports customer loyalty. But as the demands of software development are transformed by DevOps and customer expectations rise, the career and role of the software tester is evolving rapidly. Customer expectations have made it imperative for applications to work seamlessly, necessitating evolution in QA and testing.

    As the QA and software testing sector progress—and “quality engineering” becomes the de facto term for creating agile, customer-centric software teams—QE is attracting a more diverse pool of leaders as the career skillset widens. The more quality engineering becomes the differentiator between elite software teams that thrive in a DevOps world and teams that struggle to adapt, the more important it becomes to elevate diverse leaders in the industry.

    Understanding this, mabl recently held a panel discussion with QA and software testing industry veterans who discussed the new era of quality and how these changes are transforming who enters the field.

    The Evolving Role of the Software Tester: Building Professional Confidence

    The constant evolution in software testing and quality engineering, though exciting, also presents a challenge to QA professionals: How to consistently build the necessary skills as well as the confidence to succeed. As quality engineering becomes a multidisciplinary career role that encompasses engineering, functional and non-functional quality management and the customer experience, the question for QE professionals becomes one of continuous learning and the confidence to broach, if not lead, challenging discussions.

    LaDeitra Lee, chief technology officer for Sparx Studio, understands how confidence can sometimes feel elusive—especially for younger pros just getting started. But her message is meant to encourage those just starting out to speak up: “QA knows the most about the product because we know the customer’s perspective, and we’re testing the full product from the front end that everybody sees all the way to the backend … the main thing: You want to make sure you have the confidence in your work,” Lee said.

    When quality engineers have confidence in their skills, they’re better able to collaborate with the rest of the software development team to improve testing strategy and triage defects. But building confidence can be challenging, especially as software testing has embraced coding skills to the point where software developers can specialize in quality as SDETs. However, that doesn’t mean that coding experience is the most essential skill in a quality engineering career. Since quality engineering is all about connecting code to user context, soft skills like empathy are just as critical for the next generation. So, even if QE professionals aren’t expert coders, they can build confidence in their skills by understanding their unique place in the software development process.

    Marjie Carmen, software engineering manager at Arch Insurance, agreed. “When I started out, it was commonly believed that software testers didn’t need programming skills or software engineering skills since the focus was on manual testing. But today, I see QA working hand-in-hand with and having almost the same skills as a software engineer; sometimes even more. I really see quality assurance as equal because they have to know the business side and the perspective of the users and where the industry is going. They have to make really good recommendations about how the product should be and need the confidence to go to the engineering side and say, ‘What’s the fastest way I can get this product tested and in the hands of the user?’”

    Creating Unconventional Career Paths in Software Development

    How has hiring for a tester today changed in the last decade? As quality engineering continues to grow as a profession, many in the field are creating new career paths by moving between different roles throughout the software industry. By supporting these unconventional candidates, Maaret Pyhäjärvi, principal test engineer and prominent QA speaker, said that software development organizations can grow internal talent and help quality engineering develop as a field.

    “We hope that there’s more of this openness for moving from one technical role to another,” said Pyhäjärvi. “There’s always the possibility of learning small slices of technicality. Some of my favorite architects these days are so good at software testing; so good at programming and can really bring the whole team together. So we need to allow that kind of movement where people get to try things and break away from stereotypes.”

    Susan Marie, president of the Triangle Software Quality Association (TSQA) said, “I love the capital-Q quality emphasis because it gives me leverage to do well—that’s just one area of quality. I hate the idea that the job title is the one thing that you’re allowed to do; you need to be giving guidance around what’s expected of you and what other people can expect from you.”

    While technology is always evolving, former Slack senior engineering manager Karine Sully said the main characteristics for the job have been consistent—even as far back as a decade ago. “I always look for people who are curious and who have good communication and organizational skills, especially coming in at entry-level or lower-level. All you need is to be able to think critically and organize your thoughts and be able to communicate what it is you’re doing. Then, you can push beyond that and grow.”

    Given the challenges inherent to working with multi-disciplinary teams, Lee said, “I think what helped me the most is having a sponsor. So my advice for anyone on my team, or anyone that’s looking to grow in their career, is making sure you have someone a few levels above you looking out for you.”

    Fostering Diversity in Software Testing Teams

    Growing responsibilities equal a growing number of requirements and skills for quality engineering careers. Navigating the hiring process is never easy, but succeeding in a rapidly changing field can feel like running a marathon at a full sprint, especially when trying to foster more diversity in software development and testing.

    “…Diversity and inclusion are definitely very dear to my heart, and I feel you have to go where people don’t look like you. So if you want to hire more Black or Hispanic engineers, you have to go to areas where you see more of them,” Lee said. “If it’s engineering that you’re looking for, do your research and find those schools that specialize in that particular area. I’m a part of the National Society of Black Engineers, so I tap into that network if I’m trying to help build a diverse team.”

    Carmen agreed that hiring managers need to look closely at areas where there may be holes to fill. “I got into management by looking at gaps and filling them—it was always my goal to find a gap and say, ‘Hey, I can take that off your hands and in the role.’ So it’s a natural evolution to get the different roles that I’ve had by saying yes to more and different responsibilities.”

    Conclusion

    Though the QA and software testing fields are in the midst of several transformations, the change is opening the door for more people to have successful careers in software quality. Though their role is to ultimately improve the product, that road to quality is usually filled with bugs and unpredictable challenges. When quality engineering professionals are confident in their work, it’s easier for them to lead constructive conversations on improving the product—and facing down the engineering teams, if necessary. Building a diverse and confident next generation for quality is essential to building delightful digital experiences for all.

    “I heard from a very famous pioneer in the engineering industry about QA that ‘We don’t have a magic wand; we can’t test quality into your product, but we can test your product.’” Pyhäjärvi said. “The whole concept of QA engineer, QA quality assurance, QE, I think gives people the illusion that we can do something impossible. We can only show light to the areas of the product that need work.”

  • Survey Shows Correlation Between Open Source, DevOps Skills Demand

    Survey Shows Correlation Between Open Source, DevOps Skills Demand

    A survey published this week by the Linux Foundation suggested enterprise IT organizations now prefer to hire IT professionals that have both open source software and DevOps experience.

    Conducted in collaboration with edX, a leading global online learning platform from 2U, Inc., the survey polled 1,672 open source professionals and 559 respondents with responsibility for hiring open source professionals. The results revealed there is also a high correlation between demand for that expertise and familiarity with DevOps.

    In terms of skills most sought, 69% of employers said they are looking for IT professionals that have cloud and container technology expertise followed by Linux (61%) and DevOps/GitOps/DevSecOps expertise (57%). Another 40% are looking for individuals with cybersecurity skills.

    More than three-quarters of the IT professionals (76%) surveyed currently work with Linux (76%), while 60% have worked with cloud/container technologies and 53% have DevOps/GitOps/DevSecOps experience. Well over three-quarters (79%) said it was either very important (44%) or extremely important (35%) to be familiar with DevOps.

    Clyde Seepersad, senior vice president and general manager for training and certifications at the Linux Foundation, said with all things being equal in terms of salary and benefits, more IT professionals preferred to work for organizations that are clearly viewed as open source software leaders. Organizations that want to recruit the best talent should make an effort to be seen as significant contributors to open source software projects to attract the best IT talent.

    Roughly half the respondents currently work for IT vendors, but the rest represented some type of end-user organization that typically consumes open source software. That distribution showed that demand for open source software expertise has now moved well beyond IT vendors that build commercial applications and IT platforms, he noted.

    Overall, the survey found 93% of employers struggling to find enough skilled talent, with nearly half of respondents (46%) planning to hire additional IT professionals with open source software expertise in the next six months. A full 86% said hiring IT professionals with open source software expertise was a priority. Well over two-thirds of employers (69%) said they are more likely to hire an open source professional with a certification. A total of 90% of employers said they will pay for employees to obtain certifications, with 58% reporting that open source IT professionals typically have higher salaries.

    A total of 81% of the open source software professionals surveyed also said they planned to add certifications this year. Nearly three-quarters of them (73%) also noted it would be easy for them to find a new job. About a third of those respondents either left or changed jobs in the last year, the survey revealed. Two-thirds of open source software professionals said a higher salary would deter them from leaving a job.

    More than three-quarters of IT professionals (77%) also noted they would benefit from additional cybersecurity training.

    However, only 43% of employers identified training as a means to close their current skills gaps. Another 41% said they hired consultants to fill these gaps. Only 16% of those respondents said they were willing to delay projects because of a skills gap.

    It’s clear that IT vendors and enterprise IT organizations are, in many ways, competing for the same talent. The challenge enterprise organizations face is making sure they have a high enough profile to be perceived as a place where IT professionals can make a meaningful open source software contribution.

  • Not Everything That is Necessary Adds Value

    Not Everything That is Necessary Adds Value

    Since the Lean production method for manufacturing arose in the 1930s, organizations everywhere have been seeking ways to apply it to reduce waste and increase productivity. This model has served thousands of companies well, from manufacturing and product design to software development. Yet, one difficulty that comes up when discussing or applying Lean in software development is the debate about what is and isn’t considered value-added work.

    Some people get defensive when certain activities are labeled non-value-add (NVA). Others argue that if a customer expects an activity and is willing to pay for it, it must be value-add (VA). From my perspective, software engineers, business leaders and others must accept the reality that it’s entirely possible for necessary processes to add no tangible value. We must understand the intent of Lean within these classifications. In doing so, we can get past the defensiveness and disagreements and move on to improvement.

    Let’s explore a few examples of NVA activities that are unavoidable—and therefore necessary—to a successful software development value stream:

    • Resolving important defects
    • Rework to meet client specifications (i.e. after clarifying requirements)
    • Project time tracking and billing (i.e. for time and materials projects)
    • Complying with regulatory mandates
    • Testing

    Some customers expect these activities to be performed. Software professionals generally agree that all of these NVA activities can be necessary. Yet many Lean proponents will continue to insist that they are NVA and should be minimized. So, where does that leave us?

    Distilling ‘Value’ to Its Essence

    Regardless of how important or necessary NVA activities might be, from a Lean perspective, unless an activity is adding value to the finished product, it is technically an NVA activity. Testing is an NVA activity. Defect correction is an NVA activity. Complying with regulations, although important to protecting profit margins for the company—and an activity that might incent customers to select your product over your competitor’s due to their reduced risk—is nevertheless a NVA activity.

    This is where we enter the grey area of “necessary but NVA activities that actually add a lot of value.” One prominent example is resolving defects that cannot be postponed. You’re probably shaking your head and thinking, “No way. Resolving defects increases quality which makes the finished software product more valuable to the end user. Therefore, it must be a value-add activity.”

    The answer is actually, “No, it is not.” Why? While the cost of defect resolution may be incorporated into the final price tag of software, there is no line-item charge for it. Most purchasers will not pay extra for defect resolution. They’ll feel that quality software is essential to their project and defect resolution should be included.

    Furthermore, they believe quality should be built-in— designed into the product and the process used to build it. That makes it an NVA activity. It’s necessary to the delivery of quality software but it doesn’t add value in the Lean sense of the term.

    The truth, whether or not business leaders want to acknowledge it, is that NVA activities are built into almost every product or service. When someone goes to pick up a prescription at the pharmacy they are never asked to pay an extra research fee. When someone test drives a car and decides to purchase it, they aren’t charged for the gas they burned during the test drive. Both of those activities were necessary for the final outcome to be satisfactory to everyone, but they added no value to the effort.

    The same is true for successful software delivery. Lean approaches form the foundation for modern software development, but being Lean doesn’t mean that you have eliminated all NVA activities. In fact, quite the contrary.

    Lean suggests that perfection is never achieved. A Lean organization values continuous improvement and is always looking for ways to reduce NVA activities. For all software projects, some elements will always be NVA. The perpetual existence of both value-add and non-value-add are facts of life.

    Optimizing Necessary Activities

    Despite the fact that these activities might be necessary and, therefore, part of the project cost, they don’t have to be excessive. Responsible software professionals and the companies for whom they work will make an extra effort to reduce waste and optimize outcomes in all NVA activities.

    Reducing or eliminating waste is one of the most important tenets of Lean software engineering. Waste can be found everywhere, from too many people working on a project and ineffective communication to an excessive number of manual processes, backlog mismanagement and rework.

    Breaking the Stigma of “Non-Value Add”

    Companies must develop quality software and sell it at a price that pays for the effort. In my experience, the way to do that is by evaluating every activity. Consider whether it is VA or NVA and whether it is essential or non-essential. Then reduce or eliminate the NVA as much as possible, even if it’s essential, and optimize the VA.

    Software professionals should be ready to defend the importance of the many necessary but NVA activities that go into a quality outcome, while remaining unapologetic about calling them what they are—a process, procedure or other activity that adds no value.

  • TechStrong Con 2022: Exploring What’s Next in Tech

    TechStrong Con 2022: Exploring What’s Next in Tech

    We have become increasingly reliant on technology and it’s hard to imagine life without all the great tech inventions we use in our daily lives. As technology keeps progressing, more is expected of IT teams, and security is a top priority.

    While we are still trying to get used to the new normal, the IT community continues to shine as a beacon, demonstrating how humans are leveraging technology to overcome the many challenges we face. On June 21, business and tech leaders who are working on transforming the world and moving it forward will come together at TechStrong Con Virtual Summit to celebrate the power of technology, share their stories, provide practical insights and lend valuable advice to help other professionals succeed in their careers. More than a virtual event, it is a community gathering that offers learning, networking and upskilling opportunities. Now in its third year, TechStrong Con continues to serve as a testament to the ways in which technology can improve human existence.

    Things You’ll Learn

    The agenda features a mix of topics including live coding, cloud-native, cybersecurity, digital transformation, observability, DevOps, open source and more. Attendees will have the opportunity to learn from some of the brightest minds in the industry about:

    • Managing the security of APIs
    • Key observability trends for 2022
    • How to accelerate digital transformation
    • Habits that will help improve your security posture
    • The state of the software supply chain post-Log4Shell
    • The distributed cloud
    • The future of data engineering
    • Building a diverse cybersecurity workforce
    • Crypto and NFTs
    • Low code and citizen development
    • The value of feature flags
    • How DevOps must be part of your future to attract the right talent
    • Managing and motivating teams in a hybrid environment

    Meet the Speakers

    The speaker lineup features globally recognized business leaders, DevOps, cybersecurity and IT experts including:

    • Sholmi Ben Haim, co-founder and CEO at JFrog
    • Chenxi Wang, founder and general partner at Rain Capital
    • John Willis, senior director of the global transformation office at Red Hat
    • Caroline Wong, CSO at Cobalt
    • Thomas Krane, principal at Insight Partners
    • Lisa Plaggemier, executive director at National Cyber Security Alliance
    • Tami Mazel Shackar, CEO at Incredibuild
    • Tom Sweet, VP in IT solutions at GM Financials

    Visit the Exhibit Hall

    In addition to the sessions, attendees can visit the virtual exhibit hall to interact with partner sponsors including Chronosphere, ConnectALL, Tidelift and TechStrong Research. The expo hall will be open throughout the event, giving attendees the opportunity to chat with the sponsors and download information at any time.

    Registered attendees will also receive a link to access the virtual environment on-demand. To see the full agenda and to register for free, please visit the TechStrong Con website.

  • Cloud Giants Shun Wind Power? | LaMDA not Sentient? | MS IE RIP?

    Cloud Giants Shun Wind Power? | LaMDA not Sentient? | MS IE RIP?

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Warren Buffett asks too much for wind energy, it’s “completely ridiculous” to say Google’s chatbot LaMDA is sentient, and Microsoft finally kills Internet Explorer. (more…)

  • How to Adopt an SRE Practice (When You’re not Google)

    How to Adopt an SRE Practice (When You’re not Google)

    Site reliability engineering (SRE) isn’t a new term or practice. The practice of applying software engineering skills and principles to operations problems and tasks happened even before site reliability engineer was a defined job title. But organizing a proactive approach to building and maintaining software drives long-term success in improving operational efficiency, data-driven roadmap planning and general uptime and reliability. All these advantages account for the widespread adoption of SRE. 

    In this article, I’ll dive into what it takes to get into site reliability engineering, how to adopt it within your own organization and some of the core principles and best practices you’ll need to keep in mind as you move forward in your SRE maturity journey.

    What is SRE?

    SRE, or site reliability engineering, is the practice of applying software engineering expertise to DevOps and operations problems. Often, this means proactively writing code and developing internal applications or services to combat reliability and performance concerns. SRE has been a practice for many years but has been more recently popularized by Google when they first published Site Reliability Engineering: How Google Runs Production Systems in March 2016.

    SRE is a complicated acronym because it both relates to a job title, site reliability engineer,  as well as a general practice adopted by development and IT teams, site reliability engineering. SRE teams are often organized differently depending on the organization and the services they support. Sometimes site reliability engineers (SREs) are sprinkled among development teams. This means they can vocalize concerns during roadmap planning and work closely with QA teams, collaborating on everything from shipping features to staging to managing production environments. 

    Another approach organizes an SRE team as a standalone group. The SRE team as a whole is focused on responsibilities including monitoring applications and infrastructure, establishing reliability metrics, tracking issues with new releases and handling on-call duties. No matter how they are organized, what remains the same for all these SREs is their initiative—reliability and performance.  

    DevOps Vs. SRE

    The rapid adoption of DevOps practices may have you wondering, “How is SRE different from DevOps?” Commonly, the two terms go hand-in-hand. SRE is a practice that doesn’t necessarily have to be part of DevOps culture and adoption but is often implemented by organizations that are further along in their DevOps journey. The further along on your DevOps maturity model, the more likely you are to have bought into SRE practices.

    The conversation isn’t ‘SRE versus DevOps; the conversation is about establishing a proactive SRE team and operating model to help strengthen your DevOps practice. Whether you choose an SRE framework integrated into your development and IT teams, or you want to make SRE a standalone business unit, you need to understand their general responsibilities.

    SRE Team Responsibilities

    Site reliability engineers are responsible for defining what performant and reliable really mean when you talk about your applications, services and infrastructure. The day-to-day tasks can range anywhere from instrumenting new monitoring solutions to building custom apps for technical support teams. They might ship new code to production to fix bugs or deliver new features, or they might respond to incidents in real-time and work closely with support teams to deliver positive customer experiences.

    At the end of the day, site reliability engineers are the key to understanding exactly how customers experience your product and how to track system performance and reliability through your customers’ eyes. SRE teams need to figure out exactly where service boundaries exist between what development teams ship and what customers experience. From there, they need to find ways to monitor reliability and performance concerns in a way that helps your internal teams proactively identify risks and deliver better software. 

    SRE teams spread knowledge across the product and development teams to consistently define reliability across the entire organization. With everyone on the same page, the engineering teams can make data-driven decisions when it comes to releasing new features or improving current experiences in production. 

    Site Reliability Engineering Principles and Practices

    At a very high level, Google defines the core of SRE principles and practices as an ability to ’embrace risk.’ Site reliability engineers balance the organizational need for constant innovation and delivery of new software with the reliability and performance of production environments. 

    The practice of SRE grows as the adoption of DevOps grows because they both help balance the sometimes opposing needs of the development and operations teams. Site reliability engineers inject processes into the CI/CD and software delivery workflows to improve performance and reliability but they will know when to sacrifice stability for speed. By working closely with DevOps teams to understand critical components of their applications and infrastructure, SREs can also learn the non-critical components.

    Creating transparency across all teams about the health of their applications and systems can help site reliability engineers determine a level of risk they can feel comfortable with. The level of desired service availability and acceptable performance issues that you can reasonably allow will depend on the type of service you support as well. SRE principles and practices embrace experimentation and require a dedication to proactively understanding the health of the services they support.

    An SRE Operating and Maturity Model

    You can perform a lot of the responsibilities asked of a site reliability engineer and still have a software engineer job title. So, how do you know how mature your site reliability engineering practice is? Luckily for you, we’ll lay out a quick way to build an effective SRE operating model and track your maturity against it. An SRE operating model typically includes three elements, which you might achieve in phases:

    1. A team (or at least one person) dedicated to the practice of SRE.
    2. Deep integration and influence across product, development and operations teams.
    3. Autonomy to automate workflows and write code for nearly any part of your application or system.

    Your SRE maturity depends on where your organization falls along these three elements of an SRE operating model. If you’ve taken the steps to make an SRE team or hire your first site reliability engineer, you’re at the beginning of your journey. If you have a team and they are a valued part of roadmap discussions, QA, deployment workflows, incident management processes, then you have a somewhat mature SRE practice. 

    An organization only reaches complete SRE maturity when the SRE business unit has the autonomy to automate workflows, build applications, own monitoring and alerting solutions, or interject themselves into nearly any conversation. Vocalizing performance and reliability concerns upfront and having a proactive discussion about those concerns is always better than simply ignoring them until it’s too late.

    Monitoring, CI/CD and Organizational Automation

    Site reliability engineers can and will automate just about anything and everything. If it can proactively detect, remediate or resolve an issue, it needs to be automated. From continuous integration and delivery practices to production environment monitoring, SREs should have some visibility into all of it. If they can identify ways to proactively uncover performance and reliability issues, then they need to have the authority to implement those changes.

    Today’s DevOps and IT capabilities around automation, monitoring, artificial intelligence and machine learning give SRE teams a huge advantage when identifying issues, responding to them and fixing them. Organizations with mature DevOps and SRE practices can catch problems in staging and they can also build automated incident management workflows and self-correcting systems. By determining critical components in your applications and infrastructure, SREs can narrow down the scope of things that can cause major problems.

    The Practice of Service Levels (SLIs, SLOs and SLAs)

    Service levels come into play to help SRE teams communicate the true health of digital products and services to all stakeholders. This is done by identifying and measuring critical components that are key to delivering positive customer experiences. In particular, they need to know when one or more components expose functionality to external customers. We call these intersection points system boundaries. System boundaries are the place where site reliability engineers need to apply service-level indicators and objectives to their metrics in order to tell the real story of system performance and reliability. 

    • Service-level indicators (SLIs) are the key measurements to determine the availability of a system.
    • Service-level objectives (SLOs) are goals you set for how much availability you expect out of a system.
    • Service-level agreements (SLAs) are the legal contracts that explain what happens if the system doesn’t meet its SLO.

    While SREs aren’t always responsible for managing service levels, it often falls within their purview. By tracking SLIs and tying them to SLOs, you can set goals around the performance of a system. Google’s SRE book defines the four golden signals of service levels as latency, traffic, errors and saturation. So, for example, you could look at an API call and track its number of successful/failed requests (the SLI) against a general percentage of requests that need to be successful for customers to have a good experience (the SLO).

    SRE teams will often set strict SLOs on critical components within their applications and services to better understand how strict of an SLA they can agree to with customers. From here, the team can apply error budgets as a way to understand how quickly they must resolve issues in order to stay compliant with their SLOs. Service levels allow teams to aggregate metrics and create a transparent view of uptime, performance, and reliability across the entire organization. At a glance, business leaders can use service levels to monitor compliance across multiple teams, applications, services, etc. to gain a comprehensive understanding of their system’s health.

    Adopting SRE Best Practices

    Adopting SRE best practices and principles won’t happen overnight. It takes time and effort to proactively monitor your teams and systems for performance and reliability concerns. But, in the end, your DevOps teams and especially your customers will thank you for deciding to take advantage of site reliability engineering.

  • Technical Debt: When It Works and When It Doesn’t

    Technical Debt: When It Works and When It Doesn’t

    Every software team has probably faced technical debt—the accumulation of little development deficiencies that will require rework down the line. Just like financial debt, they accrue interest as they build up, in the form of difficult software modifications or challenges in adding new features. Time is the usual culprit; your development team has one timeframe for creation but your leadership team wants to bring the software to market faster. And when it comes to choosing between building a clean and polished piece of software or hitting that delivery date, you usually need to bow to pressures from on high. It’s at that point that your collaboration might go off track, with little pieces of incomplete code jumping into the mix.

    Without careful monitoring, technical debt will eventually slow down your development and deployment processes, degrade your product quality and limit your ability to innovate in a changing market. But is technical debt unilaterally bad? Not always. Sometimes it’s in service to a greater strategy. Let’s look at the differences.

    When is Debt Part of a Good Strategy?

    Pankaj Gupta, senior director, product marketing at Citrix, said when technical debt impedes an organization’s ability to function, that’s a clear sign they need to wipe out the debt and start with a clean slate.

    “But there are a few scenarios under which it makes sense to let debt accumulate,” he said. “For example, if the cost of addressing a technical debt is significantly higher now than in the future; if the debt is not impacting your immediate and short-term business needs or if you have an emergency release like a major security vulnerability fix.”

    Daniel Viveiros, chief technology officer at CI&T, recommended that teams keep the big picture in mind when making the right tradeoffs. “For me, it’s about putting the business first and understanding that constantly activating value is imperative for success,” he said. “Well-managed technical debt can be an effective tool to shorten the lead time. Deferring refactorings, modernization efforts and other common debts in order to prioritize deployments is a constant tradeoff the engineering teams deal with on a daily basis.”

    What are the Signs of Too Much Technical Debt?

    Gupta provided some warning signs for technical debt overload.  “You know you’re accumulating too much technical debt when the cost and/or time to fix the technical debt is higher than starting fresh,” he said. “And the time taken for each release and deployment is consistently increasing.”

    A less obvious result: a DevOps exodus. The development team will be the first to feel the impact of too much technical debt, such as having a harder time completing tasks and working long hours to fix frequent breakages. “Employees are leaving the company out of frustration from working on legacy systems, spending most of their time fixing ad-hoc issues, routinely missing and being on-call all the time,” Gupta said. What debt reaches that level, resignations begin to mount.

    Viveiros pointed out that compiled debt will impact system resilience: “Bugs are originated more often and the change failure rate goes up. Speed is perceived as risky instead of something beneficial to the digital delivery process.”

    The ultimate sign of too much debt, he said, is poor business performance and lost revenue. “If downtime equals lost opportunities, the technical debt will become a financial debt,” Viveiros said. “Too much technical debt may impact the perceived quality of the product. As a result, the product and brand’s image will suffer.”

    What’s the Best Way to Manage Debt?

    Failure to deal with technical debt means kicking it down the road to another developer to tackle—and no one wants to be that person. So what’s the best way to take control and pay it off? To start, approach it as a collaborative effort and implement these four practices.

    1. Identify the types of debt. Not all technical debt is created equal. Distinguish between the debt you accept in the moment as something to fix later on and the inadvertent debt you discover—and categorize it into code debt, design debt, build debt and other forms to identify origin patterns.
    2. Analyze and automate. Analyze the origins of your debt and look for ways to tighten workflows or automate certain tests and processes. By reducing common errors and hidden bugs, you can stop them from snowballing into technical debt.
    3. Develop new policies and standards. These should clarify when debt makes sense and when it causes unacceptable damage. For instance, an immediate release of a security patch would be deemed acceptable while errors that will eventually cause considerable downtime would not.
    4. Communicate the cost to IT and business leaders. When another hyper-speed deadline comes your way, make sure your leadership understands the risks to product quality and developer retention. With the price tag made clear, they’re more likely to change delivery dates or provide funding for additional developers.

    Like most out-of-control spending, harmful technical debt begins with poor decisions and a certain level of denial. By approaching decisions with greater clarity and foresight on both the Dev and Ops sides of the house, teams can give themselves more breathing room and the space to produce exceptional software.