The past
For people who aren't familiar with the area
let me explain: The average speed of a non-commercial internet
connection was around 5Mb/s on a good day. The number of connected
devices was close to zero unless of course, you've counted the PC that
you've accidentally left switched on.
From a
Software development perspective, there used to be at least 3 completely
distinctive teams fulfilling different functions to get some new
functionality to the customer. A team of developers, testers and
operations people; often separated not only by dividers but by rooms and
in some cases buildings. In a generic product development life-cycle
the developers had a set amount of time - let's say 3 months - to
implement some new functionality and fix any bugs that got brought into
the "release". During their work, there would be regular demos
no one else would see a working prototype of the product. Towards the
end of the development, one of the developers would be nominated to
follow the rigorous release process to compile the build ready for
"release" to the test team.
With the "final" build in hand, the test team would be ready to install and test for about a third of that time the developers spent on it. In an ideal world, the test team would then sign off the release following a successful test cycle (that included a level of regression testing). It would be at this stage when the test team would
Firstly the operations team would read through the detailed upgrade manual
vague release notes and request an upgrade time slot from the customer.
Once they had an upgrade window allocated for X hours they would carry out the instructions and complete ahead of time
nervously attempt the impossible challenge and with sweat and tears,
they would finish a few hours past the deadline, causing an unexpected
production outage.
Evolution
With the popularity of micro-service architectures and non-monolithic development came the big push for companies to release software quicker and with more confidence and less human error. Several pieces had to be in place to achieve the impossible; such as fully automated software testing, automated software builds and automated software delivery.
The aim was to do all of these in a quick and repeatable fashion in a "continuous" way. There was also a people aspect to all of this which meant that it made sense to create a team that was responsible for the software release from start to finish. The need to diversify people inside this team was also quite big, which led to a multi-disciplined team structure. And to add to the mix it was the idea to keep this team together for the duration of the project or at least the development life-cycle.
Having put most things in place it was then a question of further evolution to shorten downtimes using methods such as green/blue deployments, early access to features for privileged beta tester groups, feature toggles, and the eventual realisation that trunk-based development is far easier and cost-effective to maintain.
It all kinda makes sense in today's perspective, but it was a relatively long road for organisations and individuals to come to terms with Continuous Integration, Continuous Delivery and Continuous Deployment.
How does Dev(Sec)Ops fit in the picture?
As the abbreviation suggests it's Development, Security and Operations. Combining those different speciality areas under one hat.
With the evolution of the multi-disciplined teams and the use of cloud providers such as AWS and Azure, there was a sudden need for people who were able to fulfil multiple roles and in the lack of another name people started referring to it as DevOps or DevSecOps.
However, we have to make it clear that DevOps is not a role or a job title. It's a culture, that focuses on enabling the development team (or even a whole organisation) of being completely self-sufficient. The DevOps culture promotes all the building blocks (security, infrastructure, monitoring, planning for failure, performance, disaster recovery) of a successful software delivery team and it does that by leading by example.
The future
We can't predict the future, but as you can see the need is always to do things quicker, with less effort and to do that we going to see other trends emerging. There are still a lot of organisations that need assistance in improving their processes. Some companies are only just beginning their Agile transformation and we have helped many of them through it, both from a technical and a process point of view. If you or your organisation needs any assistance with agile coaching, automation or software delivery please don't hesitate to send us a message.