6 ms·

The Best DevOps Is NoOps

52 points by fhirzall 9y ago

pmlnr 9y ago
"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 9y ago
  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.
  - keymone 9y ago
    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.
  - scaryclam 9y ago
    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 9y ago
    > "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 9y ago
      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 9y ago
        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.
- singingfish 9y ago
  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/
Turbots 9y ago
Hate to tell this every I see anything "DevOps" related on Linkedin or HN or wherever: There is no such thing as a "DevOps" engineer... DevOps is a culture, not a job description. I'm working as a consultant and every big enterprise right now is looking for "DevOps" engineers. They give their developers and operations people a "DevOps" course, make sure they get their "DevOps" certificate and voila, the enterprise is now doing "DevOps"... WTF?! Some enterprises even say: "Ye, we have 2 DevOpes, so we're cool right?" while they keep doing projects in WaterScrumfall: variable scope, variable budget, fixed deadline sigh
jerguismi 9y ago
Looks like an advertisement piece for their services.
- gaius 9y ago
  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.
grx 9y ago
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).
jaggederest 9y ago
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 9y ago
  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 9y ago
    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
  - jaggederest 9y ago
    A) you can't B) Nothing in particular It's not about the application or any technical concerns. It's purely a business decision - above $25k a month you have room to hire people and still save money, below that you really strictly do not.
- icebraining 9y ago
  You can't really do that when you're hiring headcount. I'm curious, why not? Can't you do it on a regular basis, like refactoring?
  - jaggederest 9y ago
    Because "refactoring"/"consolidating workers" in headcount means firing people, and that's pretty cruel to do on a pure cost-cutting basis in a small company :)
phatbyte 9y ago
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.
- cjsuk 9y ago
  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 with no investment at all. At this point, the decisions affect your bottom line badly because scaling up customers means an instant cost and geopolitics can mean sudden revenue decreases. You need to plan for a partial success and a partial success can't handle vendor lock in. I'd argue, after spending the last 5 years working with AWS, that the learning curve for locking yourself into a vendor has a zero return as well. One product change and start again. IaaS yes. Anything else, no thanks. Edit: also some of the IaaS providers make standard services that compete with their own products difficult. Look at SES. If you run IaaS in AWS you have to jump through a lot of hoops to run an outbound mail relay. Their solution: just use SES; it's really easy! It's not!
  - dankohn1 9y ago
    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/landscape/CloudNativeLandscape_v0.9.4_cncf.jpg https://raw.githubusercontent.com/cncf/landscape/master/land... (Disclosure: I'm the executive director of CNCF and helped make this image.)
skybrian 9y ago
It seems odd that Google App Engine isn't mentioned, since that's been NoOps for many years before the others came along.
zoltrain 9y ago
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.
_Codemonkeyism 9y ago
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.
seanwilson 9y ago
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 9y ago
  > I can manage a server manually Ansible? Puppet? Chef?
  - seanwilson 9y ago
    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.
Boothroid 9y ago
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.
ai_ja_nai 9y ago
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 9y ago
  > 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.
nostroso 9y ago
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.
CrLf 9y ago
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.
xorcist 9y ago
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.
geekamongus 9y ago
DevOps: "Captain, we need to divert power from the warp core to the forward shields." "Make it so!" NoOps: "Make us go."
holydude 9y ago
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.
m1keil 9y ago
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 9y ago
My favorite example of a NoOps organization https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/ https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/a... . 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.
mdekkers 9y ago
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.
johnpython 9y ago
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 9y ago
  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.
internobody 9y ago
"i hate to break it to you, but you still have to monitor shit in heroku, you knuckleheads."
yellowapple 9y ago
"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.
nunez 9y ago
> NoOps means that application developers will never have to speak with an operations professional again. So basically the exact opposite of DevOps?

52 points by fhirzall 9y ago

"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 9y ago
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.
- keymone 9y ago
  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.
- scaryclam 9y ago
  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 9y ago
  > "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 9y ago
    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 9y ago
      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.
singingfish 9y ago
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/

Turbots 9y ago

Hate to tell this every I see anything "DevOps" related on Linkedin or HN or wherever: There is no such thing as a "DevOps" engineer... DevOps is a culture, not a job description. I'm working as a consultant and every big enterprise right now is looking for "DevOps" engineers. They give their developers and operations people a "DevOps" course, make sure they get their "DevOps" certificate and voila, the enterprise is now doing "DevOps"... WTF?! Some enterprises even say: "Ye, we have 2 DevOpes, so we're cool right?" while they keep doing projects in WaterScrumfall: variable scope, variable budget, fixed deadline sigh

jerguismi 9y ago

Looks like an advertisement piece for their services.

gaius 9y ago
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.

grx 9y ago

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

jaggederest 9y ago

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 9y ago
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 9y ago
  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
- jaggederest 9y ago
  A) you can't B) Nothing in particular It's not about the application or any technical concerns. It's purely a business decision - above $25k a month you have room to hire people and still save money, below that you really strictly do not.
icebraining 9y ago
You can't really do that when you're hiring headcount. I'm curious, why not? Can't you do it on a regular basis, like refactoring?
- jaggederest 9y ago
  Because "refactoring"/"consolidating workers" in headcount means firing people, and that's pretty cruel to do on a pure cost-cutting basis in a small company :)

phatbyte 9y ago

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.

cjsuk 9y ago
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 with no investment at all. At this point, the decisions affect your bottom line badly because scaling up customers means an instant cost and geopolitics can mean sudden revenue decreases. You need to plan for a partial success and a partial success can't handle vendor lock in. I'd argue, after spending the last 5 years working with AWS, that the learning curve for locking yourself into a vendor has a zero return as well. One product change and start again. IaaS yes. Anything else, no thanks. Edit: also some of the IaaS providers make standard services that compete with their own products difficult. Look at SES. If you run IaaS in AWS you have to jump through a lot of hoops to run an outbound mail relay. Their solution: just use SES; it's really easy! It's not!
- dankohn1 9y ago
  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/landscape/CloudNativeLandscape_v0.9.4_cncf.jpg https://raw.githubusercontent.com/cncf/landscape/master/land... (Disclosure: I'm the executive director of CNCF and helped make this image.)

skybrian 9y ago

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

zoltrain 9y ago

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.

_Codemonkeyism 9y ago

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.

seanwilson 9y ago

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 9y ago
> I can manage a server manually Ansible? Puppet? Chef?
- seanwilson 9y ago
  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.

Boothroid 9y ago

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.

ai_ja_nai 9y ago

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 9y ago
> 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.

nostroso 9y ago

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.

CrLf 9y ago

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.

xorcist 9y ago

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.

geekamongus 9y ago

DevOps: "Captain, we need to divert power from the warp core to the forward shields." "Make it so!" NoOps: "Make us go."

holydude 9y ago

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.

m1keil 9y ago

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 9y ago

My favorite example of a NoOps organization https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/ https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/a... . 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.

mdekkers 9y ago

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.

johnpython 9y ago

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 9y ago
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.

internobody 9y ago

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

yellowapple 9y ago

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

nunez 9y ago

> NoOps means that application developers will never have to speak with an operations professional again. So basically the exact opposite of DevOps?