Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Best DevOps Is NoOps

medium.com

Post reply on HN
Print view View original

31–40 of 66 posts

Re: The Best DevOps Is NoOps

#31

Post by CrLf »

This is so misguided I don't even know where to start, and it's the same line of reasoning that has been degenerating the meaning of DevOps for a while.

1. There is no such thing as NoOps (when something's in production, whatever needs to be done to keep it running qualifies as Ops - does your serverless platform ensure your backups can be properly restored and your application doesn't start crashing left and right in the middle of the night because of bad data and/or user input?).

2. So much advice on this subject from companies that have no legacy, and from companies that _will_ have no legacy (because they'll run out of money in a couple of years). This kind of advice means nothing in the real world.

Re: The Best DevOps Is NoOps

#32

Post by pmlnr »

fhirzall wrote: post #28
pmlnr wrote: post #20

Earlier quoted context omitted.

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

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.

Re: The Best DevOps Is NoOps

#33

Post by scaryclam »

seanwilson wrote: post #26
phatbyte wrote: post #10

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…

I get the feeling the OP was talking more about things like Firebase than EC2 or Cloud Compute. Of course, GCP and AWS will allow you to do things that lock you in, but as you stated, you don't have to do that to use their other products.

The idea that some people are using other companies backend systems to build their own company that completely relies on those systems creeps me out.

If I hire a backend developer who creates an API that talks to my DB, then that developer walks away, at least I can continue with my business while I run around finding a new developer. I don't need a new codebase and I don't need to shutdown operations. If a hosting company goes under but I host my own code there, at least I can redeploy elsewhere and get on with life. If I use a BaaS company and they go under/discontinue my hosting/etc then I can neither move, or hire another company to continue the work. I have to start again, and for anything significant, that's probably going to kill my company first.

Re: The Best DevOps Is NoOps

#34

Post by xorcist »

I've done my fair share of work helping out with botched cloud migrations. The reality is that it is absolutely essential to be intimately familiar with the platform you deploy with.

As long as you are in the business of deploying software, you have to know what you are deploying and how. You can call this person ops, devops, whateverops, or just the guy with most knowledge about Linux.

You are going to end up troubleshooting stuff, and the more far away you are from the hardware the more dependent you are on your tooling and the people who know how to use it. (Especially storage. Don't get me started on storage.)

Anyway, the point is that if you're going with Lambda then need someone who knows Lambda. They may be easier or harder to find than people who know Linux but don't wait until it's too late as that's going to be expensive. And conversely, invest time in learning the platform before you use it.

Re: The Best DevOps Is NoOps

#35

Post by skewart »

ai_ja_nai wrote: post #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 comp…

> 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.

You can say the same thing about ops people being "dumb command line users who can't debug assembly language."

Higher abstractions and fewer reinvented wheels are one of the major overarching goals of computing. If I never had to type "sudo systemctl" ever again for anything but a fun antique restoration project then I would be very happy.

That said, I completely agree that for any company other than maybe some early-stage startups to go completely NoOps today, in 2017, is not a good idea.

Re: The Best DevOps Is NoOps

#36

Post by pmlnr »

seanwilson wrote: post #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…

> I can manage a server manually

Ansible? Puppet? Chef?

Re: The Best DevOps Is NoOps

#38

Post by seanwilson »

pmlnr wrote: post #36
seanwilson wrote: post #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…

> I can manage a server manually Ansible? Puppet? Chef?

Yes but it's still much more effort than a cloud service that doesn't require you to write, test and maintain scripts like this. The less I have to care about security updates and what state is stored on a disposable server the better.

Re: The Best DevOps Is NoOps

#39

Post by jazoom »

phatbyte wrote: post #10

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…

I learned this lesson very early on in my dev experience. My app's database was Parse. Parse no longer exists as a service. Before that it was based on StackMob, from which I moved to Parse because StackMob was shutting down. Parse gave a hell of a lot more notice, but I was done with this project at that point.

Now a feature of the app just doesn't work. I won't be rewriting it for another backend.

Guess who doesn't use Firebase. This guy.

As a side note, I currently use RethinkDB. RethinkDB shut down last year. That has had no negative effect on my current project, which could run for a very long time on the last stable version of RethinkDB. Since it was open source, now it is even under development again.

Re: The Best DevOps Is NoOps

#40

Post by mcherm »

chii wrote: post #17
phatbyte wrote: post #10

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…

> it basically puts your company product under someone else's rules, and if those rules changes or worse, if these companies go bankrupt, migrating to another system could be the death of your product as well. This is basically where standards has to come in. Imagine if electricity was not standarized - you'd have to buy into one frequency or another. Then you'd face the same problem as with using BaaS! I say, there…

> Imagine if electricity was not standarized - you'd have to buy into one frequency or another. Then you'd face the same problem as with using BaaS!

Ever tried traveling around the world (or even just around Europe) with an electric device? Now... once you picked up an adapter at the hardware store, how difficult was it? "Not much of a problem" for most folks, somewhere between "a moderate pain" and "ruined my device" for the few with special issues.

Post reply on HN