DevOps, NoOps, NoDev...
While doing some researches in the internet, I found a quite funny article titled "The NoDev revolution has started", the article starts with the following sentence "Developers primary function is wheel reinvention.", followed by some examples. Quite funny, right ?!
Let’s also say, Ops primary function is making the reinvented wheel turning “correctly”.
Ok, I’m doing the same mistake, as almost IT people, which is opposing Dev and Ops.
Because of this generalization, the DevOps practice appeared. Using the same metaphor as earlier, DevOps appeared to have the wheel turning smoothly even during a wheel change, or reinvention. When DevOps becomes mature, we started hearing about "NoOps", "NoDev" and one day "NoDevOps" who knows (maybe it’s already the case).
During decades, we discussed about how to increase productivity and time to market by optimizing development processes, and a lots of initiatives appeared: UP, XP, Agile, Lean, etc. All of them are mainly trying to organize dev and ops teams separately, by putting processes in a day to day project life.
In the last few years, organizations started pointing the need of dev and ops collaboration. The drivers was mainly reduce infrastructure availability, upgrades, deployment process, etc. This was helped by the virtualization, continuous integration, different services (IaaS, PaaS for eg) proposed to project teams, etc.
DevOps, the move...
In a “traditional” management organization, the development teams have their own IT process, ask operation teams at the end or in parallel to prepare the environment, to deliver the package, to do some maintenance, etc. as an outsourced team. With project complexity we have today, not being included from the beginning and during the whole project process, is just time loosing.
The DevOps is the concept behind the collaboration between development and operation. In practice, it tends to include operations in the development project lifecycle. We can talk here about service lifecycle instead of project lifecycle. In a service-oriented world, the project teams are not only responsible of delivering the project to production but also respecting the SLA (Service Level Agreement), maintaining the product, assuring scalability, etc.
The final goal is to have in mind that a service contributors should be embedded in the product construction from the beginning.
NoOps, NoDev, what else ?
Several companies make the choice to move their platforms into the Cloud. In the Cloud several XaaS services can be delivered. Companies have the choice between at least three models: SaaS, PaaS or IaaS.
In IaaS model, ops continue to have tools and plateform maintenance responsibilities. Does it mean that no operational guys are involved in project phase ? The answer is 'No'.
In the case of PaaS, where the ops service is already part of the model, the ops role is quite different in project lifecycle. Can we can talk here about NoOps ? The answer is also 'No' !
In PaaS model, the different platform components are already configured and ready to use, the network is integrated (DMZ, segregation, load balancing...), etc. The main tasls for operation teams, to have the platform ready, are to design the Cloud integrated services, network and security components and delivery process. This means that less ops guys are involved in the product construction, maybe also a different roles, but ops still have a role in the company. The NoOps concept is like a myth, in this context.
With SaaS model in the Cloud, the software is like a black box, delivering a set of functionalities. It's a good deal for small companies or to have a raduced IT sraff. The NoDev concept is applicable, which is coming from the following assumption: "If you're not in the business of IT, stop making IT your business". The issue here, for a particular business needs, which is quite often the case, a company ask for a custom development. In several companies, IT departments develop in-house applications, implement their business needs and maintain applications and infrastructure. For IT decision makers, before going through in-house development, it is relevant to study the existing open source solutions, proprietary software, etc. The effort is focused on primary company business not on IT.
Saber OMRANI
