Devops
Publié le 25/03/2022
Extrait du document
Number two is there's also a very very strong need to accelerate collaboration. Developers don't work in silos. They worked together, and I come from the open source world, so I know this is very, very true. Linux wouldn't exist without huge communities of developers coming together and making things work. Even proprietary software like Windows wouldn't exist if developers in house at Microsoft didn't come and work together, and the same is also very true for your software as well. People need to be able to collaborate and collaborate efficiently, and so this brings us to our software delivery paradox. You want to innovate with speed, but you also need to be very, very reliable and you need to be able to do that efficiently, carefully, and make sure that you are not impeding the innovation that you're trying to drive. And we've seen this. This aren't just buzzwords and paradigms that. We've picked our plucked out of thin air. We've actually seen this in companies all around the world. Unicorns that are growing at a very rapid pace using software as their backbone. They are able to ship and experiment faster if they try something and it works. They're able to iterate very quickly, build it rapidly, and release it to their customers. We've also seen that they're leveraging open source for a lot of the stuff that they don't need to rebuild if it's built. Why rebuild it again, right? And open source provides this very strong foundation for you to actually go in, get code and actually use it wherever you want to it to the point where right now I believe the number is at either 90% or greater than 90% of software in the world is running on open source. Your TV's using open source. Your mobile phone is using open source, the Windows version that you're using on your PC has some elements of open source software. It is available across the board. And so if you are a developer and you're wondering, hey, I need to build something rapidly if it's already built, you know why we build it, right? Number three is also or #5 actually is being able to push new code very quickly. Very confidently and very securely. You need to be able to figure out what do you need and how do you get it out there. And most importantly, this ties into our space of collaboration and we'll talk a bit about this when we're going to be talking about CICD source control. And things like that. You also want to measure team metrics right and optimize your processes. You want to know how effective the teams that are working are, and we've seen a lot of these companies being able to not only check how they are doing from a service delivery perspective, but also measure their teams and ensure that people are actually delivering what they're doing or what they claim to be doing. In fact, there's the number on open source, 99% of all codebases include open source and that will lead us to something else which is around open source vulnerabilities and how you can use them. Remember this session is Dev OPS and Dev SEC OPS and so we'll be talking a bit about both sides, so we've spoken about the why of Dev OPS. We know why we need devils. We want to iterate quickly. We want to innovate. We want to be able to define our destiny as companies and get our developers to basically collaborate efficiently. We want them to deliver software quickly, but what is DevOps? Take a couple of people, blindfold them and ask them hey touch an elephant and tell me what you think it is right? And let strict DevOps as this elephant so DevOps it's in the name, its development and operations DevOps. It's a job title, you know Dev OPS engineer. I know a DevOps engineer, it's just a job title. No Dev OPS is automation. DevOps is about making sure your processes are smooth. And quick and fully automated? No, no, let me tell you what DevOps is. DevOps is faster and smaller releases. I used to do sprints and I know agile and I know that DevOps is about faster and smaller releases. Well, you see the thing here is DevOps involves all of these. It takes a lot from each and every one of these bits and pieces, and allows you to choose your own DevOps formula. So don't think as DevOps as just one of these things. It's basically everything it is all of them. It is taking each and everyone being able to automate being able to do faster and smaller releases, being able to drive collaboration amongst your developers. And also in some instances it is a job being a dev OPS engineer and So what is Dev OPS? Let's break it down a bit more right? You want to be able to take everything that you do as an organization and run it faster. Usually when most developers think of DevOps they think of continuous delivery and continuous delivery is just one bit of it, right? So we think of DevOps as the Union of people. Processes and products to enable continuous delivery of value to your end users. Right? Think of that thing, it's people, processes and products. It's not just pure continuous delivery, it's how all these three fit in together. Because you cannot take the people out of the DevOps process, you cannot take the process out of Dev OPS. It's literally name. You cannot take the products that you're building and the products that you're using. Out of the DevOps process, all of these three need to work in harmony and the DevOps process is quite simple. It's actually quite familiar, right? If you're talking about let's breakdown continuous delivery for a bit here. Continuous delivery basically means you are always in a cycle of innovation. You start by planning and tracking. You find out what you need to do and how you want to deliver it. You head into development and you start thinking about hey, how do I build this product and you actually build the product and test it. And then once it's good you deploy the product you release it out into the world and see how is it being taken up by the market. And once that is done you decide hey, let's operate so. Operation here basically means checking it's running on a day to day basis and once you're running it and in this case This is just the users using the application you come down to monitoring and learning what errors are people getting. What feedback are we getting? And then based on that you feed it back into your cycle and that's continuous delivery, but we'll break it down a little more when we talk about the various bits and pieces of DevOps and so. Let's take a look at the three key areas. Of people, processes and products, but I early forgot. Let's talk a bit about Dev SecoPS. So what is Dev Secops? It's basically Dev OPS with a security mindset. And so this means integrating security into your software delivery process and we will be talking about this in a bit, and in fact we call it the shift left strategy and I hope this is left for you as it is for me. But in any case we'll talk about shifting left and I'll be able to show you that in a bit. So let's talk a bit about. People, processes and products. People, these are your developers. These are your IT teams. These are your QA teams. These are the business leaders who are coming up with the solutions that need to be built. These are the people who decide what innovation is going to happen right? And so you need to have #1 A clear set of rules you need to know what does every person do. What is this developer supposed to deliver? Because once you have a role you are able to clearly define. Responsibilities and the good thing with responsibilities is that they're not only measurable. You can actually go in and check and track and see. Are these people doing what they are supposed to do? And the good thing is, if you are clear on your roles and responsibilities, you can then go beyond into building a proper development culture. A culture of innovation, and I think it was a quote from where he said culture eats strategy for breakfast. If you do not have.
«
Good morning ladies and gentlemen and welcome to our first session of
the DevOpS Academy.
I am your host, Lawrence Muthoga and I look after
Microsoft Open source business across Middle Eastern Africa and a
good thing with the open source world is it runs on Dev OPS Dev OPS
is the engine that fuels it and so it's only right that I step in and
share with you why you should care about Dev OPS in this first
session in this series of videos, we're going to be talking about.
Not just why you need DevOps, but some of the tools that you can use
and some of the paradigms that you should keep in mind as you go
forward in your dev OPS journey and hopefully at the end of all this
you'll have gained not only knowledge of why you need DevOps in your
organization, but most importantly how will you get about to doing
it, setting it up, and making sure that you are successful in your
DevOps journey and to kick us off.
I'll be diving into why
You need dev OPS and what is Dev OPS? What is DevOps really? And
hopefully by the end of this session of hours you'll have a very
clear idea of why you need DevOps.
What some companies have been
doing with DevOps, and even how we as Microsoft transformed over time
into a dev OPS beast and we hope you can do that too as well.
OK, so.
Ladies and gents, welcome to our session on Dev(Sec)ops on Azure, so
why Dev (Sec)ops? I've changed it a bit and I'm going to throw in a
little bit of security.
Why because of something we call the shift
left mindset and I'll be touching on that in a bit.
But let's just
start from the beginning.
Why do we need Dev OPS?
Why do we need Dev OPS? OK, so the first thing we know from from
what's happened in the last actually I'd say about 20 years, is that
50% of the largest companies in the world, the Fortune 500 have been
replaced by organizations that use technology as their key driving
force.
This is really critical.
Think about the apps that you
probably use daily.
If you're using something like Uber or Lyft or
Twitter or Netflix.
You are definitely using a company's technology, right? And for them
being able to innovate faster and change faster and deliver their
services faster is what has been really really key to their success.
And so the way that applications, especially software applications,
were built in the past versus how they're being built today has
definitely changed, In the past you'd have these long times to build
an application.
I don't know how many of us remember the waterfall
model, right? You plan you design you build, you test, you take it
to QA.
They test you released to production, and if there's an issue,
it will take nearly eight days to fix that.
And so we're moving from
that into rapid innovation.
A customer has an ask boom, you're there
and you have to deliver.
And so this change is really critical.
It
has changed how not only we as developers approach applications, but
how businesses view innovation.
It's now moved from just innovation to
being Rapid.
Number two is we now have very outside column.
Loosely
coupled apps, right? You're able to bring your own and create your
own environment and the driving force behind.
This has been
containers and Kubernetes and if you are not familiar with
containers, think of them as small portable computing instances.
It's
almost like a virtual machine, but one that you can run virtually
anywhere and that is a really really powerful tool and we've seen.
»
↓↓↓ APERÇU DU DOCUMENT ↓↓↓
