
The Best DevOps Is NoOps - fhirzall
https://medium.com/buttercloud-labs/the-best-devops-is-noops-e99c83d4fdf0
======
phatbyte
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
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.

I'm not against BaaS, I think they're very useful, for prototyping, for micro-
services that don't directly affect the main product business rules (image
processing, chat app, etc..) but putting all your "gold eggs" into a vendor
system should be taken after a serious thought of the pros and cons.

~~~
chii
> 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 needs to be standardization, so that commodities can be
commodities. Companies like to pretend they are some special snowflake that
sells something unique and un-replicable. That's not at all the case, and i
wish that more people call them out on it. Making sure that standards exists
for a particular commodity offering (e.g., apis, or via some sort of RFC), or
don't use them at all.

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

~~~
user5994461
A lot of power supplies are strictly 110V or 230V. They will fry when plugged
in a different country, with the adapter.

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

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

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

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

------
grx
I see two problems:

1\. „Ship, ship, ship!“ – Yes, a speed advantage over competitors - especially
with a new innovative product - is a key factor for startups. BUT: does
anybody really believe in the transition from prototype to a scaling product?
The article talks about „Startup Lifecycle with DevOps / NoOps“. Show me a
business that has done this transition; planning ahead for a rewrite and
budget für new admins.

2\. Cloud-lockin. This should be taken very seriously by any startup that
wants to live longer than a technology cycle. If you choose to build your
platform on top of cloud technologies, you give up the control over
functionality and storage. IMO any tech business should be able to handle at
least web and application server architectures for their platform (I agree
that mail is something different that should be left to mail providers).

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

~~~
pmlnr
> I can manage a server manually

Ansible? Puppet? Chef?

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

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

------
m1keil
_sigh_

Disclaimer: I'm an ops guy (technically SRE by job title).

There's so much more to Operations than just running pure infrastructure. It's
not only about bare metal and application server configuration or maintaining
your CI/CD pipeline.

Data life-cycle (backups), capacity planning, incident management, monitoring
and KPIs are just some of the items from the top of my head.

I'm not saying that developers can't do that, it's just... if they do, they
are doing Operations and you effectively have Ops in your organisation.

Ops is not only about installing and managing LAMP stacks..

------
gregatragenet3
My favorite example of a NoOps organization
[https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/a...](https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/)
. Now also a NoDatabase organization heading towards NoCustomers. Having some
ops guy in the loop is like having insurance against a class of easily
avoidable but company ending/maiming mistakes.

------
jaggederest
I've been saying this for a while.

If you are spending less than $25k/mo on Heroku or equivalent, you're not
ready to move off it yet.

A lot of times when I talk to people with a high Heroku bill looking to move
to bare metal, I end up being able to optimize it by 1/3rd or more just by
picking dyno types, scaling appropriately, and consolidating workers. You
can't really do that when you're hiring headcount.

~~~
grx
How can you compare the monthly price versus VM types/capabilities?

What does my bill say about the performance of my app in an e.g. Amazon
environment?

~~~
albertgoeswoof
he/she means you can probably get away with just adding more dynos or whatever
to your PaaS to get the performance you need, because the costs of moving out
will be significantly higher (opportunity costs and time spent)

eventually if you're spending thousands per month on a PaaS it might be time
to reconsider

------
zoltrain
It also doesn't take into account the startups that can't use said serverless
architectures, like Fintech or Heathtech. You inherently need to understand
how data moves through your platform when you have tight compliance
restrictions. It's why both Firebase functions and Lambda aren't HIPAA
compliant. unsurprisingly the old school tech like RDS, EC2, EBS, VPC are.
Having a sweeping statement that if you're an early stage startup you need to
be No-Ops is a bit silly in this context. It shows you not considering what
you're trading for that platform. I'm more for having better tooling for
orchestrators like Kubernetes. You still get low level control, but most
boring ops can be automated away pretty easily. You also don't trade
portability across cloud vendors. If your dev team is already using
docker/docker-compose then its not much of a step up to deploying a service in
Kubernetes.

------
jerguismi
Looks like an advertisement piece for their services.

~~~
gaius
Yes, it's just an ad. Never have to speak to operations is naive nonsense -
chuck it over the fence and pray that site failover, backup/restore, etc just
happen by magic. Cloud is great, serverless is great but TANSTAAFL.

------
Boothroid
Whenever I'm reading one of these ads masquerading as blog posts I always
close the browser tab the moment I come across the 'here at x company..'
statement.

------
skybrian
It seems odd that Google App Engine isn't mentioned, since that's been NoOps
for many years before the others came along.

------
johnpython
If you think being a "software engineer" means you only write code and
ops/security is none of your concern, you are terrible. The best software
engineers understand the importance of operations and security for the code
they release to production.

~~~
mgrennan
And if the went so busy putting as steering wheel on the skateboard they might
have some time to thing about how the seatbelt fits and bumpers. Speed Kills.

------
mdekkers
_NoOps means that application developers will never have to speak with an
operations professional again._

Unless is is the middle of the night and your site is down. Then you _really_
want to be able to talk to an operations professions. Idiots.

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

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

------
yellowapple
"A few examples of NoOps platforms that fit the above criteria are Heroku,
Amazon Lambda, and Google Firebase."

I don't know about Lambda and Firebase, but Heroku is _not_ "NoOps" in my
experience. You still have to deal with dyno configurations and linking things
together, and even have to deal with security updates every once in awhile
(Heroku's "stacks" are not supported forever).

Meanwhile, this sort of vendor lock-in is a great way to murder a startup
before it even learns how to walk. These services are not cheap; hiring a
"devops engineer" or a proper sysadmin will almost always pay off in the long
run, since they'll be _much_ cheaper (and much better at their intended
purpose) than the likes of Heroku when you actually do need to scale beyond
the prototyping stage.

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

------
holydude
Seriously people developers are NOT paid for piling up features. I do not even
know where to start but this article and I guess the guy representing the
company totally failed to understand few concepts here and there.

------
geekamongus
DevOps: "Captain, we need to divert power from the warp core to the forward
shields."

"Make it so!"

NoOps: "Make us go."

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

------
internobody
"i hate to break it to you, but you still have to monitor shit in heroku, you
knuckleheads."

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

So basically the exact opposite of DevOps?

