Hi, I'm VA Boyer and I'm a developer advocate at IWS. Hello, I'm VA Boyer and I'm a developer advocate at Amazon Web Services. So today I'll talk about application resilience and we'll look to answer the question, whose job is it? Anyway, thank you for joining. During my recent talks on continuous resilience, I've been asked many thought provoking questions. One of the questions that I keep being asked time and time again is it possible for application resilience and innovation to coexist? So in this session, we'll look at a few features to look to answer this question. So we'll look at. Cultural transformation for digital transformation. And then we'll look at the shared responsibility model in software development. And then lastly, we will look at the technical considerations for shared responsibility. We'll look at how all these points work together to ensure the coexistence of application resilience and innovation. So let's begin. So beyond application resilience, organizations are looking to innovate for their customers. So the questions they ask themselves is, does the pursuit of application resilience not hold back innovation? How do teams organize in order to ensure that there is both application resilience and innovation? And who in the team is responsible for application resilience and who is responsible for applic for innovation? So I talked about continuous resilience and a quick catch up on what continuous resilience is all about. Continuous resilience is when teams move away from a robustness centric approach to instead facing up to the fact that. Applications will fail at some point, and thus embracing failure with an intention to build capabilities that ensure that there's resilience in the applications when they ultimately experience failure. I. Organizations that seek to digitally transform and become tomorrows disruptors are not able to do this without undergoing cultural transformation silos in software development or care. When various roles that contribute towards software development rarely interact or talk to each other, ultimately this results in the absence of teamwork. Silos within a software development lifecycle get in the way of communication and collaboration, thus slowing down innovation and the delivery of business value to customers. It's also worth mentioning that silos can introduce conflicts within roles, which can manifest through statements such as that is not my job, and further compromising a quality product being delivered to the customer. So as teams seek to move out of the silo development approach, communication between teams becomes very important. Communication moves teams towards a shared responsibility model, and it's very important for innovation. So there are tools that teams can explore that support, collaboration and communication. So teams can explore tools that better support collaboration during software development. Tools like GitHub are very popular among developers as they offer collaborative features that make life easier for developers. Features such as code reviews, pool request notifications, and more. Software development projects can be better organized using tools such as Trello, which lets teams organize projects into boards so that teams can have a view of us on the to-do list, what's being worked on and what's done in order to eliminate confusion with project status. So I briefly talked about shared responsibility model in the previous section, and I'll expand on it a little bit more here. Good quality code is only just one of the contributing factors in application resilience, performance efficiency, security and functional suitability go hand in hand with good quality code towards contributing towards your application resilience. If you decide to tackle these contributing factors individually, it's easy to fall back into siloed functions where individual roles within teams are responsible for only some of these contributing factors. I. It's however more beneficial for everyone in the team and ultimately in the organizations to make quality a shared responsibility. This approach reduces development costs and ultimately the customer or the end user benefits from a better product. Now I'm going to paraphrase Eric Madar, who wrote for devops.com, and he said that team members are equally ultimately responsible for application resilience. Outdated organizational structures, however, tend to place responsibilities on a single employee, on a single team, or on a single role. Organizing team structures around products instead of projects will accelerate innovation and increase the quality of work due to increased collaboration that is fostered by this team structure. So now I'm talking about shared responsibility. I'm talking about collaboration, and it's starting to sound like I have gone and started a whole other conversation on a popular term. DevOps. So in the book DevOps for Dummies, author Emily Freeman describes DevOps as a philosophy that is meant to build a culture of trust, a culture of collaboration, and a culture of continuous improvement. So Emily Feather goes on to give a guide on how to design your organization so that you support this collaboration and this continuous improvement. So is the culture of your organization healthy in that the worst of tech culture is avoided with diversity of thought being encouraged? Are your team members empowered to make dec decisions without always consulting management for every decision that they make? So staying with this topic of DevOps a little bit longer, it is worth reiterating that building a common DevOps team or having DevOps forecast members in the team introduces shared responsibility in the team. So over time, several essential practices have emerged when teams are adopting DevOps, and these practices are continuous integration, continuous delivery. Infrastructure is code and monitoring and logging, but we will look at these in a little bit more detail a little bit later. So talking about technical considerations for a shared responsibility. So now that the culture has been addressed, what technical considerations will support this shared responsibility in teams? First we look at distributed architectures and how they can support this shared responsibility. So there is this really insightful books that I read. It's the title of the book is Fundamentals of Software Architecture, where the authors contrast to architecture styles monolithic versus distributed. Monolithic is described as a single deployment unit of all your code, or as distributed is described as involving multiple deployment units that are connected through remote access protocols. An example of a distributed architecture is a microservices architecture. Which is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. It's a way of breaking up a monolithic software into various components that can function separately, that have specific tasks and that communicate with each other through a simple application programming interface known as an API. The second technical consideration that tends to support shared responsibility is continuous integration and delivery. So there's a white paper by AWS that introduces DevOps, and this white paper highlights AWS capabilities that help you accelerate your DevOps journey. And it also talks about services that can help remove the undifferentiated heavy lifting that's associated with DevOps. Adaptation. It expands on these essential practices when adopting DevOps, some of which are already briefly talked about previously. So this white paper highlights AWS capabilities that help you accelerate when you are on your DevOps journey. And I already talked about the services that. Are available that can help you remove all this work that goes with you adopting DevOps. So what are these practices? The first practice is continuous integration. Continuous integration is a software development practice where developers regularly merge their code changes into a central repository, after which automated bills and tests are then run. GitHub Actions is a continuous integration and continuous delivery platform that allows you to automate your, build your test, and your deployment pipeline. It lets you create workflows that build and test every pool request to your repository or deploy, merge pool requests to production. The next practice we'll look at is infrastructure is code. Infrastructure as code is a practice in which infrastructure is provisioned and managed using code and software development techniques such as vision control and continuous integration. So when we talk about infrastructure as code, look at considering tools like Terraform, which lets you automate the provision of your infrastructure, including databases, servers, and firewall policies among others across multiple cloud platforms. If you're looking to get started with Terraform, you will find a link that I will share at the end of this talk that will help you get started with infrastructure as code and terraform. Then we look at monitoring and logging. Monitoring and logging enables organizations to see how application and infrastructure performance impacts the experience of their products and user. Open Telemetry is a collection of tools, collection of APIs and SDKs. Use it to instrument to generate, to collect and to export telemetry data such as metrics, logs, and traces to help you analyze your software's performance and behavior. At the end of this talk, I do link a tutorial that is very helpful if you're looking to get started with open telemetry. Now we will look at communication and collaboration practices are established to bring teams closer and by building workflows and distributing the responsibilities for communications. When we talk about security, security should be a crosscutting consent. Your continuous integration in your continuous delivery pipelines and all related services should be safeguarded and proper access control permissions should be set up. The Open web application security project known as OSP is a foundation that works to improve the security of software. Their programs include community led open source software projects, and they have over 250 local chapters worldwide. The OS Foundation has published a list of top 10 security risks to avoid in order to change the software development culture towards a more secure culture. So to conclude, it seems that the old saying remains true. You cannot keep on doing the same things and expecting different results. Teams will have to evolve in order to ensure innovation for their customers. Teams will have to evolve into a shared responsibility model in order to be better positioned to work towards application resilience. So to end, I asked you a few questions that I want to leave you with. Do you still have siloed functions as part of a software development cycle? Another question I would ask you is, are you in the process of transitioning from siloed functions to a shared responsibility team? And I'd also ask you, have you fully transitioned to a shared responsibility team? With that, I thank you very much and if you scan that QR code, you will access a link where you will find my LinkedIn. Please do connect and also you'll find all the links that I've been talking about throughout this talk. Thank you.