Live data from Hacker News

The Best DevOps Is NoOps

medium.com

21–30 of 66 posts

Re: The Best DevOps Is NoOps

#21
post #14

Maybe I'm old school, but I really hope developers give a serious thought before jumping into this vendor lock-in trap. This is specially concerning if not scary, when you start to "outsource" the backend business rules to something like Firebase or other BaaS systems. Using these as PoC or for an MVP, I'm 100% behind it, but using it on production ready products, it's a disaster waiting to happen, as it basically pu…

100% agree with you. No one accounts for portability. The common mantra is that if portability becomes a problem you will be rolling in VC cash so you can just afford to restart everything from scratch and shrug it off. Basically defer the complicated decisions to later on. That never accounts for the "grey phase" which a lot of products seem to slide into permanently which is where they are just about scraping by wi…

The message of the cloud native software stack, most often built around Kubernetes, is that cloud portability enables you to avoid vendor lock-in.

A look at the stack: https://raw.githubusercontent.com/cncf/landscape/master/land...

(Disclosure: I'm the executive director of CNCF and helped make this image.)

Re: The Best DevOps Is NoOps

#22
post #2

"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 th…

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/

Re: The Best DevOps Is NoOps

#23
We do move to NoOps in the classical sense, but are not there yet. But serverless is a good step.

With the ever more complex delivery pipelines it does make sense for someone to build delivery infrastructure. And devs are a better investment when they write app code than delivery infrastructure.

Re: The Best DevOps Is NoOps

#24
Fully agree with this. I see people all the time recommending a VPS, a Digital Ocean droplet, an AWS EC2 box etc. for a company website/app/service because it's "easy" and "any developer worth their salt should be able to admin a server" to save maybe tens of dollars a month. Heroku can be an order of magnitude less effort for example.

I can manage a server manually but I don't want to waste my time doing that. It's never going to be as robust as a cloud service that has a team of staff doing it for you either. Anything that requires me to SSH in makes me cringe now to be honest; it's just way more low level and manual than I want to get involved in when I could be coding.

Re: The Best DevOps Is NoOps

#25

Maybe I'm old school, but I really hope developers give a serious thought before jumping into this vendor lock-in trap. This is specially concerning if not scary, when you start to "outsource" the backend business rules to something like Firebase or other BaaS systems. Using these as PoC or for an MVP, I'm 100% behind it, but using it on production ready products, it's a disaster waiting to happen, as it basically pu…

to play devil's advocate...

The article seems to be written in the context of small startups.This is an inherently risky (and risk tolerant) environment.

The biggest risk is usually internal. Fail to make a good product, or the product isn't popular... If your chance of total failure in the next 3 years is alread 25% or 90%, then adding 2 or 10% risk can be reasonable. This is an abnormal situation.

A related concern from a few years ago was FB & Twitter "as a platform". In some cases, the risk paid off. Take Tinder, for example. Tinder doesn't work at all without FB and plan-B is probably terrible.

That's not a risk an existing business could take. Tinder could because they were a startup. Using FB profiles avoided the empty profile problems most upstart social networks have.

Dating is a network-effects problem. So, a 50% (or whatever) increase in profile completion rates could have been the difference between success and failure.

If "NoOps" can genuinely reduce the area of competence a startup needs, and let them focus on application building (or whatever)... that can be an edge. Taking risks to gain an edge is something a risk tolerant startup can do.

Of course, small companies become big companies and these decisions leave a legacy.

Re: The Best DevOps Is NoOps

#26

Maybe I'm old school, but I really hope developers give a serious thought before jumping into this vendor lock-in trap. This is specially concerning if not scary, when you start to "outsource" the backend business rules to something like Firebase or other BaaS systems. Using these as PoC or for an MVP, I'm 100% behind it, but using it on production ready products, it's a disaster waiting to happen, as it basically pu…

> Maybe I'm old school, but I really hope developers give a serious thought before jumping into this vendor lock-in trap.

What vendor lock-in do you mean though? If you're using AWS, Google or Heroku, they all support Node, Python and PHP for instance and have several options for file storage, SQL and NoSQL. Migrating away is always going to be painful (although you can make this easier for yourself with abstractions in your code) but you can still host on cloud services in ways that don't tie you in.

I agree if you start heavily relying on features that only one company provides you might be in for some trouble but hosting + coding it all yourself carries significant risk as well.

Re: The Best DevOps Is NoOps

#28
post #20
post #7

Earlier quoted context omitted.

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…

> "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…

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.

Re: The Best DevOps Is NoOps

#29
While a completely stateless and auto scalable infrastructure is desirable even by Ops people themselves, reality doesn’t always allow for this because: Not everything can be event driven. Persistent data will always have to be managed by somebody.

Plus, NoOps conceals the risk to have a de-evolutions of devs into even dumber IDE users that can’t even type “sudo systemctl start mysql” at the terminal.

NoOps as a company wide phylosophy can’t be tenable.

Re: The Best DevOps Is NoOps

#30
Half of my work is to develop and maintain a devops console for the application. I could indeed have spent that time building new features, but we are not necessarily interested in what else we could add, but rather in what else we could leave out. In der Beschränkung zeigt sich erst der Meister.
Post reply on HN