>>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 today. >>I'm really excited to share with you a kind of a wild idea. A complete re imagining >>of the S DLC >>and I want to be clear, I need your feedback. I want to >>know what you think of this. You can always find me >>on twitter at editing. Emily, >>most of my work centers around devops and I really >>can't overstate what an 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 we all reach for in our everyday work. >>When devops surfaced as an idea in 2000 >>and eight, the tech industry was in a vastly different space. >>AWS was an infancy >>offering. Only a handful >>of services, >>Azure and G C P didn't exist yet. The majority's 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. >>Applications adhered >>to a monolithic architecture, databases were almost exclusively relational >>and serverless wasn't even a concept. Everything from the application to the engineers >>was centralized. >>Our current ecosystem couldn't >>be more different. Software is still hard. Don't get me wrong, >>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 challenging the very >>premises we have accepted as Cannon 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. DeVos has come to mean 5000 different things to 5000 different people. For some, it can be distilled >>to continuous integration and continuous delivery or C I C D. For others, it's >>simply deploying code more frequently, perhaps adding a smattering of tests >>for others. Still its organizational, they've added a platform team, perhaps 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 important is that there isn't a universally accepted >>standard, well what deVOPS is or what it looks like an execution, it's a philosophy more than anything else. >>A framework 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 though, is that an attempted to capture the challenges of the entire >>software development process. It's that broad >>umbrella, that holistic view that I think we need to breathe life into again, The challenge we face >>is that devops isn't >>increasingly outmoded solution to a >>previous problem developers now face >>cultural and technical challenge is far greater than how to more quickly deploy a monolithic application >>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 free platform. Even now, I don't have a crystal ball that would be >>very handy. >>I'm not completely certain with the next decade of tech looks like >>and I can't write this story alone. I need you >>but I have some ideas >>that can get the conversation >>started, I believe to >>build on what was we have to throw away assumptions >>that we've taken for granted all this time in order to move forward. We must first step back. Mhm. The software or systems development life cycle, what we call the S DLC >>has been in use since the 1960s and it's remained more or less the same since before >>color television >>and the touch tone phone >>Over the last 60 or so odd years we've made tweaks, slight adjustments, massaged it. The stages or steps are always a little different >>with agile and devops we sort of looped it into a circle >>and then an infinity loop. >>We've added pretty colors. But the sclc >>is more or less >>the same and it has become an assumption. We don't even think about it anymore, >>universally adopted constructs like the sclc 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 a >>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 or sometimes wine, >>buildings, toilets, >>plumbing, roads, cars, art, computers, everything. The splc is a remnant an artifact of a previous era and I think we should throw it away >>or perhaps more accurately replace >>it, replace it with something that better reflects the actual nature of our work. A linear, single threaded model designed for the manufacturer of material goods cannot possibly capture the distributed >>complexity of modern socio technical systems. >>It just can't. Mhm. >>And these two ideas aren't mutually exclusive that >>the sclc 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. >>No, I don't know about you. I've never had a software project goes smoothly in one >>go, no matter how small, even if I'm the only person working on it and committing directly to master >>Software development >>is chaos. It's a study and entropy and it is not getting any more simple. The model with which we think and talk about software development must capture the multithreaded, non sequential nature of our work. It should embody the roles engineers take on and the considerations they make along the way. It should build on the foundations >>of agile >>and devops and represent the iterative nature of continuous innovation. >>Now when I was thinking about this I was inspired by ideas like extreme programming and the spiral model. Yeah >>I wanted something that would have layers, >>threads, even a way >>of visually representing multiple processes happening in parallel. >>And 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 but I want to give you a moment to have a first impression to absorb >>my idea. >>I call it revolution because well for one it revolves, >>it's circular shape reflects the continuous and iterative nature of our 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 my mission with this is to challenge the status quo. 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 architect. Ng development, >>automating, >>deploying and operating >>intersecting each loop are six >>spokes >>that describe the production considerations every engineer has to consider throughout any engineering work and that's test, >>ability, secure ability, reliability, observe ability, flexibility and scalability. The considerations listed >>are not all >>encompassing. There are of course things not explicitly included. I figured if I put 20 spokes, some of us, including myself, might feel a little overwhelmed. So let's dive into each element in this model, >>we have long used personas as the default way to do divide >>audiences and tailor messages to group people. >>Every company in the world right now is repeating the mantra of developers, developers, developers, but personas have >>always bugged me a bit >>because this approach typically >>either oversimplifies someone's career >>are needlessly complicated. 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 specifically tailor >>messages >>as to call out the difference between a devops engineer and a release engineer or security administrator versus a security engineer. But perhaps most critically, I believe personas are immutable. Mhm. 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 the same persona on that ubiquitous drop down. We all have to choose >>from when registering for an >>event. Probably this one too. I I was a developer and I will always identify as a developer despite doing a ton of work in areas like devops and Ai ops and Deverell >>in my heart. I'm a developer I think about problems from that perspective. First it influences my thinking and my approach. Mhm roles are very different. Roles are temporary, >>inconsistent, >>constantly fluctuating. If I were an actress, the parts I would play would be lengthy and varied but the persona I would identify as would remain an actress and artist >>lesbian. >>Your work isn't confined >>to a single set of skills. It may have been a decade ago but it is 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, >>developer, building out code or fixing a bug >>and on automation engineer, looking at how to improve manual >>processes. We often refer to as soil release engineer, deploying code to different environments or releasing it to customers. >>We're in operations. Engineer, ensuring an application functions >>inconsistent expected ways >>and no matter what role we play. We have to consider a number of issues. >>The first is test ability. All software systems require >>testing to assure architects >>that designs work developers that code works operators, that >>infrastructure is running as expected >>and engineers of all disciplines >>that code changes won't >>bring down the whole system testing >>in its many forms >>is what enables >>systems to be durable and have >>longevity. It's what reassures engineers that changes >>won't impact current functionality. A system without tests >>is a disaster waiting to happen. Which is why test ability >>is first among >>equals at this particular roundtable. Security is everyone's responsibility. But if you understand how to design and execute secure systems, I struggle with this security incidents for the most >>part are high impact, low >>probability events. The really big disasters, the one that 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 >>then goodness because you know that there are >>endless small >>vulnerabilities lurking in our systems. >>Security is something we all know we should dedicate time to but often don't make time for. >>And let's be honest, it's hard and >>complicated >>and a little scary. The cops. The first derivative of deVOPS asked engineers >>to move >>security left this approach. Mint security was a consideration >>early in the process, not something that would block >>release at the last moment. >>This is also the consideration under which I'm putting compliance >>and governance >>well not perfectly aligned. I figure all the things you have to call lawyers for should just live together. >>I'm kidding. But >>in all seriousness, these three concepts >>are really about >>risk management, >>identity, >>data, authorization. It doesn't really matter what specific issue you're speaking about. The question >>is who has access to what, when and how and that is everyone's responsibility at every stage, site, reliability, engineering or SRE is a discipline and job and approach for good reason, it is absolutely >>critical that >>applications and services work as expected. Most 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 through but fidelity and durability, reliability >>is the end result. But resiliency for me is the journey the action engineers >>can take to improve reliability, observe ability is the ability to have insight into an application or >>system. It's the combination of telemetry and monitoring and alerting available to engineers >>and leadership. There's an aspect of observe ability that overlaps with reliability but the purpose of observe ability >>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 observe ability actually >>originates and linear >>dynamic systems. It's defined as how well internal states of a system can be understood based on information about its external outputs when it is critical when companies move systems to the cloud or utilize managed services that 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, are partitioned into small components or classes >>and architected to enable the Now as >>well as the next inflexible systems. Change dependencies are reduced or eliminated. Database schemas, accommodate change well components communicate via a standardized and well documented A. P. I. >>The only thing >>constant in our industry is >>change and every role we play, >>creating flexibility and solutions that can be >>flexible that will grow >>as the applications grow >>is absolutely critical. >>Finally, scalability scalability refers to more than a system's ability to scale for additional >>load. It implies growth >>scalability in the revolution model carries the continuous >>innovation of a team >>and the byproducts of that growth 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 or rely on its services, our colleagues, >>current and future with whom we collaborate and even our future selves. Mhm. >>Software development isn't a straight line, nor is it a perfect loop. >>It isn't ever changing complex dance. >>There are twirls and pivots and difficult spins >>forward and backward engineers move in parallel, creating truly magnificent pieces of art. We need a modern >>model for this modern >>era, and I believe this is just the >>revolution to get us started. Thank you so much for having me. Mm.