James U. • Complete BS.

As I am going to hammer over and over in the coming years, cloud is a complex adaptive system, which means even the best "NoOps" automation is going to have to adapt to a wide variety of applications, conditions, changes in technology and changes in the market.

There is no such thing as NoOps. There is AppOps, which can be done by developers, and can be assisted by tremendous automation, but it will exist. See http://news.cnet.com/8301-19413_3-20016550-240.html

Furthermore, in talking to enStratus enterprise customers, it appears highly unlikely that any enterprise will allow a developer to remain on the hook for production availability of any app for long. The best developers will move from project to project to project, which means there will be room for people who watch over production applications (many, many of them at a time). To me, that's ops.

Dan T. • I do think Lucas's vision is right on in terms of direction. I'd quibble a bit with the name since NoOps is primarily a developer theme, and we'll probably never get to the point where developers can be completely unaware of the behaviors necessary for deployment. (for example, as a .NET developer my app might need specific IIS app pool settings set, which is ostensibly an operations task).

I'm not sure about the timeline for mainstream adoption, but we're already seeing a lot of traction around the concept among enterprise customers, and people already moving there.

On a side note, and since I'm sure Lucas will be stopping by, I'm not sure I understand the differentiation between AppFog and CloudFoundry. I thought AppFog essentially offered CloudFoundry capabilities, but over multiple infrastructure providers?

EDIT: James is right in that we're not seeing enterprises wanting to turn over operational maintenance of running applications to developers. The "answer" needs to include capabilities for both devs and operators - especially in the medium-term private cloud world.

Ben K. • James - with the greatest respect (and dude, I mean that genuinely) I don't think we should completely dismiss the concept of developers having no operating requirements for a product's operations. Isn't the holy grail a fully automated system that wrangles the complexities underlying app delivery and does what is needed to ensure availability?

On another note you raise an awesome point viz the contention that devs will not have the "DevOps" role on an ongoing basis as they move from project to project. So I'd be interested to know where you see the line between developing with a view to operating efficiency and the actual operations itself... if that makes sense - essentially I'm saying there's a blurry line between Dev (with a degree of Ops in there) and pure Ops. What say you?

Diane M. • Saying that PaaS is all about just about NoOps diminishes the power of PaaS in the application development lifecycle. NoOps is great conceptually, and Gigaom/AppFog have done an awesome job illustrating the potential of PaaS - but please don't wait until 2013 to start using PaaS.

PaaS enables so much more than just easy deployment path to the cloud. It's about going from code to cloud - giving the developer micro clouds that are identical environments to the production ones to rapidly design and prototype on, creating an ideal staging environment for QA and testing, and then being able to re-point the application to the production environment after it meets IT's criteria and review.

PaaS enhances and encompasses the entire development application life cycle from idea to design to prototypes to testing to deployment and ongoing operational maintenance of the service.

The idea that no Operations will be involved the production deployment and ongoing maintenance of services once they are pushed live may be more mythical than the "man-month".

Otto M. • I see CC technologies as the next abstraction layer in providing IT services. Operations will be present but at a higher level of abstraction.

Adrian C. • Netflix runs NoOps - i.e. we do all the things that comments above say won't happen. Just because you don't think "enterprises" will stop using dedicated ops orgs, doesn't prevent some of us from running a dev-only product team that runs its own code directly and calling it NoOps. It's different, so it should have its own name. Get over it.

Ben K. • Adrian - but you guys so a lot of ongoing operational stuff don't you? Hence should NFLX be classified as proponents of DevOps? The point Lucas is getting to is one where zero operational activities occur, it doesn't sound like you guys are there... Or am I mistaken?

Adrian C. • All prod changes are made by the developers that wrote the code. We have some central coordination for reliability engineering that is a devops skill set (working in a dev org, and writing code, not run books), but they don't make changes, they call the dev to do it. Dev says launch new code version (pick, click) send traffic to this version of the code (click). Autoscaler figures out how many to run according to traffic. Alerts go directly to the developers, on-call rota for devs managed by pagerduty. There is no ops function or team for the product, its all development. We do have corporate ITops, for laptops, email, DVD shipping etc. but they don't deal with the streaming product.

Glen B. • 12 months is a bit of a short timeframe for a lot of DevOps related stuff. We're just going through some things at realestate.co.nz now where we are wanting to deal with Big(ish) Data and the tools just are not that plug and play right now. Sure people are working on solutions but nothing so far that makes it set and forget. Same with queue servers and other things we need in our stack.

Glen B. • Adrian: I'm interested in this approach. Are you saying that none of you infrastructure is setup by specialists and everything is done by devs? There is zero server tuning, zero config, etc. verything is installed and configured and tuned by devs or uses of the shelf web services?

Alan O. • NFLX do some awesome DevOps but I'm sure they would be happy if all those guys were doing the same great job - on the other side of the fence (i.e. in Amazon) ;-)

The work they do is something that could be multiplexed across many clients of the Amazon cloud platform (I'm not even going to go into PaaS or IaaS as Amazon offer a mix and everything in between)

It's work they have to do to allow the NFLX Developers build the feature/proprietary/value on top of.

Would NFLX drop some devops if Amazon had Cassandra-as-a-Service with all the features they need - at the drop of a hat I'm sure - but Amazon don't - so the DevOps remains needed.

Will some startups jump straight to using Dynamo to reduce/eliminate DevOps if the feature set is right - yes every time.

James U. • Ben, let me ask you this: is disaster avoidance a dev activity or an ops activity? Is consolidating resource use across multiple applications a dev activity or an ops activity? Is tracking the financial cost of applications to the business a dev activity or an ops activity?

I should say that sometimes even I confuse the existing "operations" roles in IT (e.g. data center operations, mainly) with what we are talking about here. I am talking about operating applications, which I argue will in fact commonly be done by multiple teams within each organization, if only because most enterprises have enough applications to look at IT as a whole (even in the cloud) as something to be evaluated and optimized.

Look, I think there are a few organizations, like Netflix, that have unique opportunities to stretch the boundaries of how things are done. And all enterprises should look at them and ask "how can I do things differently?" However, the vast majority of businesses don't want to leave operations to chance--not just avialability, but all of the things I mentioned above.

Thus, there will be operations outside of simply what the developers themselves do. Will there be an IT department that does it? Probably, but who knows. Either way, operations will continue to exist outside of just the development team in most businesses.

Diane M. • It's obvious from Adrian's comments and as Netflix is hiring Senior DevOps Engineer (see http://www2.netflix.com/Jobs?id=7563&jvi=oFw9Wfw0 ) - that DevOps is alive and well at NetFlix. And I'm a huge fan of Netflix's approach.

But what's occurring here is the roles of IT Ops will/is/continues to morph/merge with Development. It doesn't matter what you call it or who the person responsible reports to, the prototyping, qa, testing, staging and managing the ongoing release cycle for the product will still need to occur - PaaS enables "LeanOps" might be a better way of defining the leaner role that the operations tasks are becoming - regardless of who does the work.

Dedicated Ops teams may disappear from the enterprise reporting structures, in favour of leaner more PaaS-empowered development teams like those at NetFlix -but it's an ongoing evolution - and as James said - there will continue to be tasks outside of the development that continue to exist that will remain in IT operational tasks.

Adrian C. • The Netflix DevOps engineer position mentioned by Diane is embedded in a developer team that builds the middle tier services that provide the various membership related data sources, they need to be a good Java developer with distributed systems and multithreaded application experience, while also having ops experience and taking on that responsibility for the team. The manager of that team reports to the same development VP that I do. That's very different to a devops engineer reporting into IT, writing puppet or chef scripts and working on a list of jobs sent over from dev.

Answering Craig, there is no server tuning, it's all Java code tuning by devs. We run everything in a Netflix PaaS using a common base AMI that updates about once a month with new patches etc. and new code is baked into app specific AMIs. We don't use puppet or chef at all. We do have a central cloud performance team that helps the dev teams tune and autoscale their code, and debugs performance problems. Anyone can deploy a new Cassandra cluster, it's trivial. We have a dev team that is building automation to operate Cassandra, they are rapidly making manual tasks go away. e.g. if a Cassandra instance breaks, it just gets replaced automatically.

I've submitted an abstract to the Velocity Conference in June, "NoOps: what happens when the developers run everything", if its scheduled I will try and explain in detail what I think NoOps means and how we do things differently.

Kurt M. • At risk of going to deep here - but netflix which utilizes and horizontal scale environment made up of non-persistent images - is very different that typical enterprise IT environment that is comprised mainly of persistent virtual machines.

Aren't development and ops requirements very different in those very different environments?

Dan T. • To follow on from Kurt, I'd consider Netflix to be exceptional in almost every way - culture, product offering, technical strategy, etc.

Off the top of my head, some differences between Netflix and the more traditional definition of enterprise (I'm sure Adrian will correct me where I'm wrong):

Netflix's platform is at the core of its offering where in enterprises it's at best a supporting function.

Netflix can have a fairly specialized platform, enterprises need general purpose (or lots of specialized ones)

Netflix isn't encumbered by the same regulatory concerns as many of the most forward-looking enterprises (generally fin svcs)

Netflix seems to have avoided the silos and organizational inertia that many enterprises have

Average talent level of IT staff at Netflix seems higher than at the enterprise

The fact that Netflix can be successful and approach the NoOps vision proves that it's possible, not that it's probable.

Dragan M. • In my mind, the opposite of Ops is Research and Development. If a developer is on the hook for making sure their system is always running and is a responder, he is an Ops person.
What I think is going on with cloud systems is that we are minimizing the System Administrator role and the developer is finally incented to minimize the operational role.

Michael D. • @Dan T: You are spot on. The phrase "ceteris paribus" or "all other things being equal or held constant" is often missing in these debates that center around, "Well Company X did it, everyone else should to!"

As a consultant that travels around the world meeting different IT workers, I have serious doubts when people in one isolated part of the US seem to think that this one company's operations model is now the defacto way Enterprise IT organizations should now operate. The staff isn't there, the culture doesn't exist, the leadership isn't in place, and there is too much baggage.

That doesn't mean that they shouldn't try to emulate some of the great things Company X has done, or even learn from Company X, but to think every company will operate this way is misguided.

Jeff S. • The organization delivering the service (e.g., the SaaS vendor) is accountable for operational excellence. Even if they run on a PaaS platform, they have to make sure that platform is good, and working properly. If it stops working properly, they need to know, and be able to take action. That sounds operational to me.

In the future, no one outside of Amazon may rack servers anymore, and no one outside of AppFog may configure load balancer services anymore. But that doesn't mean operational knowledge/skill/process/tools disappear. I think James has it right with the term "app ops". What concerns me about current PaaS marketing is the implication that you can take a "blissful ignorance" approach.

I think the term DevOps captures the notion that app dev and app ops are both integral parts of delivery quality Software-as-a-Service, and thus should be viewed holistically (whether you change the org chart or not). I think the term NoOps has negative and misleading implications (as mentioned above, the illusory goal of blissful ignorance).

Adrian C. • Lots of strawmen being setup and knocked down here. The AppFog info graphic is talking primarily about NoOps for startups, I'm saying that Netflix is also a much larger example of a PaaS based NoNops organization. Nowhere have either of us said that traditional enterprises should or will be doing this. We do however claim a competitive advantage from the agility and automation of a PaaS based product and a NoOps organization.

The mistaken idea that NoOps means "blissful ignorance" misses the point entirely. Developers do have to learn some ops skills, with PaaS tooling it's not hard, and developers naturally build automation or design out the need for automation if you make them directly responsible for running their own code. As the info graphic notes, the amount of time a dev spends operating a PaaS is small and decreasing.