The Myth of NoOps
SUBSCRIBE TO OUR BLOG
Get our new blogs delivered straight to your inbox.
THANKS FOR SIGNING UP!
We’ll make sure to share the best materials crafted for you!
5 minutes read
The Myth of NoOps
Written by Sarjeel Yusuf
Product Manager @Atlassian
2009 has a special place in the history of software and technology as it is the year that formally saw the birth of DevOps. In June of that year, John Allspaw and Paul Hammond presented their talk, 10 Deploys a Day: Dev and Ops Cooperation at Flicker” at the O’Reilly Velocity conference. Legend has it that Patrick Debois was not physically present at the talk, however, he did see the recording of the presentation. It was this presentation that inspired him to go and coin the word “DevOps”, by hosting the first DevOpsDays in Ghent Belgium in October that year.
Since then the effects of DevOps have been well recorded throughout academia, talks, blogs, and whitepapers across the industry. The whole goal of the concept was to increase velocity while maintaining stability, and those who adopted the culture successfully saw great benefits in achieving this goal.
Since the birth of DevOps, we have seen break-away concepts spring up including topics such as GitOps, AIOps, and ChatOps. Out of all these ‘Ops’ cultures and practices that have come up, the most misunderstood and controversial one is the topic of NoOps. This is because NoOps is often touted as a replacement for DevOps, some going as far as even saying that No Ops would be the death of DevOps.
This purported notion is repeated in various literature pieces and other resources around the web. However, I argue that this can’t be further than the truth. NoOps is not the death of DevOps, but rather the result of continually applying the right DevOps principles in your development teams or organization. That is what this piece aims to illuminate. Disbanding the myth once and for all.
NoOps No What?
In 2011, Mike Gualtieri, now VP and Principal Analyst at Forester Research, coined the term NoOps in his piece “I don’t want DevOps. I want NoOps”. Since then the term NoOps has made itself present in various discussions on the best ways for software teams to collaborate and build software.
The notion here is that the development environment becomes greatly automated to the extent where Ops is no longer needed. Hence the term NoOps. The journey to this state is one that DevOps itself promotes, as automation is one of the key pillars of DevOps. The debate that arises, however, is that will the environment ever be in such a state of automation that development teams will no longer have to interact with operations. Hence the term No-Ops, no operations required.
Adrian Cockcroft, now vice president of cloud architecture strategy at AWS, once wrote “There is no ops organization involved in running our cloud, no need for the developers to interact with ops people to get things done, and less time spent doing ops tasks than developers would spend explaining what needed to be done to someone else”.
This idea may seem frightening at first for those involved in ops. However, these fears arise due to a misinterpretation of the promise of NoOps.
NoOps: An Extension of DevOps
As the notion of NoOps took its rightful place in the world of software development practices, it is often seen as a contender to DevOps. One that may even kill the notion of DevOps. However, that is a misinterpreted notion.
As described, NoOps is the idea that the development environment has achieved a level of automation that no longer warrants the need for developers to interact with operations. This level of automation though is not something that can be achieved immediately. It needs a shifting of cultural practices and introduction and setup of tools to facilitate the automation process.
Reaching this level of automation is the goal of DevOps. To understand this, we must take one step back and remind ourselves of what DevOps is.
DevOps: A combination of tools, practices, and philosophies that allow for increased development velocity while maintaining system stability.
There are various ways in which DevOps aims to achieve the overall goal stated above. However, one of the core pillars is automation. This is not only to increase velocity but also to facilitate the stability of the system. Automation aims to reduce the barrier that arises from the Wall of Confusion idea. This “wall” can be thought of as a barrier between those who want to make a change and those who want stability.
This wall in reality is a gap in communication and understanding. Traditionally, before DevOps, when developers would make a change, it was the responsibility of operation personnel, i.e SRE to make sure that change is incorporated without any disruptions. However, if an incident occurred it would be difficult for those operating the system to understand and resolve the incident as they aren’t the ones who developed the system, but rather are simply running it. This gap in communication and understanding, the Wall of Confusion, can be most effectively torn down when the person on either side of the wall is the same. Hence the combination of Dev and Ops.
The question is, can we ever automate the entire development pipeline to an extent that operations are no longer needed? Theoretically yes, but practically this would never be possible. NoOps is the ideal state that we aim to reach, and even in this state, there is still a need for DevOps.
Long Live DevOps
Now that we have a solid understanding of what DevOps and NoOps mean, we can then begin to comprehend why NoOps is not the kingslayer that it is perceived to be.
The People Factor
The death of operations is inevitable, but so is the death of traditional developers. Many usually believe that DevOps or more extreme concepts such as NoOps would mean the death of operations. However, it would also mean the death of the traditional developer. The entire idea of DevOps is to combine the responsibilities of development and ops as much as possible.
Therefore, the notion of DevOps is leading to the rise of innovative new practices and technologies such as infrastructure as code and incident investigation.
These new methods are aimed at enabling developers and operations personnel to take up roles from the other end of the Wall of Confusion. As a result, not only the traditional ops role is changing but so is the traditional developer role. It’s no longer enough to simply know how to code in Java or use a set of AWS SDKs. Knowing how to set up CI/CD pipelines and spinning up container instances is now seen as a great advantage in developer roles.
DevOps is Continuous Innovation
By further taking into account all the tools and practices being introduced it is noted that the process of achieving automation is a continuous process. The fact that a system with full automation can be set up once and then never be modified again would signal that the development process itself is not innovating and moving with new advancements in the field of software development. Therefore, it can be said that NoOps actually becomes the antitheses of the innovative spirit of the DevOps.
For example, serverless functions are now trending in popularity. As teams and organizations begin to adopt serverless technologies such as AWS Lambda functions, the entire development pipeline news to be overhauled. Software development is no stranger to fast-paced development and innovation. This is even noted in how the idea of DevOps evolves with new technological inductions. GitOps is simply the latest idea of automating development pipelines which arose due to the increasing popularity ibn Kubernetes.
Ops Is Not Always on the Right Side of the Wall
The illustration of the Wall of Confusion shared above paints a very simple idea of how Dev and Ops interact. However, operational and development roles are not defined by the individual job roles, but rather by the nature of work in the development pipeline.
One such example is the segment of debugging, where strong debugging practices contribute towards mitigating incidents in the future. However, developing for the cloud is very different compared to when developing on-prem or local applications where all depending resources such as services and data stores are available locally.
As a result, having observability indicators much earlier in the development pipeline would help with the process of debugging in the cloud. This means surfacing data in the form of logs, metrics traces to understand how developed components interact and affect other areas of the cloud architecture before going to production.
This has given rise to the concept of Remote debugging which is done by connecting the remotely running application with the development environment. Hence being able to replicate metrics similar to what would have been achieved when running in production.
Several third-party tools can be incorporated in carrying out remote debugging. Thundra recently released its debugging capability which leverages the concept of observability. It achieves this using non-intrusive debugging strategies such as non-breaking breakpoints and IDE integration support. Overall the feature allows you to test your cloud apps in both pre-production and production environments, by surfacing the required insights without posing a risk in your actual codebase. Here is a video showing Thundra Sidekick’s capabilities. It’s an effective tool as it greatly promotes the much-needed shift-left culture. You can find out more about Thundra Sidekick here.
Conclusion
NoOps is definitely an attractive notion, one which all teams should work towards as it can be considered the end goal of DevOps practices. However, practically speaking, such an end goal may never be achieved as operations have been seen to be present in multiple areas of the development pipeline and life cycle of the product. Therefore, it is safe to say, that any claims of NoOps being the death of DevOps is definitely a myth that is simply being reiterated by overexcited conversations in the community.
SHARE
×
SUBSCRIBE TO OUR BLOG
Get our new blogs delivered straight to your inbox.
THANKS FOR SIGNING UP!
We’ll make sure to share the best materials crafted for you!
5 minutes read
The Myth of NoOps
Written by Sarjeel Yusuf
Product Manager @Atlassian
2009 has a special place in the history of software and technology as it is the year that formally saw the birth of DevOps. In June of that year, John Allspaw and Paul Hammond presented their talk, 10 Deploys a Day: Dev and Ops Cooperation at Flicker” at the O’Reilly Velocity conference. Legend has it that Patrick Debois was not physically present at the talk, however, he did see the recording of the presentation. It was this presentation that inspired him to go and coin the word “DevOps”, by hosting the first DevOpsDays in Ghent Belgium in October that year.
Since then the effects of DevOps have been well recorded throughout academia, talks, blogs, and whitepapers across the industry. The whole goal of the concept was to increase velocity while maintaining stability, and those who adopted the culture successfully saw great benefits in achieving this goal.
Since the birth of DevOps, we have seen break-away concepts spring up including topics such as GitOps, AIOps, and ChatOps. Out of all these ‘Ops’ cultures and practices that have come up, the most misunderstood and controversial one is the topic of NoOps. This is because NoOps is often touted as a replacement for DevOps, some going as far as even saying that No Ops would be the death of DevOps.
This purported notion is repeated in various literature pieces and other resources around the web. However, I argue that this can’t be further than the truth. NoOps is not the death of DevOps, but rather the result of continually applying the right DevOps principles in your development teams or organization. That is what this piece aims to illuminate. Disbanding the myth once and for all.
NoOps No What?
In 2011, Mike Gualtieri, now VP and Principal Analyst at Forester Research, coined the term NoOps in his piece “I don’t want DevOps. I want NoOps”. Since then the term NoOps has made itself present in various discussions on the best ways for software teams to collaborate and build software.
The notion here is that the development environment becomes greatly automated to the extent where Ops is no longer needed. Hence the term NoOps. The journey to this state is one that DevOps itself promotes, as automation is one of the key pillars of DevOps. The debate that arises, however, is that will the environment ever be in such a state of automation that development teams will no longer have to interact with operations. Hence the term No-Ops, no operations required.
Adrian Cockcroft, now vice president of cloud architecture strategy at AWS, once wrote “There is no ops organization involved in running our cloud, no need for the developers to interact with ops people to get things done, and less time spent doing ops tasks than developers would spend explaining what needed to be done to someone else”.
This idea may seem frightening at first for those involved in ops. However, these fears arise due to a misinterpretation of the promise of NoOps.
NoOps: An Extension of DevOps
As the notion of NoOps took its rightful place in the world of software development practices, it is often seen as a contender to DevOps. One that may even kill the notion of DevOps. However, that is a misinterpreted notion.
As described, NoOps is the idea that the development environment has achieved a level of automation that no longer warrants the need for developers to interact with operations. This level of automation though is not something that can be achieved immediately. It needs a shifting of cultural practices and introduction and setup of tools to facilitate the automation process.
Reaching this level of automation is the goal of DevOps. To understand this, we must take one step back and remind ourselves of what DevOps is.
DevOps: A combination of tools, practices, and philosophies that allow for increased development velocity while maintaining system stability.
There are various ways in which DevOps aims to achieve the overall goal stated above. However, one of the core pillars is automation. This is not only to increase velocity but also to facilitate the stability of the system. Automation aims to reduce the barrier that arises from the Wall of Confusion idea. This “wall” can be thought of as a barrier between those who want to make a change and those who want stability.
This wall in reality is a gap in communication and understanding. Traditionally, before DevOps, when developers would make a change, it was the responsibility of operation personnel, i.e SRE to make sure that change is incorporated without any disruptions. However, if an incident occurred it would be difficult for those operating the system to understand and resolve the incident as they aren’t the ones who developed the system, but rather are simply running it. This gap in communication and understanding, the Wall of Confusion, can be most effectively torn down when the person on either side of the wall is the same. Hence the combination of Dev and Ops.
The question is, can we ever automate the entire development pipeline to an extent that operations are no longer needed? Theoretically yes, but practically this would never be possible. NoOps is the ideal state that we aim to reach, and even in this state, there is still a need for DevOps.
Long Live DevOps
Now that we have a solid understanding of what DevOps and NoOps mean, we can then begin to comprehend why NoOps is not the kingslayer that it is perceived to be.
The People Factor
The death of operations is inevitable, but so is the death of traditional developers. Many usually believe that DevOps or more extreme concepts such as NoOps would mean the death of operations. However, it would also mean the death of the traditional developer. The entire idea of DevOps is to combine the responsibilities of development and ops as much as possible.
Therefore, the notion of DevOps is leading to the rise of innovative new practices and technologies such as infrastructure as code and incident investigation.
These new methods are aimed at enabling developers and operations personnel to take up roles from the other end of the Wall of Confusion. As a result, not only the traditional ops role is changing but so is the traditional developer role. It’s no longer enough to simply know how to code in Java or use a set of AWS SDKs. Knowing how to set up CI/CD pipelines and spinning up container instances is now seen as a great advantage in developer roles.
DevOps is Continuous Innovation
By further taking into account all the tools and practices being introduced it is noted that the process of achieving automation is a continuous process. The fact that a system with full automation can be set up once and then never be modified again would signal that the development process itself is not innovating and moving with new advancements in the field of software development. Therefore, it can be said that NoOps actually becomes the antitheses of the innovative spirit of the DevOps.
For example, serverless functions are now trending in popularity. As teams and organizations begin to adopt serverless technologies such as AWS Lambda functions, the entire development pipeline news to be overhauled. Software development is no stranger to fast-paced development and innovation. This is even noted in how the idea of DevOps evolves with new technological inductions. GitOps is simply the latest idea of automating development pipelines which arose due to the increasing popularity ibn Kubernetes.
Ops Is Not Always on the Right Side of the Wall
The illustration of the Wall of Confusion shared above paints a very simple idea of how Dev and Ops interact. However, operational and development roles are not defined by the individual job roles, but rather by the nature of work in the development pipeline.
One such example is the segment of debugging, where strong debugging practices contribute towards mitigating incidents in the future. However, developing for the cloud is very different compared to when developing on-prem or local applications where all depending resources such as services and data stores are available locally.
As a result, having observability indicators much earlier in the development pipeline would help with the process of debugging in the cloud. This means surfacing data in the form of logs, metrics traces to understand how developed components interact and affect other areas of the cloud architecture before going to production.
This has given rise to the concept of Remote debugging which is done by connecting the remotely running application with the development environment. Hence being able to replicate metrics similar to what would have been achieved when running in production.
Several third-party tools can be incorporated in carrying out remote debugging. Thundra recently released its debugging capability which leverages the concept of observability. It achieves this using non-intrusive debugging strategies such as non-breaking breakpoints and IDE integration support. Overall the feature allows you to test your cloud apps in both pre-production and production environments, by surfacing the required insights without posing a risk in your actual codebase. Here is a video showing Thundra Sidekick’s capabilities. It’s an effective tool as it greatly promotes the much-needed shift-left culture. You can find out more about Thundra Sidekick here.
Conclusion
NoOps is definitely an attractive notion, one which all teams should work towards as it can be considered the end goal of DevOps practices. However, practically speaking, such an end goal may never be achieved as operations have been seen to be present in multiple areas of the development pipeline and life cycle of the product. Therefore, it is safe to say, that any claims of NoOps being the death of DevOps is definitely a myth that is simply being reiterated by overexcited conversations in the community.
SHARE
2009 has a special place in the history of software and technology as it is the year that formally saw the birth of DevOps. In June of that year, John Allspaw and Paul Hammond presented their talk, 10 Deploys a Day: Dev and Ops Cooperation at Flicker” at the O’Reilly Velocity conference. Legend has it that Patrick Debois was not physically present at the talk, however, he did see the recording of the presentation. It was this presentation that inspired him to go and coin the word “DevOps”, by hosting the first DevOpsDays in Ghent Belgium in October that year.
Since then the effects of DevOps have been well recorded throughout academia, talks, blogs, and whitepapers across the industry. The whole goal of the concept was to increase velocity while maintaining stability, and those who adopted the culture successfully saw great benefits in achieving this goal.
Since the birth of DevOps, we have seen break-away concepts spring up including topics such as GitOps, AIOps, and ChatOps. Out of all these ‘Ops’ cultures and practices that have come up, the most misunderstood and controversial one is the topic of NoOps. This is because NoOps is often touted as a replacement for DevOps, some going as far as even saying that No Ops would be the death of DevOps.
This purported notion is repeated in various literature pieces and other resources around the web. However, I argue that this can’t be further than the truth. NoOps is not the death of DevOps, but rather the result of continually applying the right DevOps principles in your development teams or organization. That is what this piece aims to illuminate. Disbanding the myth once and for all.
NoOps No What?
In 2011, Mike Gualtieri, now VP and Principal Analyst at Forester Research, coined the term NoOps in his piece “I don’t want DevOps. I want NoOps”. Since then the term NoOps has made itself present in various discussions on the best ways for software teams to collaborate and build software.
The notion here is that the development environment becomes greatly automated to the extent where Ops is no longer needed. Hence the term NoOps. The journey to this state is one that DevOps itself promotes, as automation is one of the key pillars of DevOps. The debate that arises, however, is that will the environment ever be in such a state of automation that development teams will no longer have to interact with operations. Hence the term No-Ops, no operations required.
Adrian Cockcroft, now vice president of cloud architecture strategy at AWS, once wrote “There is no ops organization involved in running our cloud, no need for the developers to interact with ops people to get things done, and less time spent doing ops tasks than developers would spend explaining what needed to be done to someone else”.
This idea may seem frightening at first for those involved in ops. However, these fears arise due to a misinterpretation of the promise of NoOps.
NoOps: An Extension of DevOps
As the notion of NoOps took its rightful place in the world of software development practices, it is often seen as a contender to DevOps. One that may even kill the notion of DevOps. However, that is a misinterpreted notion.
As described, NoOps is the idea that the development environment has achieved a level of automation that no longer warrants the need for developers to interact with operations. This level of automation though is not something that can be achieved immediately. It needs a shifting of cultural practices and introduction and setup of tools to facilitate the automation process.
Reaching this level of automation is the goal of DevOps. To understand this, we must take one step back and remind ourselves of what DevOps is.
DevOps: A combination of tools, practices, and philosophies that allow for increased development velocity while maintaining system stability.
There are various ways in which DevOps aims to achieve the overall goal stated above. However, one of the core pillars is automation. This is not only to increase velocity but also to facilitate the stability of the system. Automation aims to reduce the barrier that arises from the Wall of Confusion idea. This “wall” can be thought of as a barrier between those who want to make a change and those who want stability.
This wall in reality is a gap in communication and understanding. Traditionally, before DevOps, when developers would make a change, it was the responsibility of operation personnel, i.e SRE to make sure that change is incorporated without any disruptions. However, if an incident occurred it would be difficult for those operating the system to understand and resolve the incident as they aren’t the ones who developed the system, but rather are simply running it. This gap in communication and understanding, the Wall of Confusion, can be most effectively torn down when the person on either side of the wall is the same. Hence the combination of Dev and Ops.
The question is, can we ever automate the entire development pipeline to an extent that operations are no longer needed? Theoretically yes, but practically this would never be possible. NoOps is the ideal state that we aim to reach, and even in this state, there is still a need for DevOps.
Long Live DevOps
Now that we have a solid understanding of what DevOps and NoOps mean, we can then begin to comprehend why NoOps is not the kingslayer that it is perceived to be.
The People Factor
The death of operations is inevitable, but so is the death of traditional developers. Many usually believe that DevOps or more extreme concepts such as NoOps would mean the death of operations. However, it would also mean the death of the traditional developer. The entire idea of DevOps is to combine the responsibilities of development and ops as much as possible.
Therefore, the notion of DevOps is leading to the rise of innovative new practices and technologies such as infrastructure as code and incident investigation.
These new methods are aimed at enabling developers and operations personnel to take up roles from the other end of the Wall of Confusion. As a result, not only the traditional ops role is changing but so is the traditional developer role. It’s no longer enough to simply know how to code in Java or use a set of AWS SDKs. Knowing how to set up CI/CD pipelines and spinning up container instances is now seen as a great advantage in developer roles.
DevOps is Continuous Innovation
By further taking into account all the tools and practices being introduced it is noted that the process of achieving automation is a continuous process. The fact that a system with full automation can be set up once and then never be modified again would signal that the development process itself is not innovating and moving with new advancements in the field of software development. Therefore, it can be said that NoOps actually becomes the antitheses of the innovative spirit of the DevOps.
For example, serverless functions are now trending in popularity. As teams and organizations begin to adopt serverless technologies such as AWS Lambda functions, the entire development pipeline news to be overhauled. Software development is no stranger to fast-paced development and innovation. This is even noted in how the idea of DevOps evolves with new technological inductions. GitOps is simply the latest idea of automating development pipelines which arose due to the increasing popularity ibn Kubernetes.
Ops Is Not Always on the Right Side of the Wall
The illustration of the Wall of Confusion shared above paints a very simple idea of how Dev and Ops interact. However, operational and development roles are not defined by the individual job roles, but rather by the nature of work in the development pipeline.
One such example is the segment of debugging, where strong debugging practices contribute towards mitigating incidents in the future. However, developing for the cloud is very different compared to when developing on-prem or local applications where all depending resources such as services and data stores are available locally.
As a result, having observability indicators much earlier in the development pipeline would help with the process of debugging in the cloud. This means surfacing data in the form of logs, metrics traces to understand how developed components interact and affect other areas of the cloud architecture before going to production.
This has given rise to the concept of Remote debugging which is done by connecting the remotely running application with the development environment. Hence being able to replicate metrics similar to what would have been achieved when running in production.
Several third-party tools can be incorporated in carrying out remote debugging. Thundra recently released its debugging capability which leverages the concept of observability. It achieves this using non-intrusive debugging strategies such as non-breaking breakpoints and IDE integration support. Overall the feature allows you to test your cloud apps in both pre-production and production environments, by surfacing the required insights without posing a risk in your actual codebase. Here is a video showing Thundra Sidekick’s capabilities. It’s an effective tool as it greatly promotes the much-needed shift-left culture. You can find out more about Thundra Sidekick here.
Conclusion
NoOps is definitely an attractive notion, one which all teams should work towards as it can be considered the end goal of DevOps practices. However, practically speaking, such an end goal may never be achieved as operations have been seen to be present in multiple areas of the development pipeline and life cycle of the product. Therefore, it is safe to say, that any claims of NoOps being the death of DevOps is definitely a myth that is simply being reiterated by overexcited conversations in the community.
2009 has a special place in the history of software and technology as it is the year that formally saw the birth of DevOps. In June of that year, John Allspaw and Paul Hammond presented their talk, 10 Deploys a Day: Dev and Ops Cooperation at Flicker” at the O’Reilly Velocity conference. Legend has it that Patrick Debois was not physically present at the talk, however, he did see the recording of the presentation. It was this presentation that inspired him to go and coin the word “DevOps”, by hosting the first DevOpsDays in Ghent Belgium in October that year.
Since then the effects of DevOps have been well recorded throughout academia, talks, blogs, and whitepapers across the industry. The whole goal of the concept was to increase velocity while maintaining stability, and those who adopted the culture successfully saw great benefits in achieving this goal.
Since the birth of DevOps, we have seen break-away concepts spring up including topics such as GitOps, AIOps, and ChatOps. Out of all these ‘Ops’ cultures and practices that have come up, the most misunderstood and controversial one is the topic of NoOps. This is because NoOps is often touted as a replacement for DevOps, some going as far as even saying that No Ops would be the death of DevOps.
This purported notion is repeated in various literature pieces and other resources around the web. However, I argue that this can’t be further than the truth. NoOps is not the death of DevOps, but rather the result of continually applying the right DevOps principles in your development teams or organization. That is what this piece aims to illuminate. Disbanding the myth once and for all.
NoOps No What?
In 2011, Mike Gualtieri, now VP and Principal Analyst at Forester Research, coined the term NoOps in his piece “I don’t want DevOps. I want NoOps”. Since then the term NoOps has made itself present in various discussions on the best ways for software teams to collaborate and build software.
The notion here is that the development environment becomes greatly automated to the extent where Ops is no longer needed. Hence the term NoOps. The journey to this state is one that DevOps itself promotes, as automation is one of the key pillars of DevOps. The debate that arises, however, is that will the environment ever be in such a state of automation that development teams will no longer have to interact with operations. Hence the term No-Ops, no operations required.
Adrian Cockcroft, now vice president of cloud architecture strategy at AWS, once wrote “There is no ops organization involved in running our cloud, no need for the developers to interact with ops people to get things done, and less time spent doing ops tasks than developers would spend explaining what needed to be done to someone else”.
This idea may seem frightening at first for those involved in ops. However, these fears arise due to a misinterpretation of the promise of NoOps.
NoOps: An Extension of DevOps
As the notion of NoOps took its rightful place in the world of software development practices, it is often seen as a contender to DevOps. One that may even kill the notion of DevOps. However, that is a misinterpreted notion.
As described, NoOps is the idea that the development environment has achieved a level of automation that no longer warrants the need for developers to interact with operations. This level of automation though is not something that can be achieved immediately. It needs a shifting of cultural practices and introduction and setup of tools to facilitate the automation process.
Reaching this level of automation is the goal of DevOps. To understand this, we must take one step back and remind ourselves of what DevOps is.
DevOps: A combination of tools, practices, and philosophies that allow for increased development velocity while maintaining system stability.
There are various ways in which DevOps aims to achieve the overall goal stated above. However, one of the core pillars is automation. This is not only to increase velocity but also to facilitate the stability of the system. Automation aims to reduce the barrier that arises from the Wall of Confusion idea. This “wall” can be thought of as a barrier between those who want to make a change and those who want stability.
This wall in reality is a gap in communication and understanding. Traditionally, before DevOps, when developers would make a change, it was the responsibility of operation personnel, i.e SRE to make sure that change is incorporated without any disruptions. However, if an incident occurred it would be difficult for those operating the system to understand and resolve the incident as they aren’t the ones who developed the system, but rather are simply running it. This gap in communication and understanding, the Wall of Confusion, can be most effectively torn down when the person on either side of the wall is the same. Hence the combination of Dev and Ops.
The question is, can we ever automate the entire development pipeline to an extent that operations are no longer needed? Theoretically yes, but practically this would never be possible. NoOps is the ideal state that we aim to reach, and even in this state, there is still a need for DevOps.
Long Live DevOps
Now that we have a solid understanding of what DevOps and NoOps mean, we can then begin to comprehend why NoOps is not the kingslayer that it is perceived to be.
The People Factor
The death of operations is inevitable, but so is the death of traditional developers. Many usually believe that DevOps or more extreme concepts such as NoOps would mean the death of operations. However, it would also mean the death of the traditional developer. The entire idea of DevOps is to combine the responsibilities of development and ops as much as possible.
Therefore, the notion of DevOps is leading to the rise of innovative new practices and technologies such as infrastructure as code and incident investigation.
These new methods are aimed at enabling developers and operations personnel to take up roles from the other end of the Wall of Confusion. As a result, not only the traditional ops role is changing but so is the traditional developer role. It’s no longer enough to simply know how to code in Java or use a set of AWS SDKs. Knowing how to set up CI/CD pipelines and spinning up container instances is now seen as a great advantage in developer roles.
DevOps is Continuous Innovation
By further taking into account all the tools and practices being introduced it is noted that the process of achieving automation is a continuous process. The fact that a system with full automation can be set up once and then never be modified again would signal that the development process itself is not innovating and moving with new advancements in the field of software development. Therefore, it can be said that NoOps actually becomes the antitheses of the innovative spirit of the DevOps.
For example, serverless functions are now trending in popularity. As teams and organizations begin to adopt serverless technologies such as AWS Lambda functions, the entire development pipeline news to be overhauled. Software development is no stranger to fast-paced development and innovation. This is even noted in how the idea of DevOps evolves with new technological inductions. GitOps is simply the latest idea of automating development pipelines which arose due to the increasing popularity ibn Kubernetes.
Ops Is Not Always on the Right Side of the Wall
The illustration of the Wall of Confusion shared above paints a very simple idea of how Dev and Ops interact. However, operational and development roles are not defined by the individual job roles, but rather by the nature of work in the development pipeline.
One such example is the segment of debugging, where strong debugging practices contribute towards mitigating incidents in the future. However, developing for the cloud is very different compared to when developing on-prem or local applications where all depending resources such as services and data stores are available locally.
As a result, having observability indicators much earlier in the development pipeline would help with the process of debugging in the cloud. This means surfacing data in the form of logs, metrics traces to understand how developed components interact and affect other areas of the cloud architecture before going to production.
This has given rise to the concept of Remote debugging which is done by connecting the remotely running application with the development environment. Hence being able to replicate metrics similar to what would have been achieved when running in production.
Several third-party tools can be incorporated in carrying out remote debugging. Thundra recently released its debugging capability which leverages the concept of observability. It achieves this using non-intrusive debugging strategies such as non-breaking breakpoints and IDE integration support. Overall the feature allows you to test your cloud apps in both pre-production and production environments, by surfacing the required insights without posing a risk in your actual codebase. Here is a video showing Thundra Sidekick’s capabilities. It’s an effective tool as it greatly promotes the much-needed shift-left culture. You can find out more about Thundra Sidekick here.
Conclusion
NoOps is definitely an attractive notion, one which all teams should work towards as it can be considered the end goal of DevOps practices. However, practically speaking, such an end goal may never be achieved as operations have been seen to be present in multiple areas of the development pipeline and life cycle of the product. Therefore, it is safe to say, that any claims of NoOps being the death of DevOps is definitely a myth that is simply being reiterated by overexcited conversations in the community.
*** This is a Security Bloggers Network syndicated blog from Thundra blog authored by Sarjeel Yusuf. Read the original post at: https://blog.thundra.io/the-myth-of-noops
