The term “DevOps” has been making waves throughout the IT Industry for a few years now. You hear a lot of stories of organisations and teams attempting to transform to a “DevOps Mindset” and more often than not, they come up short.
The 2 popular software development methodologies are Waterfall and Agile. Waterfall starts with the conception, then follows very structured steps that doesn’t allow you to back track until the change has been deployed. Changes are usually pushed through relatively quickly, but they are usually very large and often come with bugs which means that if you want to fix them, you have to start from the beginning again and wait until the next deployment window. Agile allows you to take an idea, and go back and forth between these steps before a deployment. This means that deployments are usually smaller and more concise, but taken longer to get through.
DevOps uses a lot of the agile methodology, but Agile mainly focuses on the approach between the developer and the end-user. It doesn’t necessarily focus on the end-to-end process of development, hosting, and deploying these changes. That’s where DevOps comes in. Development and Operations.
“DevOps” isn’t a profession – It’s an idea, a concept and a culture. It’s not about a few particular products like Jenkins or Docker or using cloud technology such as AWS and Azure, nor is it about making your developers responsible for managing servers, load balancers or Terraform. DevOps is a combination of all of these things together to ensure that Developers have the platform and the tools they need to get their code changes out faster, better and more reliably.
Yes, it’s great to be able to release enhancements and fixes to software faster and more effective, but a part of the devops culture is relying on a stable and well performing platform where these applications sit.
Large companies like Microsoft, Amazon and Netflix are now able to handle hundreds, maybe even thousands of deployments a day so ensuring that you have built a platform that is able to handle this and ensuring you have the tools in place for when it goes wrong is vitally important. Alerting, performance monitoring and environment self-healing are extremely important when developing a platform for your software and is the highest priority to a DevOps Engineer or SRE (Site-Reliability Engineer). The key areas that play into this are:
Most of these are taken advantage of by using a cloud based environment i.e. scaling instances due to high load or storage space, or created automated testing scripts as part of your Jenkins deployment pipelines. Automation is key in ensuring that all of this is ran as smoothly as possible (and to ensure that no pesky humans get in the way!)
Well, that depends on a multitude of factors. Every organisation or environment is different and the people that work in them will have a different idea about which area to focus on first and will probably come down to which areas need the most work first. Perhaps your release management and communication between teams is already like a well-oiled machine, but infrastructure changes are still being done manually? Getting started on your IaC would be a good start. Start a planning session, and take note of your key bottlenecks or areas with technical debt. You don’t need to to make several changes at once, small practical and well planned changes will make the world of difference and will actually make it even easier to implement further changes down the line.
Perhaps you have no idea where to start and would like a team of talented professionals to do it for you? If that sounds like something that would be of interested, then send us an email here! We’ll be glad to hear from you.