Maybe I'm old school, but I really hope developers give a serious thought before jumping into this vendor lock-in trap.<p>This is specially concerning if not scary, when you start to "outsource" the backend business rules to something like Firebase or other BaaS systems.<p>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.<p>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.
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.<p>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?).<p>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.
"NoOps means that application developers will never have to speak with an operations professional again."<p>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.
I see two problems:<p>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.<p>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).
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.<p>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.
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.<p>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.<p>You <i>are</i> 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.)<p>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.
<i>sigh</i><p>Disclaimer: I'm an ops guy (technically SRE by job title).<p>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.<p>Data life-cycle (backups), capacity planning, incident management, monitoring and KPIs are just some of the items from the top of my head.<p>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.<p>Ops is not only about installing and managing LAMP stacks..
My favorite example of a NoOps organization <a href="https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/" rel="nofollow">https://www.reddit.com/r/cscareerquestions/comments/6ez8ag/a...</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.
I've been saying this for a while.<p>If you are spending less than $25k/mo on Heroku or equivalent, you're not ready to move off it yet.<p>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.
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.
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.
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.
<i>NoOps means that application developers will never have to speak with an operations professional again.</i><p>Unless is is the middle of the night and your site is down. Then you <i>really</i> want to be able to talk to an operations professions. Idiots.
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.<p>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.<p>NoOps as a company wide phylosophy can’t be tenable.
"A few examples of NoOps platforms that fit the above criteria are Heroku, Amazon Lambda, and Google Firebase."<p>I don't know about Lambda and Firebase, but Heroku is <i>not</i> "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).<p>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 <i>much</i> cheaper (and much better at their intended purpose) than the likes of Heroku when you actually do need to scale beyond the prototyping stage.
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.
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.
DevOps: "Captain, we need to divert power from the warp core to the forward shields."<p>"Make it so!"<p>NoOps: "Make us go."
We do move to NoOps in the classical sense, but are not there yet. But serverless is a good step.<p>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.
> NoOps means that application developers will never have to speak with an operations professional again.<p>So basically the exact opposite of DevOps?