Gitlab has decided not to go bare metal after community feedback. Pretty cool to see the company listening to the community for such a large financial decision!
Gitlab has decided not to go bare metal after community feedback. Pretty cool to see the company listening to the community for such a large financial decision!
GitLab decided to change a large decision based entirely on the assertions of random people on the internet? None of their extracted quotes have actual evidence behind them. This is not how I’d like companies to make technical decisions.
Good they made a decision, and good they did listen and act on feedback.
About their choice I get the feeling from the comments that most of them equate “bare metal” with buying your own servers and biking to a datacenter when something broke. But there are plenty of providers which rent out machines per month, and where you can get your own physical internal networks. When something broke you have their engineers fix things, and you don’t have to go there. You can choose the location based on Internet topology, not on physical location close to you. For me (or, for where I work), this is a nice middle ground. We get good performance for really not much money. Our load is very predictable though, so we don’t need the great scaling flexibility you get with temporary servers, and now we also don’t have to pay for that flexibility we don’t use.
This is a point lots of people seem to miss - almost on purpose.
The host I generally use will let you configure custom builds for new hardware that you’re going to rent, and can configure it to use their xen management system, so you can use their Api (or control panel) to spin up new vms on your “own” hardware, or spin up temporary ones on shared hardware.
Honestly though the more concerning trend is with people who somehow equate “the cloud” with “I don’t need ops staff”
Which is extremely weird seeing that especially AWS (as a product) is more like a toolbox with almost no ready-made solutions.
To be fair, some cloud platforms (e.g. AppEngine) really do mean you don’t need ops staff.
Sure, Heroku the same. That’s where the high cost comes from.
Although I’d say that they also reach the level where you need dedicated staff for keeping the environment in order.
Sounds like ops to me.
No, we fired our ops staff. We’ll make the developers do it. We'll… I know, we’ll call it “DevOps”!
I have heard that exact argument, that it’s cheaper because now your developers can just do it, and you already have them, rather than needing to also employ separate sysadmins. I guess this assumes that your developers have a lot of free time.
Okay, genuine question coming from a young'n: what exactly is the relationship between “DevOps” and “Ops”? I always thought it was “DevOps is developer and product infrastructure, which is a subset of Ops”. But it sounds like that’s incorrect, or it’s theoretically the case but you’ve seen it go horribly awry in practice.
In an ideal world, it’s the recognition that development and operations are intimately tied together, that infrastructure (especially in the cloud world) is “soft”. It’s a cross-functional discipline that ties development and operations together.
In practice, it’s, “We fired everybody who understand infrastructure because our developers do that now.”
DevOps is a buzzword just like “cloud”
What does “cloud” mean? Does it mean something like Dropbox; iCloud; Google Mail/Drive/etc? Does it mean AWS/Google Cloud/Azure?
DevOps has at-best been described as either:
Ops, using development-like concepts i.e. things like configuration as code, allowing for automated provisioning etc.
Developers and Ops working more closely together.
In reality, it mostly seems to mean “Fire the ops, Developers can do it now, because AWS has an API”. This has literally led to me being asked by a poor developer who got stuck with the task after I’d left: “How do I install this SSL cert”.
She’s a fine developer, and I’m sure she is capable of learning whats required. But you do not want to be relying on someone with obviously zero experience in Ops, with only the guy who just left as “backup” when things go to shit.
Note that ops “automating” things isn’t a new concept that Infra/Ops staff never knew about before “DevOps”. I still remember automating the migration of a couple thousand workstations between Novell eDirectory trees. This basically meant, uninstall the Novell client and ZENworks (the one piece of software you have to allow remote-control, so if it breaks half-way through, you need to be physically in front of it to resolve it), and re-install them with the new settings. The “city” teams did this all by hand, every step of the way, with probably a dozen people on-site to do the work, 1 campus per weekend. In the outer metro and country sites, we did it with just two of us, and a couple of battle tested, infinitely tuned batch files. Our process allowed us to migrate 10 remote (as in, no-one at all on-site, just a bunch of PCs turned on) sites in one weekend, over ~64-256kbit ISDN/similar lines.
In my experience “doing DevOps” for the last, er, four or five years:
it’s entirely up to the company that hires you.
The theory is that DevOps means integrating the development of software with delivery (QA and release) and ongoing operation of the software.
In practice, it can vary from:
to the utopia of realizing that software is best owned from design to deployment to release and maintenance.
Pick your poison, I guess.
Yeah, in some sense it is, but with “ops” being such an extremely fuzzy term to begin with…
I don’t think Ops is that fuzzy, when compared with terms like “Cloud” and “DevOps”.
Ops, as in, Operations to me is just the internal name IT Shops give, to what would normally be “The IT Department” in a non-IT shop. In practice, Ops in a software company probably aren’t doing desktop support for internal users, but they’re basically managing environmental resources: servers & the services they provide, storage, networking, etc.
If your “cloud platform” requires someone to “manage” it, then they’re still doing Ops, regardless of what their title or experience is. If your “cloud platform” doesn’t require someone to manage it, I suspect that either your app is not much more complex than “hello world” or you’re using the platform wrong.
[Comment removed by author]
Do you have a reference on this? I checked their site and it looks like they hire a lot of ops.
[Comment removed by author]
Any sufficiently complicated NoOps system contains an ad-hoc, bug-ridden, slow pile of scripts that implement 1% of the common ops workflows.
The thing about AppEngine is that it’s not complicated. It limits what you can do but if you stay within those limits you really don’t need ops.
So, its basically managed hosting, which has existed for ~20 years in the form of shared web hosts.
No, it’s nothing like that. It provides automatic scaling with traffic.