back to article GitLab to dump cloud for its own bare metal Ceph boxen

Git repository manager and developer playground GitLab has decided it is time to quit the cloud, joining Dropbox in concluding that at a certain scale the cloud just can't do the job. GitLab came to the decision after moving to the Ceph Filesystem, the new-ish filesystem that uses a cluster running the Ceph objects-and-blocks- …

  1. Pascal Monett Silver badge

    So, the Cloud is starting to leak

    I'd love to go on a sarcastic rant about how Manglement is Doing It Wrong Again, but the simple reality is that the Cloud can benefit if one knows exactly why one is intending to use it.

    With GitLab, the pros and cons have clearly been extensively studied and the decision made on facts, not marketspeak - which is hardly surprising from a group of computer nerds for whom I'm betting marketspeak does not impress.

    So this is not really a failure of the Cloud, just a victory for Reason Over Marketing.

    I do find the conclusion very interesting though : paying for sub-par performance because time-share.

    That's a point I'm going to have to add to my list of arguments against.

    1. Ole Juul

      Re: So, the Cloud is starting to leak

      "the simple reality is that the Cloud can benefit if one knows exactly why one is intending to use it."

      Marketing has trouble understanding that what they're selling isn't the best solution for everything. Hopefully these prominent examples will filter into management culture and help get some sanity into the cloud craze.

  2. Mage Silver badge
    Big Brother


    The Cloud owners have to make profit every month and have ongoing overheads.

    A server is always going to be cheaper to buy (for a year) if the Cloud is making money. The actual real cost of both solutions is more complicated.

    Cloud is OK for cross site collaboration, if you have your own local backups. Assuming issues of privacy and security are sorted (those are often unclear for the Cloud).

    Cloud = Server of someone else, out to make profit.

    1. thegroucho

      Re: Cloud

      One size certainly does not fit all.

      However it is not just how much a server costs, that is very simplistic view (a general case, not necessarily discussing GitLab here):

      Cost to procure the server (the procurement process takes time = money).

      Time to get the server to be delivered.

      HW support contract.

      Cost to physically install the server with associated DC, rack, network, power and cabling costs. Never mind the technicians performing the above needing salary.

      Put together some orchestration system. (OK, one is needed in 'cloud' (eugh, I used the word) environment, however it will be using bunch of APIs).

      Cost of storage subsystem (that can easily go into tens of millions depending on scale required).

      Cost to repeat above in different locations and pay for the storage and network connectivity between sites (assuming stretched metro cluster, I agree Ceph is different animal).

      On the other hand properly done public 'cloud' (eugh, I said it again, maybe should use equally disgusting 'hyperscaler'):

      Adding the ability to scale as and when needed on demand.

      Security model which is better than what most outfits can do.

      OPEX which most FDs love as oposed to CAPEX.

      This will work for most businesses, however to repeat one size will not fit all.

      Of course YMMV.

      1. Anonymous Coward
        Anonymous Coward

        Re: Cloud

        > OPEX which most FDs love as oposed to CAPEX.

        Spot on, as the rest of your analysis.

    2. Voland's right hand Silver badge

      Re: Cloud

      A server is always going to be cheaper to buy

      If and only if you are loading it above a certain break even point.

      Cloud is cheap when you have a trickle of requests. It is also cheap when scaling your system initially before you understand the user demands and scaling requirements.

      Once you know your load and if it is high enough to justify a dedicated server you are likely to find a dedicated server more cost effective. The same goes for various use cases requiring Nx servers.

  3. nematoad Silver badge


    "...would you clouds chase every use case..."

    Apart from my difficulty in parsing the statement quoted, my answer would be: Probably. Because when all you have is a hammer, then everything looks like a nail. Once again it's horses for courses and one size does not fit everyone.

    1. Anonymous Coward
      Anonymous Coward

      Re: Because.

      >> "...would you clouds chase every use case..."

      > Apart from my difficulty in parsing the statement quoted, my answer would be: [some cliche]

      And my answer would be "ALL YOUR BASE ARE BELONG TO US", which is equally applicable to the original sentence and more in line with it from a grammatical point of view.

  4. Charlie Clark Silver badge

    "pay for what you provision"

    IO is always the biggest problem with any virtualised environment and why cloud solutions are sold on CPUs, memory, disk size, bandwidth, anything but the IO speed and VCS systems are known to hammer IO.

    So, it's a classical trade-off which is why some businesses are happy not managing their own data centres because they have extremely variable capacity. The various providers also offer differing solutions.

  5. John Smith 19 Gold badge
    Thumb Up

    So the takeaway is

    1)Cloud is good for fast starting an application.

    2)Some applications (mostly with high IO counts) scale really badly. They should be run on their own servers.

    So cloud --> good early development environment. May be OK operating environment. Or not.

    The DevOps equivalent of "Premature optimization is the root of nearly all evil"?

    Good to know. But aren't most databases quite heavy on both I/P and O/P ?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022