Rethinking the SDLC - GitHub Universe 2021

hi i'm emily freeman i'm the author of devops for dummies and the curator of 97 things every cloud engineer should know i am thrilled to be here with you all and i'm really excited to share a sort of wild idea a complete reimagining of the sdlc now i want to be clear before i even start i need your feedback i want to know what you think you can always find me on twitter at editing emily most of my work centers around devops and i really can't overstate the sheer impact the concept of devops has had on this industry in many ways it built on the foundation of agile to become a default a standard that we all reach for in our everyday work when devops surfaced as an idea in 2008 the tech industry was in a vastly different space aws was an infancy offering only a handful of services azure and gcp didn't exist yet at least not publicly the majority of companies maintained their own infrastructure developers wrote code and relied on sys admins to deploy new code at scheduled intervals sometimes months apart container technology hadn't been invented and applications adhered to a monolithic architecture databases were almost completely relational serverless wasn't even a concept everything from the application to the engineers was centralized our current ecosystem couldn't be more different now don't get me wrong software is still hard it always will be but we continue to find novel solutions to consistently difficult persistent problems now some of these end up being a sort of rebranding of old ideas but others are a unique and clever take to abstracting complexity or automating toil or perhaps most important rethinking even challenging the premises that we have accepted as canon for years if not decades in the years since devops attempted to answer the critical conflict between developers and operations engineers devops has become a catch-all term and there have been a number of derivative works devops has come to mean 5 000 different things to 5 000 different people for some it can be distilled to continuous integration and continuous delivery ci cd for others it's simply deploying code more frequently adding tests security gates for others it's organizational they've added a platform team even a questionably named devops team or have created an engineering structure that focuses on a separation of concerns leaving feature teams to manage the development deployment security and maintenance of their siloed services whatever the interpretation what's really important is there isn't a universally accepted standard of what devops is or what it looks like in execution it's a philosophy more than anything else a framework that people can utilize to configure and customize their specific circumstances to modern development practices the characteristic of devops that i think we can all agree on is that it attempted to capture the challenges of the entire software development process it's that broad umbrella that holistic view that i think we should breathe life into again the challenge we face is that devops is an increasingly outmoded solution to a previous problem developers now face cultural and technical challenges far greater than how to more quickly deploy a monolithic application onto on-premises infrastructure cloud native is the future the next collection of default development decisions and one the devops story can't absorb in its current form i believe the era of devops is waning and in this moment as the sun sets on devops we have a unique opportunity to rethink rebuild even re-platform now i don't have a crystal ball that would be mighty handy i'm not completely certain what the next decade of tech really looks like and i can't write this story alone i need you but i have some ideas that i think can get the conversation started i believe to build on what was we have to throw away the assumptions that we've taken for granted all this time in order to move forward we must first step back the software or systems development life cycle what we call ubiquitously the sdlc has been in use since the 1960s and it's remained more or less the same since before colored television and the touchstone phone over the last 60 years we've made tweaks slight adjustments we've massaged it a little bit the stages or steps are always a little different with agile we've bent it into a circle and devops we made an infinity loop we've added pretty colors but the sdlc has become an assumption we don't even think about it anymore universally adapted constructs like the sdlc have an unspoken permanence they feel as if they have always been and always will be i think the impact of that is even more potent if you were born after the construct was popularized nearly everything around us is a construct a model an artifact of a human idea the chair you're sitting in the desk you work at the mug from which you drink coffee and sometimes wine buildings toilets plumbing roads cars art computers everything the sdlc is a remnant an artifact of a previous era and i think we should throw it away or more accurately replace it replace it with something that better reflects the nature of our work a linear single threaded model designed for the manufacturer of material goods cannot possibly capture the distributed complexity of modern sociotechnical systems it just can't and these two ideas aren't mutually exclusive that the sdlc was industry changing valuable and extraordinarily impactful and that it's time for something new i believe we are strong enough to hold these two ideas at the same time showing respect for the past while envisioning the future i don't know about you i have never had a software project go smoothly in one go no matter how small even if i'm the only person working on it and committing directly to maine like a maverick software development is chaos it's a study in entropy and it's not exactly getting any more simple the model with which we think and talk about software development must capture the multi-threaded non-sequential nature of our work it should embody the roles engineers take on and the considerations they encounter along the way it should build on the foundations of agile and devops and represent the iterative nature of continuous innovation when i was thinking about this and i did think hard on this i was inspired by ideas like extreme programming and the spiral model i wanted something that would have layers threads even a way of visually representing multiple processes happening in parallel what i settled on is the revolution model i believe the visualization of revolution is capable of capturing the pivotal moments of any software scenario and i'm going to dive into all the discrete elements in a moment but i want to give you a moment to have a first impression to really absorb the idea i call it revolution because for one it revolves its circular shape reflects the continuous and iterative nature of our everyday work but also because it is revolutionary i am challenging a 60 year old model that is embedded into our daily language i don't expect gartner to build a magic quadrant around this tomorrow but that would be super cool and you should call me instead my mission in this is to challenge the status quo and to create a model that i think more accurately reflects the complexity of modern cloud native software development the revolution model is constructed of five concentric circles describing the critical roles of software development architecting developing automating deploying and operating intersecting each loop are six spokes that describe the production considerations every engineer must consider throughout any engineering work testability securability reliability observability flexibility and scalability the considerations listed are not all encompassing there are of course things not explicitly included but i figured if i put 20 spokes some of us might get a little overwhelmed myself included so let's dive a little bit deeper we have long used personas as a default way to divide audiences and tailor messages to group people every company in the world right now is repeating a mantra of developers developers developers but personas have always bugged me a bit because the approach typically either oversimplifies someone's career or needlessly complicates it few people fit cleanly and completely into persona based buckets like developers and operations anymore the lines have gotten fuzzy on the other hand i don't think we need to tailor messages so specifically as to call out the difference between a devops engineer or a released engineer certainly not between a security administrator and a security engineer but perhaps most critically i believe personas are immutable a persona is wholly dependent on how someone identifies themselves it's intrinsic not extrinsic their titles may change their jobs may differ but they're probably still selecting that same persona on that ubiquitous drop down we all have to choose from when registering for an event i was a developer i will always identify as a developer despite doing a ton of work in areas like devops and ai ops and devrel in my heart i'm a developer i think about problems from that perspective first it influences my thinking and approach roles are very different roles are temporary inconsistent constantly fluctuating if i were an actress the parts i played would be lengthy and varied but the persona i would identify as would remain an actor an artist your work isn't confined to a single set of skills it may have been a decade ago but not today in any given week or sprint you may play the role of an architect thinking about how to design a feature or service a developer building out code or fixing a bug an automation engineer looking at how to improve the manual processes we often refer to as toil a release engineer deploying code to different environments or releasing it to customers or an operations engineer ensuring an application functions in consistent expected ways and no matter what role we play we have to consider a number of issues the first is testability all software systems require testing to assure architects that designs work developers the code works operators that infrastructure is running as expected and engineers of all disciplines that code changes won't bring down the system testing in its many forms is what enables systems to be durable and have longevity it's what reassures engineers and leadership that any small change won't impact current functionality a system without tests is a disaster waiting to happen which is why testability is first among equals at this particular round table security is everyone's responsibility but few understand how to design and execute secure systems i struggle with this security incidents for the most part are what we call high impact low probability events the really big disasters the ones that end up on the news and get us all free credit reporting for a year they don't happen super frequently and thank goodness because you know that there are endless small vulnerabilities lurking in our systems security is something we know we should dedicate time to but often don't make time for and let's be honest it's hard and complicated and scary dev secops the first derivative of devops asked engineers to move security left this approach meant that security was a consideration early in the process not something that would block a release at the last moment this is also the consideration under which i'm putting compliance and governance while not perfectly aligned i figure all the things that you have to call lawyers about should just live together i'm kidding but in all seriousness these three concepts are really about risk management identity data authorization there's lots of different aspects of it but the question is really who has access to what when and how and that is everybody's responsibility at every stage site reliability engineering what we call sre is a discipline a job an approach for good reason it is absolutely critical that applications and services work as expected for the vast majority of the time that said availability is often mistakenly treated as a synonym for reliability instead it's a single aspect of the concept if a system is available but customer data is inaccurate or out of sync the system is not reliable reliability has five key components availability latency throughput fidelity and durability reliability may be the end result but resiliency for me is the journey the action that engineers can take to improve reliability observability is the ability to have insight into an application or system it's the combination of telemetry monitoring alerting all available to engineers and leadership there's an aspect of observability that overlaps with reliability which is why they're neighbors but the purpose of observability isn't just to maintain a reliable system though that is of course important it is the capacity for engineers working on a system to have visibility into the inner workings of that system the concept of observability actually originates in linear dynamic systems and is defined as how well the internal states of a system can be understood based on information about its external outputs it is critical that when companies move systems to the cloud or utilize managed services they don't lose visibility and confidence in their systems the shared responsibility model of cloud storage compute and managed services require that engineering teams be able to quickly be alerted to identify and remediate issues as they arise flexible systems are capable of adapting to meet the ever-changing needs of the customer and the market segment flexible code bases absorb new code smoothly embody a clean separation of concerns and are partitioned into small components or classes they are architected to enable the now and the next in flexible systems change dependencies are reduced or eliminated databases schemas accommodate change well components communicate via a well-documented and standardized api the only thing constant in our work is change in every role we play creating flexible systems that will grow as applications grow is critical finally scalability scalability refers to more than a system's ability to scale for additional load it implies growth and a system's ability to grow over time scalability in the revolution model carries the continuous innovation of a team and the byproducts of that team within a system for me scalability is the most human of the considerations it requires each of us in our various roles to consider everyone around us our customers who use the system and rely on its services our colleagues current and future with whom we collaborate and even our future selves we have to read that code too software development isn't a straight line nor is it a perfect loop it is an ever changing complex dance there are twirls and pivots and difficult spins forward and backward engineers move in parallel creating i think truly magnificent pieces of art we need a modern model for this modern era and i believe this is just the revolution that will get us started thank you [Music]

Channel: GitHub

Views: 7,385

Keywords: git, github, collaboration, programming, version control, open source, software development, octocat, innersource, enterprise software, github universe, github universe 2021

Id: Z66-us_VDu8

Length: 19min 22sec (1162 seconds)

Published: Thu Oct 28 2021