"No ops needed". Every time I see such piece of PR I cry a little inside. Sure, spread such things even more, so that everyone around, devs, managers, business take it even more seriously and build more horrible, unsustainable, overpriced, insecure and failing infrastructures and services. No ops needed in the serverless lambda cloud! ;)
Operations always were those guys that kept complaining about "reliability" and "maintainability" and how the perfect thing that worked on my machine woke them up in the middle of the night, and how I must bother with inconsequent things such as "packaging" and "configuration" and "dependencies." Those incompetents, glad to see them gone.
On a serious note, you are absolutely right. IT always had two opposing forces for a reason, it provided balance between change and sustainability. The big problem was lack of communication between the two sides, which "devops" was supposed to solve.
Instead, "devops" is now developers doing what they've always done, and caring for change above all like they always did, but pretending to care about the needs of services in production. I cringe when I think about all those containers where the application is continuously delivered but the bundled openssl isn't updated when vulnerabilities are found. Welcome to the brave new world.
We're moving in a no-ops direction mainly because the most vocal folks come from startups that don't last enough to see where coherent operations matter. They go under well before that. But this idea is bleeding onto companies where it does matter, and we'll see how that goes in a few years.
We started a Devops team at work. After a year there have been 0 Ops hires, it's all Devs.
I think/hope we might see this change soon. Currently there's no real penalty for poor ops. If your customer data gets hacked, there are very few actual penalties, most of the pain is in reputation. I feel like there's been a lot of pressure to have government penalties for poor security practices, especially when so many companies "need" all the user data they can get their hands on.
> After a year there have been 0 Ops hires, it's all Devs.
You say that like it's a bad thing. If you want DevOps to be successful, you don't hire a "DevOps team". You hire a team of devs to make ops tools that are so easy to use that all the other devs can manage their own ops.
The idea is that doing "good ops" is so easy that everyone in the company does it.
You do need at least someone who really knows what "ops tools" need to do, someone with sufficient experience to know the difference between "good ops" and "the first idea some non-ops experience developer had that looked like it solved the problem on his local machine"...
From my (admittedly somewhat limited) experience, an old-school sysadmin (who's likely moved into dev for the better paycheque) is often _way_ better at filling that role thad a more dev oriented person who's done some devops in the past.
In my experience, "good ops" people are the ones with lots of war stories to tell of disasters or narrowly averted disasters either of their own of of friend/colleagues they hang out with. It's a profession who's lessons seem to be best-taught by spectacular failures and heroic recovery efforts, rather than college courses, vendor/consultant training, or "industry best practices" documents...
As I journey through my nascent (6? year) career in a sysadmin role (support previous to that), it strikes me more and more that ops is a craft, like blue-collar trades. You can't become a hot-shot ops staffer by being smart and attending a month of intensives; so much of it is learned through experience (and discussion). I think of myself more as a 'journeyman sysadmin' than a 'midlevel sysadmin'...
Absolutely! I always suggest to young folks who ask how to get into operations that they should set up a linux box and use it as their primary system. There is no better way to rack up your own war stories than trying to use a linux box on a day to day basis.
I agree. My point was that OPs complaint was about not having any ops hires, and I was saying that he shouldn't need any. He can find a crusty old sysadmin who figured out that making their job easier by coding is a good thing. :)
> You hire a team of devs to make ops tools that are so easy to use that all the other devs can manage their own ops.
We used to have people to make those ops tools, we called them ops. The whole devops things seems to be based on the false notion that ops didn't automate their work.
Equating "ops" with "tools" is just another symptom of the problems I was referring to. Tools are not the solution. Tools do not replace process, practice and goals. Tools are just tools.
As a developer, absolutely. You need that kick in the ass from the grumpy old bastard who refuses to setup your queue with a max depth of 1 million, or open up the firewall between the database and the DMZ.
> build more horrible, unsustainable, overpriced, insecure and failing infrastructures and services
This is a bit too much.
I'm not saying that Fortune 500 companies should use DO, but I don't see what's wrong with having a couple of servers for your 50k visitors per month web-app.
Sure "do-it-right" will be hard, but with DO you can literally buy yourself more time until you are able to hire the right people to do that.
> I don't see what's wrong with having a couple of servers for your 50k visitors per month web-app.
It's about context. Your 50k visitor a month webapp doesn't need a load balancer. When you actually need a load balancer, chances are you need someone to deal with myriad other reliability concerns as well.
Well, if you are using VMs and the site cannot afford to go down, then the 50k visitor site does need a cloud load balancer. Individuals VMs can fail anytime. These cloud load balancers can be a part of your HA solution, but yeah.. one also needs to make all other parts of the infrastructure HA (or at least HA-friendly) for this to work as expected, which is not necessarily a simple feat.
I hate being woken at night by emergency calls, so I would prefer to set everyone and everything up with HA solutions.
I have a 100k / month web app, and I have one $10 server for the app, and one for the db on DO. Based off the CPU + disk usage, I'd say I could grow 4x and stay with the same setup. It will be a lonngg time before I need a load balancer.
Either my workload is atypical or people massively overestimate the server power they need.
Except when either your app server or db server go down on a Friday night (sods law implies this will happen on a weekend you're heading out of town).
Now your 100k/month platform is down for 3 days.
You've saved something like $40/month (two additional app/db vms plus a load balancer), but a failure could realistically cost you 1/10th of a month of downtime (which, simplistically looks like $10k). Do you think your platform with two single points of failure is _not_ going to go down like this sometime in the next 5 years?
(Of course, a weekend's worth of downtime might not be a 10% revenue hit - but depending on your SLAs and penalties it's also possible to be a lot more than that...)
The type of companies that create horrible, unsustainable, overpriced, insecure and failing infrastructures and services using cloud systems will create even worse systems with an in house ops team.
You're suggesting that because a company without any experienced Ops staff makes bad decisions about their Infra, if the same company had experienced Ops staff, those staff would somehow make even worse decisions about their Infra?
The GPs logic is that your company either has experienced ops folks or it doesn't, and it will create shitty systems whether cloud-based or traditional if the case is the latter.
What dasil003 said. The type of company making terrible choices with a cloud provider will not hire and empower a good Ops team.
If the company doesn't hire a couple of experienced Ops people to manage their could infrastructure, why do you think they will do a good job hiring a team? You can shoot your self in the foot with any gun. However, one path requires many more choices, more people, and more process to get it right. If they can't get the simpler path right, than what makes you think they will be able to go down the more complex path?
For my experience, the average company with on premises servers with a Ops staff is horrible, unsustainable, overpriced, insecure and failing.
Completely agree. In the last couple of years there has been a push to say that ops are no longer needed and that a dev/engineer can do ops. I've found this to be a fallacy, and while true a developer might be able to use docker, or serverless, they usually have zero idea of the configuration used and no actual in-depth understanding of how these services work and communicate. Thus no idea how to scale or fix problems.
For the last 5 or 6 years, people have been waving their arms saying platforms as a service (Heroku, etc) or containers eliminate the need for servers. Howerver, the cloud server market has only ballooned in size. AWS has continued to explode with huge revenue numbers. Google Cloud is fasty maturing and a threat to Amazon. Azure is competing as well. Servers aren't going away.. Ops aren't going anywhere...
Anyway, I bring up this rant, because I just founded my third startup Elastic Byte (https://elasticbyte.net) which is a DevOps and cloud infrastructure management as a service. If anybody is looking for professional ops to manage their cloud infrastructure (AWS, GCP, DigitalOcean, Azure) I'd love to chat.
One of the things that used to separate "small business" from "big business" was reach. A small business was one that operated within the confines of a region, a town, or a city. They were characterized by being asymmetric in their execution, so they might be a shop with a great sales guy and lousy inventory control, or excellent quality and workmanship but poor management of expenses or receipts. If they were asymmetric enough, it would kill them and they would be one more business that was born, lived, and died.
Now however you can start a business in your basement that has global reach. It's still a small business, and it's still likely asymmetric in its ability to execute, but now it has high visibility. What is more it depends on network infrastructure in order to work.
Everyone wants to be the Microsoft Back Office version of "cloud". Install it, click the defaults, and it provides the infrastructure you need to run your small business.
I get your point, and attitude such as "lol who needs ops, developers can do it" can lead to really shitty situations indeed.
On the other hand, you have developers / small teams who are just trying to get things off the ground and want some basic redundancy and other benefits of load balancing. That's the primary audience of such service, in my opinion.
Sure, you can just spin up HAProxy and even a very basic configuration might do the job. But it's one more thing to learn and maintain, often one more thing to train people to work with, etc. The same can be said about other popular managed services, including Amazon S3, RDS etc. It's a decision you have to make.
So I truly understand your position but I don't think that such sarcastic attitude actually helps anyone.
> I do wish I could drop a Samsung PRO 960 in our database VM though :(
Consider Hetzner if you want high IO at low prices. You'll get "regular" SSDs in their VPSs, but you can get mirrored NVMe SSDs in their bare metal servers [1]. Nothing but great experiences with them. They have APIs to let you automate provisioning of the bare-metal servers if you want to tie it into a larger cloud deployment
