It seems odd that Google App Engine isn't mentioned, since that's been NoOps for many years before the others came along.
The Best DevOps Is NoOps
11–20 of 66 posts
Re: The Best DevOps Is NoOps
#12Looks like an advertisement piece for their services.
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.
Re: The Best DevOps Is NoOps
#13I'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.
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?
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
Re: The Best DevOps Is NoOps
#14Maybe 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 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!
Re: The Best DevOps Is NoOps
#15Maybe 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…
Cloud services don't save you money, they buy you focus.
There are very little companies today that need custom buildouts, but that doesn't mean we shouldn't keep an eye on portability.
Re: The Best DevOps Is NoOps
#16I'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.
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?
Re: The Best DevOps Is NoOps
#17Maybe 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 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.
Re: The Best DevOps Is NoOps
#18"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…
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…
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.
Re: The Best DevOps Is NoOps
#19It 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.
Re: The Best DevOps Is NoOps
#20"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…
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 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.