I Don't Want DevOps. I Want NoOps.

DevOps is a term used to describe better communication and collaboration between application development professionals and infrastructure operations professionals. "Dev"+"Ops"="DevOps." The goal of DevOps to make the process of deploying applications faster and smoother. DevOps is a loosely defined set of emerging practices to get developers and operations pros to work together. Developers and operations professionals are often at odds. Developers want to release software more frequently; operations professionals want to protect the stability of the infrastructure. I applaud the goal of DevOps to improve the process of deploying application releases.

"No"+"Ops"= "NoOps"

The last thing many application developers want to do is have a sit-down with the ops guys. Besides which, they don't understand. Sure, the ops guys efforts are critical to our applications because they have to run on something. But, developers should look to spend more of their time getting closer to the business, not getting closer to the hardware. I fully acknowledge that there is a need for quicker and less-rickety deployment processes. But, I think DevOps is a step backward. Instead I propose NoOps. The goal of NoOps is also to improve the process of deploying applications. But, NoOps means that application developers will never have to speak with an operations professional again. NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them. Of course, this is not just about getting virtual machine instances. It is also about release management. Ops can run this public, private, or hybrid infrastructure and give developers the tools they need to responsibly deploy applications faster.


The cloud and IaaS does not solve deployment problems

Hi Mike,

An interesting point of view to say the least. My main concern is your claim that cloud, IaaS, PaaS are technologies that will almost eliminate the current release and deployment issues that we experience today. I have a different opinion that was recently document in a whitepaper "Does The Cloud Simplify Application Release Deployment?" - http://www.noliosoft.com/resources/paper/cloud-deployment

Would love to get feedback.


Heroku, CloudBees, and ElasticBeanstalk...

...are all examples of NoOps. However, we must look at the type of applications that fit the NoOps boundaries and the organizations that support that process. I think a deeper look will reveal that NoOps and DevOps are still in play, just in different organizations with enterprises (the guys with Ops) leading the latter.

A different angle

As an IT Operations professional, I think it's critical that Ops thinks more like Dev. Infrastructure as Code is a movement that helps us to dig into how to measure and automate more of the infrastructure. Improving predictability and flexibility in our services. I don't think Ops is about hardware any more. It's about how we support our services. Maybe we will all end up working for 3 cloud providers someday, but I expect we can do more to add value to our enterprises by challenging both dev and ops to move toward the customer, rather than away from each other. If all your Ops team is doing is racking gear and taking tickets, then they need to wake up to the new challenges.


but, still I think there's a need to automate towards self-service. To your point about "services" it would be nice, if as a developer, I could requisition resources to build and test, without human intervention (all pre-Ops in the current thinking of the definition). The objective is to grow quality software right? The more that I can engage "real" tests before and after QA intervention/UAT the better the DevOps relationship will appear like NoOps.


Infrastructure as Code would be right up the "self serve" alley for dev, I think. My point is that Dev and Ops aren't night and day. It makes no more sense to say NoOps than it would to say NoDev. Since I can just download nearly any module I want for my CMS, for example, should I suggest a NoDev future in the Enterprise where I build/buy robust infrastructures and install the lego's of software I want and configure it for my needs? Then the Dev's can all go work for 3 global dev companies while the Ops people go work for Google and Amazon? Everyone else is just a self serve consumer of technology? I think it is in the combining of teams/skills to make a stronger overall IT team that knows the business and uses tech to meet needs.


I like it...it really is the holy grail of the software world. We're actually getting closer - I'd say most software developers are really just software integrators. There are many modeling and language environments that are pushing code-generation to a point where Dev is indeed as out-dated as Ops.

Don't get me wrong I agree, the reality is that there is a good mix of skills required for service/product-based engineering. Agile practices will also help this, by bringing both QA and Ops closer to the deliverable early on.

But, I think the focus needs to be on the product/service (and thus the customer/end-user), not the developers or operations folks. Automation is required to ensure higher quality, and faster deliveries. Sensitivity to one side or the other only contributes to the original problem wouldn't you agree?


Well said. Agile = good. Mix those skills! Right on about the business/customer is the focus, not our precious fiefdom's in IT.

There's also an OSS connection here

As developers become integrators things like per processor licenses and core counts become the sticking point - especially if you buy James Staten's cloud economics model, where scaling down is as important as scaling up. If you do model based deployment (or config specs, or whatever you want to call them) and devs are doing assembly of OSS infrastructure components you get to a point where the release management cycle starts to look less like a Rube Goldberg contraption and more like a well-oiled machine, with relatively few manual checkpoints. And that allows both developers and ops to focus on the needs of the business.

You could call it BT.

I don't think I could

I don't think I could disagree with you more. One of the problems with current CS courses around the country is no longer are software engineers learning about hardware. Because of this, they think they can do whatever they want in the jvm or whatever with no worries whatsoever. What happens is they don't get why that nested loop runs so slow, or why they are leaking memory everywhere. I think the same can be said for working in the real world and knowing about operations. Yes, as a Software Engineer, you can get by without knowing anything about operations or hardware, but I propose that no GREAT software engineer can do that. Knowing what you are working with really helps you design the system in a way that is harmonious with your hardware. Do you not think it is useful information to a Software Engineer if you tell them that CPU is not a worry, but disk access is horrendously slow (or vice versa)? Tradeoffs like that are why there are different data structures in the world honestly, otherwise there wouldn't be a need for AVL Trees, B* Trees, Red/Black Trees etc.

That's my take,

Software developers should know about hardware

Jared, Thanks for your comments. I actually really agree with you that developers need to understand computer architecture. I started my software engineer career writing 8080 and Z80 code for the Wang operating system. It was glory days when we got a hardware upgrade from 32MB to 64MB. The things we would now be able to do with 64MB. Knowledge of computer architecture is still important for many types of software engineers.

DevOps is not really about whether or not software developers understand hardware. Instead it is about having a pow wow with operations professionals to smooth out the process of deploying apps.

My comment that developers should get closer to the business and less close to the hardware really means the operational side of running an IT infrastructure. But, I agree understanding is important. They are going to learn that from ops profesisonals and sadly, I think you are right that they don't learn it at university.

But not all developers need to know about the hardware.

I agree that there are a small number of developers that need to know about the guts of the systems we deploy to. I also think it's just as important that there are some developers that need to know all about human factors so they can design a great UI. We've reached a point where you have to specialize at some level of the digital infrastructure. If the folks who know all about the hardware are working on VMs and operating systems and they give the folks working on good UIs and e-commerce systems cues on what to do and what not to do, then that seems like an adequate solution...

Doesn't it?

What's devops about?

Devops is about getting dev and ops to work closer to better support the business. Code that isn't released has no value and is not supporting the business in any way, so one of the main focus is to work on the deployment process to get the code out. Operation today is not about hardware, we are a start-up utilizing IaaS and PaaS and the ops guys has never touched a hardware (with exception for their laptops). Still we need ops guys as we are developing a system with many components, and those components need to be configured, monitored, deployed etc. The main focus for operation is to ensure that our service is up and running 24 hours a day and 7 days a week and that all different internal and external components and services are deployed as smoothly and often as needed (at least a new version once a week).

I think if the software is so simple that you just can relay on one service then you could probably by the function as SaaS and then there are no need for developers either.

But maybe ops are becoming devs as Infrastructure as code is the way to work which means that most of their time our ops guys are actually writing code.

I also agree that everyone has to know and understand that the software will even in the cloud run on physical machine and the limitation of those (and there are even more limitations in a virtual environment)

There is a great book about Continuous Delivery how to get the process up and running - see http://continuousdelivery.com/2010/02/continuous-delivery/

I agree with you wholeheartedly!

Good post - and I second the recommendation on Jez's book. In fact I referenced it a few times in my most recent research on release management.

Operations is not just about infrastructure

Hi Mike, thanks for this article, it's an interesting take on the subject. "NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them." - that seems a bit of a stretch. Improving automation such that operations is not a bottleneck is certainly a laudable goal, but it works the same for everybody else too. As it's been mentioned in another comment, then why not NoDev? Also I find the following statement to be a smell: "The last thing many application developers want to do is have a sit-down with the ops guys.". If as an engineer you're not prepared to sit down with another engineer from a different department to get his/her insight of the problem you're likely to be setting yourself up for failure, which is exactly where the devops movement comes in.
Also, operations is not just about providing the infrastructure an application will run on, it's about a set of skills, and more importantly knowledge, that developers can benefit from. In the very same way operations within the infrastructure-as-code effort can learn a lot from developers. Replacing either with automation seems to detract from their value and weaken the overall business.

Better Ops

Too much Enterprise Dev and Ops today is still built in the craftsman mode. Individually crafted, hand assembled, complex to tune systems that require Ops and Dev care & feeding to work correctly. Moving towards automated PaaS and IaaS helps provide a standardized, utility-like platform to deploy apps on to - so that Dev can just keep making new apps and hopefully provide more business value.

It's the difference between a Formula One car and your Honda. To push the Formula One car and get the best performance you need a highly skilled team of mechanics, real-time monitoring, and the best Ops team you can get. To drive your standardized Honda you don't - just use it. As long as you're not pushing the envelope and you can afford to drop your car off for service from time to time you don't need a dedicated team of Ops. Your "Dev" Driver can just use the car and not worry about.

If you want to push the envelope, if you want 24/7, no downtime, releases without bringing the system down, then you need to design for rolling releases and no-downtime architectures that allow multiple versions of the software to be executing in parallel, messages from old and new versions to be flowing at the same time, data structures to be upgraded "on the fly" etc. And ensure that all configurations are configurable w/o a release. And ensure that all management, monitoring, logging, and configuration can be exposed in an easy to use dashboard. And, stay up to date on the latest recommendations from the platform providers to ensure your application performs well.

And you still need to think about the impact to customers to rolling out a new version at a given time and whether any external partners need to be notified or integrations re-tested. These are the roles that Ops should do to bring business value - not installation and management of commodity servers and hardware.

Formula One versus Honda

David, You have brought reality to the argument. I agree with you that some types of apps really require that Formula One fine tuning. Most can get from point A to point B in a Honda (I drive an Accord) without the one-of-a-kind fine tuning. I think that IaaS and elastic architectures reduce the need for the hardware/software fine tuning. Thank you for bringing this perspective to the DevOps/NoOps argument.

DevOps isn't just about deployment

Thinking that the value in dev and ops cooperation only lies in application deployment is missing the largest piece of the picture. It's not just about deployment, it's about working out infrastructure requirements, fault tolerance design, resiliency efforts, etc. I posted a while back about this: http://www.kitchensoap.com/2009/12/12/devops-cooperation-doesnt-just-hap...

The companies that are only considering the deployment pipeline for dev and ops collaboration are missing out. Getting tight on things like incident and outage response, business-to-infrastructure metrics collecting, etc. is really where things get interesting. Domain expertise in the two camps compliment each other, they are not divergent.

I'd also point out that "Ops" != "Provisioning and Deployment".... and I'd hate to work at a company where that was the assumption. :)

Then DevOps is no different from software architecture

Then DevOps should be called software architecture. I agree that user experience, availability, performance, scalability, adaptability, security, and economy are all important to software design, dev, and deployment. It is software architecture. I agree that firms must have incident response. That is called Ops. So what is the point of DevOps.

I think NoOps is a better goal because cloud computing requires software developers and architects to design for availability, performance, scalability, etc... IN fact, if you drill-down on what I say availability is it includes: fault tolerance, monitored, and fixable. I think we are in agreement that software architecture, deployment, and ops is important, but I think DevOps is the wrong direction to take because cloud computing will make infrastrcuture a utility. You will still need monitoring, incident response etc... but that must be built into the software and move on to other cloud resources if something bad happens.

See my post on the Seven Qualities Of Software Architecture http://blogs.forrester.com/mike_gualtieri/11-02-11-the_seven_qualities_o...

"Then DevOps should be called

"Then DevOps should be called software architecture. " <- you're almost getting it, then. :)

Good luck with the predicting the NoOps trend.

NoOps will happen because it is ideal and possible

Would you agree that NoOps is desirable? It seems that your argument may be that it is not possible. If yes, that's fair. But, I believe that NoOps is a sure thing because of cloud computing.

Scope and Scale...

I definitely think NoOps is a reality...and is currently being manifested (e.g. Heroku, CloudFormations and similar services for different frameworks).

The real question is whether or not NoOps is a reality for any service/application of greater complexity.

Ultimately this leads back to software architectures, as architects begin to design systems that break down the system complexity into systems-of-systems architecture and begin to take advantage of different features/functions as a evolutionary growth (don't build it until you need it, then just add it as a new application to the system). This new world still requires operational knowledge and skills, they are just moved to the left in the lifecycle continuum.

Just a bit of misunderstanding....

Is NoOps desirable? Sure, in the same way that unassisted human flight is desirable.

I do not believe that NoOps is possible for how you are defining it. Not for applications that have a modicum of complexity, anyway. Why? Because to think that cloud (or even fully-automated on-premise infrastructure) rids one of operational and architectural responsibilities is a fallacy. It's ok, you just have some definition adjustments to deploy.

I think there's a mismatch in your definitions of roles and responsibilities inherent with "ops" and "dev". For example, these are just some of the things that I'm (and my peers in my field) look for when hiring Ops engineers: http://www.kitchensoap.com/2010/05/26/some-webops-interview-questions/

It's difficult to discuss this in a blog comment, because your perspective and definitions seems so wildly different than what I see (and have known) in the community that you're commenting on. My community = web operations. See the Velocity and Surge conferences, and you'll get the idea of where my tribe comes from.

Give Theo Schlossnagle's chapter a read in the book I edited for O'Reilly, "Web Operations", and you'll get some more detail about what operations is about, at scale. Take some time to read the Operations parts of Jez Humble's "Continuous Delivery" to help inform your definitions as well. Throw in most of Cal Henderson's "Building Scalable Websites" and Theo's "Scalable Internet Architectures", and you'll get even more of an idea. Michael Nygard also outlines in his book "Release It!" excellent outlines for where development/architecture/operations intermingle for production.

Some final thoughts:

1. There will *always* be engineers on the 'sharp end' of applications and infrastructure. Which is to say, work that is classified in my tribe as "operations". Some of the best code and infrastructure design I've seen have come from Ops engineers.

Smart engineers, with different titles, dealing with the capacity planning (yes, that happens in the cloud, too: please look at Reese's "Cloud Application Architectures" to understand how and why), monitoring and metrics collection (hint: they're different), outage response, fault tolerance, etc. My definition involves Ops for these pieces, for so many reasons I can't list here in a post. The cloud doesn't rid anyone of Operations. It might rid them of racking and stacking servers, but not Operations (they are not the same)

Please see: http://www.kitchensoap.com/2009/05/22/annoying-to-me/. Automation and the cloud don't get anyone off the hook for thinking about infrastructure. If anything, it amplifies it - because it allows folks to think about the real problems at hand. Provisioning simplifies with the cloud, and Ops doesn't go away.

If you have people thinking about, planning for, and building to support these concepts, then they are doing Operations work. Operations do *not* just rack, install, and cable up servers. See above blog post.

2. I suspect that you and I are not in the same business, hence the differences in perspective. What convinces me of trends (organizational or otherwise) is working and resilient code, on production and resilient infrastructure, cloud or not. The concepts and ideas normally represented in the cultural movement known as DevOps is evident in the organizational, technical, and cultural trends at Etsy, Flickr, Facebook, Google, Amazon, Yahoo, and many others who are, whether they call DevOps or not.

3. I'm quite convinced that the friction you're seeing with this post (on twitter, and elsewhere) should help illuminate where you could adjust your theories and predictions. :)

For further help with any of the definitions (I really do think that this is the root of your misunderstanding) please see any presentations by Jesse Robbins, myself, or Patrick Debois about devops on slideshare.

Our engineering culture at Etsy has written about some of these topics as well:

Good luck!

Building Scalable Web Sites Will Be Different

John, Thank you for your detailed comments. I understand all of your points in today's environment. Flickr (btw: I read and like Cal Henderson's book), Facebook, Google, Amazon, Yahoo, etc... had to build very custom infrastructure and software to make those environments work. And, those were designed a few years ago.

If you project out 2 to 5 years with cloud computing and the elastic application platforms, new elastic applicatino architectures will be available to everyone. For example, you won't need 20 engineers at Facebook just to manage and tweak memcached. The little guy and many large enterprises cannot expend that same resources as those big guys yet they are faced with increasing scale.

Cloud computing and the elastic application platforms that are emerging will help democratize scale for everyone. I am not saying we are 100% there yet. We are not. But, it is coming and the relationship between Ops and Dev will change.

Reality check

Hi Mike, like it's been already mentioned before it is a laudable goal to aim for fully automated on-demand infrastructure that a developer can simply provision. And I appreciate the Formula1 Vs Honda argument, there certainly is a lot of truth to that. Nonetheless the reality seems to be that in a lot of cases you will need to make customization and have a deeper understanding of the infrastructure that does not belong to development.

I don't think I've seen a reply from you to the NoDev argument and I'd love to hear what you think about that because it seems to be very pertinent. Why can't we do away with Devs? You used to need to know how to code to run a blog, now you can just host one on wordpress.com, but while that's fine for a lot of people it is not ok for many others. I've done web development and I could customize my wp code, but it would take me longer than a professional and possibly with lower quality. I don't think I will personally ever be able to do away with devs because even in a small reality like blogging there are problems best tackled by a dedicated web developer. This is even true if you are a backend developer that knows nothing about web techs.

Even from your last post your argument seems to center around the fact that you believe "cloud computing will make infrastrcuture a utility". That doesn't seem to be likely to ever happen to me, as certain bits become simpler we will able to tackle more complex problems and need more complex infrastructures that will be hard to make into utilities. It certainly is much easier than it used to be for a developer to build something useful and usable without the intervention of system engineers, but my direct experience as a SE consultant suggests that even startups that begin like that sooner or later start to hire operations folks. This because the general purpose infrastructures they have in the cloud won't cut it or because there is still the need for a lot of automation and features at infra level that developers are not able to address or is just not efficient for them to do so.
If we then agree that ops is important and there are communication challenges that need addressing, then Devops seems to be a valid effort.

Ops is necessary to install, maintain, and manage...

Ops professionals are necessary to install, maintain, and manage infrastructure hardware and software such as servers, load balancers, SANs, etc... Stuff breaks and ops professionals are needed to monitor and respond. But, what can Ops professionals tell me about how to architect my software for availability, performance, scale, adaptability, and security? Application development professionals better know how to design and implement software that will meet both functional and non-functional requirements. That means also knowing something about the platforms they run on. I guess I can make the same argument about DBAs and WebSphere Administrators.

My vision:
1. Software architects know how to design for elastic infrastrcuture resources
2. Applications automatically provision or de-provision those resources as needed.
3. My Ops is outsourced. I have Application Support to respond incidents.


Up to this point DevOps has been decidedly "opsided", leaning towards the codification of operational tasks (install, maintain and manage). This is definitely a good thing, a necessary movement. And, the tools that are making this possible are doing a excellent job of creating the marketplace that will enable the behavior changes required of the "clickity clackers".

But, as a software engineer on the front-end of the flow I want to see more discussion about DEVops (big Dev, little Ops) and an evolution of the tools that will enable the changes required there. DVCS, BDD, cloud, monitoring and other arenas are definitely in position to be included and extend the DevOps further forward. We, on the software architecture angle, need to ensure that (1) architects not only know how to architect for cloud resources, but have the infrastructure resources available to meet the increasingly more complex non-functional/operational requirements, (2) policies are in place to the utilization of automated provisioning (and self-service capabilities for dev/test), and lastly (3) understand the SLAs reachable by providers and hook their management and maintenance capabilities into the existing operational management environments.

We also need to be clear about the distinction between the opportunities available to start-ups, or lean organizations, and the enterprise. The same needs exist in the latter (http://blogs.forrester.com/dave_west/11-03-09-dev_ops_fell_on_deaf_ears_... points to this well). As has happened with Agile/XP/Kanban, the organizations that have been able to successfully adopt aren't necessarily the ones that need it the most.

I would have to say you that

I would have to say you that given this statement you will have successfully outsourced your platform infrastructure, not your operations.

Mike, how are you forming your DevOps opinions?


Could you give some transparency about how you are forming your opinions about what DevOps is/isn't?

If you look at what you are actually asking for underneath your headline grabbing anti-DevOps and "we don't need Ops" statements, you are actually describing the need for one of the central concepts that is frequently discussed in DevOps conferences and meetups... the idea that routine Deployment needs to be handled by a self-service interface that Ops provides to Dev!

It's not "NoOps" it's "Ops is a service provider to Dev".

To make this happen you need 4 key things:
1. Dev and Ops to collaborate at design time to make sure that Ops understands and provides the platform capabilities that Dev needs
2. Dev and Ops to collaborate at design time to make sure that Dev understands and treats non-functional requirements from Ops as first class citizens along with the functional requirements from the Biz folks.
3. Fully automated provisioning system (which there are plenty of shops that have achieved this.. ask around on http://groups.google.com/group/devops-toolchain if you want actual large scale examples)
4. Fully automated QA integrated with extensive real-time monitoring and analysis (John Allspaw from Flickr/Etsy, Pascal-Louis Perez from Wealthfront, or Lee Thompson from E*TRADE/HP can show you how this is done at scale)

I think you've kicked the proverbial hornet's nest with this post because you, representing Forrester, have taken a position that Dev shouldn't want to talk to Ops and that "NoOps" (as in "Ops is just the team who builds servers and doesn't add value") is some kind of industry ideal (in the face of a growing number of orgs proving just the opposite). That seems like toxic and reckless advice to the point that taking those positions within a leading organization (Google, Facebook, Shopzilla, Etsy, Wealthfront, Orbitz, Morning Star, Yahoo, Intuit, etc..) could possibly cost one of your followers their job.

Which brings me back to my original point... can you tell us how you are forming these opinions? Are you reading certain blogs to form these opinions? Which ones?

What companies are you talking to? How come they/you aren't willing to use their names like the the multitude of pro-DevOps voices do willingly?

Have you attended any of the sold-out DevOps Days conferences? Plenty of chance for you to have... In the past two years there has been 2 in Europe, 3 in the US, and 1 in Australia. The DevOps Days conference in Mountain View last summer was a who's who of companies that specialize in building and operating software (Google, Amazon, LinkedIn, AOL, Facebook, Intuit, Shopzilla, Etsy, etc..). Most of the DevOps Days events use EventBrite for registration, so you can see the attendee list yourself and ask around. The DevOps meetup group in Chicago has over 200 members from both high performing web outfits (like Orbitz) and high performing financial services company (like Morning Star Capital). The London DevOps group has an equally impressive membership. There are dozens of other DevOps groups around the globe. Which ones have you spoken with?

Without specific evidence and obvious community interaction, it sure comes off like you (and Forrester by extension) have some other agenda against the DevOps concept. Without more transparency, I think you are hurting Forrester's reputation by coming out so harshly against a self-organizing movement of actual practitioners who are helping each other solve real problems in a vendor neutral way.

I'd like to invite you to attend the next DevOps Days which will be in Silicon Valley on June 17th (the day after the nearby Velocity conference). I extended the same invitation to your colleague, Dave West. I think you'll both find a high-caliber audience full of actual thought leaders and practitioners. It would certainly give your DevOps posts a huge boost in credibility if you came and made you case.

I'm one of the organizers and you can reach me at damon@dtosolutions.com

-Damon Edwards

Netflix runs on NoOps

Mike describes how Netflix runs in the cloud. Our ops department is AWS and is API driven. All the cloud deployments are driven directly by the engineers who are responsible for scaling and deploying their own service in our SOA. The architecture is common patterns that provide a path to follow, and tooling that is like a larger scale elastic beanstalk. We have ops expertise in our DEVops role, but there are no SA, DBA, Network or Storage admins. We use NoSQL instead of Oracle, simple internal disk instead of SANs, and autoscalers to deploy hundreds or thousands of instances in an hour if that's what we need. The ITops dept manages the data centers, CDNs internal and saas apps.

Your "NoOps" definition doesn't seem the same...

Hi Adrian,

Maybe I'm missing something and you can clear it up.

It sounds like you have leveraged a large amount of automation and have distributed operations responsibilities into other parts of the org (on-call developers and your operations specialist DEVops). You also state you have an "ITops dept manages the data centers, CDNs internal and saas apps". Those are all ideas that are discussed quite a bit in DevOps discussions (measured by conversations at DevOps events) and it sounds like Netflix is executing very well on your vision.

But it also seems like a far cry from Mike's NoOps statements like "NoOps means that application developers will never have to speak with an operations professional again"... don't your DEVops, developer, and ITops talk and plan out major releases or changes to procedures or automation? Aren't they each just sharing the "operations professional" hat rather then getting rid of that function/role all together?

If Mike's description of NoOps was the same as what you described in you comment, I doubt there would have been any backlash. It seems totally in concert with what most DevOps discussions seem to strive for (especially when you can start fresh in the cloud and not have to contend with legacy systems).


Our "Traditional ITops dept"

Our "Traditional ITops dept" has no responsibility for what we deploy in the cloud and I don't even know if they have login permissions. Our developers never need to talk to ITops unless they are working on the data replication systems that connect to the DC. Our NOC still acts as a central facilitator for production alert con calls, which span cloud and DC because we haven't finished migrating out all the apps and data that make up the Netflix product, and that linkage (which we call roman riding) is the source of most issues. We look forward to being able to run standalone, with no DC dependencies and all master copies of the data in the cloud, with a much more robust highly available software architecture. We have a cloud systems team that I'm part of which does the common DEVops stuff, but we are staffed with developers and are clearly part of the developer org. Other dev teams don't have to talk to us either before they deploy. Responsibility has been decentralized. NoOps.

What kind of activity does

What kind of activity does your cloud systems team do? What do you consider "common DEVops stuff"?

NoOps is Not Possible

Hi Mike,

As I'm sure you already are aware, NoOps is not possible and never will be, for many reasons.

First, let me say: "Who cares what the developer wants?" Having been a developer for many years in my career, before going into IT leadership and then into private services, I can say with confidence that most Developers in most companies do not represent the business that their enterprise is in nor do they typically understand what it takes to run a successful company (as is the case with most IT people, too).

Second, you made the statement that "the ops guys efforts are critical to our applications because they have to run on something." I believe this is a complete misrepresentation of Ops and its responsibilities. It's Engineering's, not Operation's responsibility, to provide Hardware infrastructure for Software to run on. Operations deploys, supports, monitors and coordinates the operating environment that has been engineered by engineers and that is leveraged by software developers.

BTW, the real equation is "Dev + Eng + Ops = DevEngOps"

You say that Software developers want more releases to Production. Yes, however let's be very fair... Developers want that and also want to do the bare minimum to get their code deployed. How many of today's developers actually do "all of the right things" to deploy their code? How many fully automate every aspect of their Building, Packaging, Distribution, Installation, Instantiation, Initialization, Execution, Rollbacks, Unit/Module Tests, System Integration Tests and User Acceptance Tests? Any developer that really follows best practices and actually does these things for all aspects of their application (and I'm not just talking about their Java or .Net Code) is in the minority. Rarely, does a developer follow all best practices before deploying his/her code. The less they do, the more risk they introduce into their code and, ultimately, the environment they deploy to. Remember, in a large enterprise (like many of the large financial companies), when code is released, it's released into an environment with tens of thousands of other applications that share common infrastructure. What that means is that something a developer or a development team deploys to a production environment will have to co-exist and interact with many other applications. If you throw a weak link into a chain then you compromise the entire chain. Operations (Ops) exists to manage that complex landscape and all its risk. And, as long as that complex landscape exists, or as long as a runtime environment exists, Ops will exist.

Remember, the concept of Ops was created to segregate roles and responsibilities in order to free up developers to do more of what they are supposed to do best, which is create and deploy more code. If there were no Ops, Dev would be performing Ops functions and doing less dev. Given the quality of most developers' code, image that scenario...

My Best,
Frank Guerino
The International Foundation for Information Technology (IF4IT)

Oh, but it does...

The problem is that NoOps already does exist. It may not be called NoOps, but its out there.

Dev + Eng + Ops?

Perhaps you just need to look away from IT for a moment, and focus on how the "product" space works, or anything where real engineering is done.

eng = f(dev, qa, ops)

This is probably closer to reality there.

I do agree that most developers don't follow ALL best practices. This is true, because it simply just doesn't make sense. Not even in a CMMI environment are ALL best practices mandatory. There will always be a "right" mix.

And, sometimes that mix just doesn't include Ops. But, let me be clear - there will always be system administrators, and "DevOps" peeps, in the loop. The difference is who employs them.

In the software world, we've been enamored with the notion of "convention over configuration" recently. NoOps is just an extension of this, being applied further into the lifecycle. It is a small price to pay, for a cleaner, more stable system (and even scalable).

Again, it isn't about Devs doing Ops work or vice versa, or a change in the functions that make up the SDLC. It is about people and culture - and the ability to get them together to collaborate in some form, early and often. Like I said before, the Ops people are just working on the front-end to create repeatable processes, and infrastructures that don't require them to "clickety clack" on the backend to provision and maintain. The one piece that I'm not too comfortable with is maintenance and monitoring...but, that too one-day will become automated, and self-responsive.

NoOps is a Dream That Will Never Happen

Hi Kit,

Some basic things, starting from the end of your post, first...

You state: "the Ops people are just working on the front-end to create repeatable processes, and infrastructures that don't require them to "clickety clack" on the backend to provision and maintain." To be clear, most people don't recognize this description an Ops function. Process "development" and "engineering" are functions that are performed long before anything ever gets deployed to Ops. The hand-off is to Ops from Software Development and from Infrastructure Engineering. Ops is recognized as a support function by the entire IT industry and includes the support of both the systems and the applications that run on them. Engineering is a form of design and happens further upstream in the SDLC.

Also you point to "convention over configuration" and make the point that "NoOps is just an extension of this." It's an extension of the spirit but the hardware infrastructure part of the picture is only a piece of Ops. There is the Application Management & Support, too. People need to be there to know how to deal with the business side of application support and no Cloud provider will ever be able to do that without providing fee based services to learn and support your apps. That type of Ops, which is App Support, will "never" go away, regardless if you run locally or on a Cloud.

Finally, your equation of "eng = f(dev, qa, ops)" is not something that I believe I agree with. Architects, Designers, Engineers and Quality people would rewrite your equation to be more along the lines of:

quality = f(planning, requirements, design, construction, deployment, testing, support, human skills)

Engineering is simply a more detailed form of design & development that gets done "pre-Release." You plan for the App, the Software Infrastructure and the Hardware Infrastructure as a "system" and manage that system through the SDLC. During design, you engineer your solutions and their components (i.e the App, the Software Infrastructure, and the Hardware Infrastructure) and manage them all as a "system." Sure, in some cases, pieces of that system and its infrastructure have been pre-deployed and can be leveraged as opposed to built, however, someone had to first plan it out, design & engineer it, build it, test it, then deploy it, and finally support it.

Anyhow, I hope this clarifies what I was trying to convey.

My Best,

Frank Guerino
The International Foundation for Information Technology (IF4IT)

Same World, Different Ecosystems...

Hey Frank. Thanks for the dialog.

It's amazing what a bit of perspective can do. I think I agree with you. I believe I stated it somewhere else in this thread/puzzle - that scope is an important factor. Not many applications are monolithic (if any) anymore. There are many different moving parts, some internal, some external...just thinking about the scalability of a multi-tiered architecture makes my head hurt. Some applications, given the appropriate scope fit the NoOps "thing". Some don't.

Ultimately, I think we're just hitting the Software Engineering versus IT barrier...and won't ever agree. Which is OK. ;) It's that perspective thing.

"Ops is recognized as a support function by the entire IT industry and includes the support of both the systems and the applications that run on them. Engineering is a form of design and happens further upstream in the SDLC."

You made these two statements - as they're absolute. To be honest, they both sound a bit bookish...like something I read in a text book many years ago. To the first statement - this is the problem at hand. There is no "entire IT industry", and many Ops peeps I know scoff at the idea of being a support function, since this is the cultural paradigm that has created the riff that DevOps is addressing. To the second statement - bah, this would only be true if you only ever built one version, and one state of a product/service. I think it would be safe to assume that nobody can exist in that world anymore. Engineering is a constant. Demands change; technologies change way to rapidly to not be in a perpetual state of engineering (forward). I come from the bullet-building-metal-bending industry - so I've been taught that engineering comes in many flavors - including operational. I feel like you're making a statement that is justifies the issue that is at hand. Industry and separated dev and operational cultures - based on some archaic notion of a uni-directional flow of lifecycle (which has fallen out of traditional engineering). The new reality is that we need operational engineering that operates software services, to include the delivery from dev to production - not a support organization that waits for something to break.


Hi Kit,

Thanks to you, too, for the dialog. I'm enjoying it.

Being formally educated as an engineer and having worked as a formal engineer for many years, before going into software dev, IT management, leadership and then out on my own to provide services, I can say that we can't really make-up the definition of engineering. It simply exists and there are many formal industries around many formal disciplines of engineering. However, in all cases, the notion of what engineering is, is pretty consistent. All universities teach that engineering is the understanding, scoping, analysis, and solution design of a problem. This is so consistent that most companies will hire a separate role, called a technician, to construct, deploy, test and support, so as to free engineers to focus on the value-add components of problem solving and solutions delivery. Engineering is a set of constructs and perceptions that have formally existed for centuries so I don't know that we can just go out and redefine them, nor would I try to.

As for my statements sounding "bookish," I agree that they do. Ambiguity is one of the biggest issues that bars standardization in all aspects of IT so I do my best to stay away from ambiguity, as much as possible. That's a habit of mine so I openly apologize if it rubs people the wrong way. I've built my career around fixing ambiguity for enterprises so it's worked for me. I firmly believe in locking down terminology and its definitions as a methodology for eliminating ambiguity and getting people to communicate better, as well as to know and understand exactly what their roles and responsibilities are. When you deal with very large enterprises and spend a lot of time writing and/or reviewing contracts for services, elimination of ambiguity by being specific, even if it comes at the expense of sounding bookish, is an asset. :-)

I'd like to address your statement that "many Ops peeps I know scoff at the idea of being a support function, since this is the cultural paradigm that has created the riff that DevOps is addressing.

I'm personally a "lover of patterns." This includes all types of patterns: Design Patterns, Process Patterns, Knowledge Patterns, Organizational Patterns, Cultural Patterns, etc. One of the pattern sets that I personally love to follow and understand are the patterns of how small, mid-sized, large, and extremely large enterprises work and structure themselves. I think we can all agree that the smallest enterprise is an enterprise of one person. In this example, one person does it all... Strategy, Planning, Requirements, Design, Construction, Deployment, Testing, Execution, Support, etc. As an enterprise progresses to be larger and on its way to being mid-sized, we can all agree that one person can't do it all and there becomes a need to split off roles & responsibilities. Usually, that split starts in a "horizontal" fashion (i.e. you hire a second person that also performs all the same functions as the first person, that was formerly the company of "one"). This type of split not only helps increase productivity but also helps reduce risk by introducing redundancy (e.g. one person goes on vacation and there is another to still do all the work, even if productivity slows for a bit). As a company continues to grow and those people can't keep up with all of the work/demand, there is an eventual point where scaling stops just being horizontal and eventually becomes "vertical." For example, you hire one person to handle all aspects of databases and data infrastructure "or" you start to do things like split off development from support and hire dedicated developers and dedicated support people. For a while, growth will continue to cause, both, horizontal and vertical splits of roles and responsibilities. However, when you get really big, an interesting patterns starts to occur... Horizontal splitting starts to scale back and move towards elimination, while vertical splitting becomes the normal pattern and continues to grow. This is what allows really big enterprises to be able to segregate and ultimately outsource different vertical functions to different vertical service providers. Don't get me wrong... there are many service providers that offer a mix. However, when you get to be VERY large scale, splits tend to be more vertical (by clear roles and responsibilities). Interestingly, a lot of these vertical splits line up with different phases of an SDLC (although there may be some cross phase roles & responsibilities (like testing groups that do both integration Testing and User Acceptance Testing) but this commonly diminishes with growth of the enterprise.

I believe that it's an unfortunate symptom of these patterns that Ops or Support becomes a vertical that most often gets the least glamor, even though they may work just as hard or, sometimes, even harder. This is typically because developers are closer to the business and development is often tied to things like "Delivery" and "Innovation", whereas Support is often perceived to be tied to "Business As Usual" or "Steady State," with the capacity to scale up or down to address change. This doesn't mean that Ops/Support isn't important. It just means that this is the pattern that commonly occurs.

Now, given this pattern, there is an interesting anomaly that starts to show itself... The costs of IT become larger and larger, as you get closer and closer to Ops. Large and Very Large enterprises spend huge fortunes on Real Estate, Data Centers, Infrastructure and Support to address the Ops problem and that big glaring number is tied to a common realization: "We're paying a fortune for something that is not our core business." In other words, IT Ops is very rarely tied to the core functions or innovative functions of a business and often becomes extremely expensive. This is why things like Clouds become so attractive (Better infrastructure, and quality with lower costs through economies of scale). If you design, build, market and sell cars, IT Ops is not your core competency. If you design, build, market and sell clothes, IT Ops is not your core competency. Etc. Those companies where IT Ops is a core competency are rare in the grand scheme of the world (IBM's & Tata's ops services divisions would be examples of companies that do provide Ops as a business).

When it comes to limited money to go around and you're the leader who has to decide where to spend your money to grow your business, where would you want to spend it? On market-aligned Product design, development, manufacturing, and sales? Or, on IT Ops? No leader in their right mind wants to over spend a penny more than they have to on non-core competencies and would rather overspend on core competencies.

Now, given all of this, it's been my experience that most Ops people "scoff at the idea of being a support function" (which was your statement) because most people want to be appreciated for what they do and want to be perceived as adding value. This is one of those patterns that I believe falls into that category we call "The Human Condition." My suggestion to people who "want" to do Ops for a living and, simultaneously, want to be appreciated for such services is to work for enterprises where Ops is their primary function. Then, assuming they're good at what they do and work hard, they will always be appreciated because the services they provide will always align directly to and be a critical part of the business model and strategy. If they work for enterprises where Ops is not the core competency, then, sadly, patterns show that they will continuously be treated as third class citizens, which is always a shame. This pattern is the same for Dev, which is usually considered to be a second class citizen. If they want to be appreciated then they need to look for work in companies where Dev is the business and the strategy, like Google. I say this from experience... "Been there. Done that. Wore the T-Shirt."

At this point, I will have wish you a wonderful weekend, as I now have to sign off and make up the lost time I spent on these great conversations before I can go off and enjoy mine, too.

My Very Best,

Frank Guerino
The International Foundation for Information Technology (IF4IT)

What a big response. Well

What a big response. Well done, Mike. And much more to the point the the Forrester analysts that I've talked to on IT Ops subjects.

The whole problem space is complicated as we all bring our own baggage about what is Dev, Engineering, Ops and other parts of the IT value chain.

As a general point, I think that you are very close to the truth. There is much too much technology and complexity in corporate IT. The whole way that it is delivered is broken in many ways, which, as much as anything, stem from the investment model driven by a heavy capex model.

IT does need slimming down (possibly to zero) and lifetime ownership of what the business uses should not be so heavily siloed. Under her leadership, all of the skills need to be brought to bear and centered around what the business operations values, rather than recovering spend on assets that weren't really needed in the first place.

However, there will be a big skills gap and the likely failures will come as much from 'doing the thing wrongly' as in 'doing the wrong thing'.

IT languages

Dev and Ops. Throw in a bunch of Network guys and a blonde, and you have ideal lab for disfunctional communication :)

Dev lives in Design and Transition, and Ops wants to be in Operating stage all the time. Although they are both in IT, they want to see each other as less as possible.


Come back 1965, all is

Come back 1965, all is forgiven.


What we really need is Nodev; where the vast legions of barely-competent, socially backward developers can stop gumming up perfectly good off-the-shelf software by sticking awful plugins into it and clunky portals on top of it.