Transcript
This transcript was autogenerated. To make changes, submit a PR.
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.