Everyone talks about agility, automation and DevOps. We are setting up agile teams, trainings, as well as automation and DevOps teams and trainings. But how can we get the best out of DevOps? And how do we get there?
So, lets begin in the "old" world...
The Dev-team was doing his job and the Ops-team did the same. Mostly both were also kind of fighting against each other, the Dev-team wanted things to be easier and the Ops-team wanted standards, security, proper testing and a lot of other things that have taken a lot of time before we were able to accomplish a software delivery to the customer (if internal or external).
Was this bad? NO. You may ask why I say "NO" here...
Because the people in the Dev-team exactly knew what they do and on the other side, the people of the Ops-team also knew what they do, why and both of them did their jobs excellent. Just a delivery of a software took a much longer time than a company or a customer wanted it to take. Also the developers wanted to deliver their software faster.
So we begin to leverage the power of agility with things like Scrum and regular releases (so called sprints) which might include features and/or fixes. Also some teams are setting up additional pipelines for hot fixes as their sprints are planned for a longer timeframe than it should be for a fix release.
After all, we still need to be able to deliver the power of the agile Dev-teams to the customers now, but the Ops-teams are blocking us. So what do we do?
We setup so called DevOps-teams!
DevOps-teams are mostly built from developers that have some operation know-how and people from operations that have some development know-how. In addition, we place frameworks like Puppet, Chef and Ansible to leverage the power of automation, that we hope to achieve by setting up the new DevOps-teams.
Now the big question: Why isn't that what we really want?
Because we will lose the power of the operations people and also we will lose some power of the developers. So what would be possible solutions?
Basically there is only one:
So what does this solution show and why is it different from the most implementations that I have seen in the last years?
It shows dedicated Dev-teams, dedicated DevOps-teams and dedicated Ops-teams. So every team has specialists for actions like developing software, developing automation for the software developer scenarios as well as automation of operational scenarios and the still needed operational scenarios which will never get lost totally, just moved from one part to the other as well as we will need less people to work on that (as you see in the image above which shows a smaller Ops-team than DevOps- and Dev-teams).
Due to we are heading cloudy times, mostly companies which have developer teams to develop software they sell, will mostly buy services which are brought to them by companies that mostly only have DevOps- and Ops-teams. So they just need to partly implement a DevOps-team in addition to their Dev-team(s).
At the end, we end in outsourcing the former Ops-teams to other companies and buy the operations as a service in the cloud as well as we set up teams to work with the offerings of those companies which will be DevOps-teams. Those teams connect the output of the Dev-teams directly with the service of the DevOps-teams at the cloud supplier.
In common we safe a lot of money leveraging the best out of every world and come up with solutions were we even can have weekly (or probably daily) deliveries to our customers. Since also the development of the cloud companies and our software is pretty interesting, I will try to follow up with articles on those topics hopefully in the near future.
All comments are very welcome!
So, lets begin in the "old" world...
The Dev-team was doing his job and the Ops-team did the same. Mostly both were also kind of fighting against each other, the Dev-team wanted things to be easier and the Ops-team wanted standards, security, proper testing and a lot of other things that have taken a lot of time before we were able to accomplish a software delivery to the customer (if internal or external).
Was this bad? NO. You may ask why I say "NO" here...
Because the people in the Dev-team exactly knew what they do and on the other side, the people of the Ops-team also knew what they do, why and both of them did their jobs excellent. Just a delivery of a software took a much longer time than a company or a customer wanted it to take. Also the developers wanted to deliver their software faster.
So we begin to leverage the power of agility with things like Scrum and regular releases (so called sprints) which might include features and/or fixes. Also some teams are setting up additional pipelines for hot fixes as their sprints are planned for a longer timeframe than it should be for a fix release.
After all, we still need to be able to deliver the power of the agile Dev-teams to the customers now, but the Ops-teams are blocking us. So what do we do?
We setup so called DevOps-teams!
DevOps-teams are mostly built from developers that have some operation know-how and people from operations that have some development know-how. In addition, we place frameworks like Puppet, Chef and Ansible to leverage the power of automation, that we hope to achieve by setting up the new DevOps-teams.
Now the big question: Why isn't that what we really want?
Because we will lose the power of the operations people and also we will lose some power of the developers. So what would be possible solutions?
Basically there is only one:
So what does this solution show and why is it different from the most implementations that I have seen in the last years?
It shows dedicated Dev-teams, dedicated DevOps-teams and dedicated Ops-teams. So every team has specialists for actions like developing software, developing automation for the software developer scenarios as well as automation of operational scenarios and the still needed operational scenarios which will never get lost totally, just moved from one part to the other as well as we will need less people to work on that (as you see in the image above which shows a smaller Ops-team than DevOps- and Dev-teams).
Due to we are heading cloudy times, mostly companies which have developer teams to develop software they sell, will mostly buy services which are brought to them by companies that mostly only have DevOps- and Ops-teams. So they just need to partly implement a DevOps-team in addition to their Dev-team(s).
At the end, we end in outsourcing the former Ops-teams to other companies and buy the operations as a service in the cloud as well as we set up teams to work with the offerings of those companies which will be DevOps-teams. Those teams connect the output of the Dev-teams directly with the service of the DevOps-teams at the cloud supplier.
In common we safe a lot of money leveraging the best out of every world and come up with solutions were we even can have weekly (or probably daily) deliveries to our customers. Since also the development of the cloud companies and our software is pretty interesting, I will try to follow up with articles on those topics hopefully in the near future.
All comments are very welcome!
- SAP Managed Tags: