[pmlnr]

"NoOps means that application developers will never have to speak with an operations professional again."

I really hope this is a joke. Application developers have a hard tendency towards "getting the job done" without thinking of optimisation and scaling, which will lead to gigantic costs. Ops people are not only for maintenance, they are also the ones thinking about scalability including costs. If you get rid of this layer you will end up running your business at a much higher operational price tag than you should and you will lose money.

[singingfish]

I spent some time at a startup where I believe (thanks to profiling) that I produced a first-pass patchset demonstrating bug-for-bug parity that would save them 10-20% of their substantial AWS bills due to efficiency improvements / removing some very bad early decisions.

Of course they made those savings by retrenching me instead (and hiring more cheap juniors when the time came) as they were too scared of their own code. I believe two years later my code reviews are still in the queue \o/

[fhirzall]

Hey pmlnr, author here. I think what the post is trying to say is that the ops team will still be at the company, but the communication overhead across teams will be less of a burden. Your ops team will still be thinking about cost, scalability - but your developers can focus on shipping features. We also mention that this is a good approach for early stage startups looking for product market fit, i.e scalability and server costs still haven't become an issue at this stage.

[scaryclam]

No offense, but the concept of a DevOps culture was created specifically to get rid of the silos you've just described as being a good thing.

Without the communication overhead, your Ops team won't know enough about the product and what it does to appropriately plan and implement the infrastructure. If your developers don't know what the infrastructure can look like, they'll be making guesses at what resources are available and may just end up building and shipping features that cause major problems in production. The result? Generic build outs that cost more and run worse, all because teams don't talk to each other and nobody understands the requirements.

If your company is in such an early stage that all you're doing is prototyping, then sure, it really doesn't matter so much. The second you're going into production, you'd better get a competent team who can deal with their own infrastructure (even if it's IaaS), and communicate with each other or it's going to be painful to just keep going, never mind grow.

[pmlnr]

> "Your ops team will still be thinking about cost, scalability - but your developers can focus on shipping features."

> "i.e scalability and server costs still haven't become an issue at this stage"

What you're describing is a hackathon demo, not a product. When you expect something to go hockey-stick, so simply can't afford not planning ahead with scalability.

Many doesn't and you can see them fail to cope with the stress an unexpected interest pokes their services. (Think mastodon, or any random blog that gets the Hug of HackerNews).

Developers _should_ be aware of this. Shipping features should never be ahead of serving what you offer live.

[fhirzall]

Every single product including the ones that go hockey-stick start out as prototypes that don't need to be prematurely optimized for scaling. That doesn't mean you shouldn't plan ahead with best practices for performance / etc, but the bulk majority of startups will not reach product-market-fit with the first version of their product. It takes months and years of iteration to be able to put up a hockey-stick growth curve.

Offering up a refined, live version of the product is non-negotiable and completely achievable with the tools mentioned in the post, but adopting services that simplify your infrastructure processes gives you the focus that an early stage product needs.

I'm 100% with that you should control your infrastructure if you're an established company, brand, or product, but we're coming at this from a startup's standpoint where speed of iteration & shipping features make a huge difference in the eventual outcome of the startup.

[pmlnr]

Sorry if I misphrased it, I didn't mean premature optimisation: I wanted to mean planning for it.

EDIT: my biggest question is still the why always focus on new features compared to stability. Think from the point of the customer - eg. when you're using something -, and grab, let's see, skype: they are sacrificing everything stable in order to catch up with the competition. I'd be extremely surprised if they are doing better this way instead of focusing on being rock solid with a small feature set. The latter results in a small, but steady growth - not the one VC prefers for certain - because people fall back to it when the other shiny fails, and, eventually, just stick to it, because 'it just works'. Don't get me wrong, incremental new features is good, but the working core product - the one that is making the money - should always come first, ahead of the shiny. Obviously my logic assumes the product is making money.

[keymone]

shipping features is always at odds with having stable product. the former is the goal of engineering team, the latter is the goal of operations team. devops is culture of communication between those, not some magical hybrid of both that makes the site run.