Do We Need to Learn Linux?

  • Sean Redmond,

    Here are couple of options for online training that I would recommend.

    Option 1:

    Linux full course: (YouTube) about 7.5 hours using Ubuntu, Zorin, etc.

    Link - The Complete Linux Course: Beginner to Power User! - YouTube

    Option 2:

    Linux crash course: (Udemy) about 13.5 hours focusing mostly on CentOS

    Link - https://www.udemy.com/course/learn-linux-in-5-days/

     

    So, it would depend on whether you want to take the Red Hat path or the Debian or even one of the other options such as Arch, Suse, etc.

    Either one (Red Hat or Debian) will be about the same, "generally speaking" it’s just a matter of using Yum or apt \ rpm or deb commands \ packages respectively for Red Hat and Debian.

    As for the real world difference between the two paths, the Red Hat path (Red Hat, CentOS, Fedora, etc.) are "more commonly seen" in the industry side, NASA, Dell Computers, IBM, etc. while the Debian path, (Ubuntu, Linux Mint, Zorin, etc.) are more commonly used by the end-users on their personal home PCs \ laptops.

    Please note the emphasis on "generally speaking" and "more commonly seen". It's not to say that the Red Hat line is only used in the industry and the Debian line is only used on the personal PC side, quite the opposite, I have seen both OS lines on both sides of the computer world.  These statements are just a generalization.

    Hope that helps.

    • This reply was modified 2 years, 9 months ago by  Aubrey Love. Reason: Clarifying the links

    Aubrey W Love
    aka: PailWriter
    https://www.aubreywlove.com/

  • For a Windows shop, is there any practical benefit, like in terms of licensing costs or performance, for running SQL Server on a non-containerized Linux instance? For example, could anyone sell me on the idea of migrating our data warehouse or dozens of development databases to Linux?

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric, to make the discussion interesting, I'll outline benefits of modernizing your process on Windows:

    1. Windocks Windows SQL Server containers are delivered as named instances, so maintain all the compatibility you're accustomed to, while these isolated environments are delivered and replaced in seconds.   You can consolidate existing instances onto a single VM with containers, and 1) reduce VMs used by up to 10:1, 2) provide dev/test self-service access to their own isolated containers, 3) reduce instance maintenance, and 4) open up improved automation for CI pipelines and even Kubernetes orchestration.   Also, these containers are simply named instances  and are covered by your existing SQL Server licenses (no added licensing is needed).
    2. When paired with database virtualization, you can serve up versioned data warehouse environments in seconds, with each requiring only 40 MB of storage, for either conventional Windows SQL instances or containers.   When Salesforce and other apps are being updated, it simplifies pre-release testing.

    Net, net, you can gain the "cloud native" benefits of Linux (containers, etc.), with Windows.   The benefits of containers doesn't require DB virtualization, or vice versa.  You can apply DB virtualization for containers and your existing instances.

  • Eric M Russell wrote:

    For a Windows shop, is there any practical benefit, like in terms of licensing costs or performance, for running SQL Server on a non-containerized Linux instance? For example, could anyone sell me on the idea of migrating our data warehouse or dozens of development databases to Linux?

    Migration, not sure. Cost, the OS cost is cheaper, but that might not matter. Licensing cost advantages could disappear quickly if staff can't solve problems quickly or needs to learn.

    I don't know I'd even try to sell anyone on converting. For the future, especially if you implement something like Big Data Clusters, which might fit a warehouse, the the cost of Linux OS v Windows might make a difference. The perf stuff is generally the same, from what I've seen. No great difference either way.

  • Thanks for this Steve & pailwriter.

    This will keep me occupied for a while.

    • This reply was modified 2 years, 9 months ago by  sean redmond.
  • <forgot to add the quote, is there an easy way to delete this?>

    412-977-3526 call/text

  • pauls 72822 wrote:

    Eric, to make the discussion interesting, I'll outline benefits of modernizing your process on Windows:

    1. Windocks Windows SQL Server containers are delivered as named instances, so maintain all the compatibility you're accustomed to, while these isolated environments are delivered and replaced in seconds.   You can consolidate existing instances onto a single VM with containers, and 1) reduce VMs used by up to 10:1, 2) provide dev/test self-service access to their own isolated containers, 3) reduce instance maintenance, and 4) open up improved automation for CI pipelines and even Kubernetes orchestration.   Also, these containers are simply named instances  and are covered by your existing SQL Server licenses (no added licensing is needed).
    2. When paired with database virtualization, you can serve up versioned data warehouse environments in seconds, with each requiring only 40 MB of storage, for either conventional Windows SQL instances or containers.   When Salesforce and other apps are being updated, it simplifies pre-release testing.

    Net, net, you can gain the "cloud native" benefits of Linux (containers, etc.), with Windows.   The benefits of containers doesn't require DB virtualization, or vice versa.  You can apply DB virtualization for containers and your existing instances.

     

    What are the downsides of your approach?

    412-977-3526 call/text

  • Fair question Robert!   I think the limitations fall into three buckets:  1)  Windocks SQL Server containers are aimed to address dev, test, and DevOps needs, and we've not invested in DR/HA support, although this is on our roadmap.    2)  Our customers plan to stick with VM based production environments, with Always On Availability Groups.   Containers are used to facilitate dev/test support for  Kubernetes hosted front-end and mid-tier apps.   Windocks supports Windows SQL Server containers on Kubernetes via a SQL Proxy service, with the Windocks Windows server running externally to the cluster.    This approach works well, and allows Kubernetes to orchestrate and manage the SQL Server environments.  I don't view this as a negative per se, but want to call it out for completeness.    3)  The chief benefit of containers are speed of environment delivery, and server density (with up to 50 or more on a single VM), which works well for dev/test scenarios.   For performance testing and ETL processing, jobs should be scheduled when compute and IO resources are available.   Performance testing and ETL jobs are certainly supportable, but performance calls for a period when fewer containers are contending for shared resources on the server.

  • Eric M Russell wrote:

    For a Windows shop, is there any practical benefit, like in terms of licensing costs or performance, for running SQL Server on a non-containerized Linux instance? For example, could anyone sell me on the idea of migrating our data warehouse or dozens of development databases to Linux?

    For me, the answer is "Yes"... it would give me incentive to retire that day.   It would also allow me to express the alternate and very colorful meaning of "FTP". 😀 😀 😀

     

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 9 posts - 16 through 23 (of 23 total)

You must be logged in to reply to this topic. Login to reply