If you get to build your own servers why torment yourself with a 2-socket solution? It's just harder to program with no benefits. A single-socket UMA solution will be more than large enough single nodes and a lot easier to program and manage.
Rolling your own servers with Kubernetes
71–80 of 209 posts
Re: Rolling your own servers with Kubernetes
#72I use to enjoy having a cheap desktop under my table or in a closet serving traffic to people across the internet. Computers have gotten faster, software has gotten better, network has gotten faster, things have gotten cheaper. Sadly instead of seeing more of these, most of these are now being outsourced to cloud providers, we have bought and drank the kool-aid that they can do it better and cheap. Which is not true,…
Looking at Knative to mature in a couple of years and with it on top of k8s we may see a slow migration back to self-hosting where it makes sense
Re: Rolling your own servers with Kubernetes
#73Earlier quoted context omitted.
> The hardware was getting cheaper each year. More software became available via open source. Then several ubecorporations entered the hosting/cloud business, and suddenly no one seems to be able to afford their own infrastructure. That conspiracy theory depends on not asking about the major costs areas you left out (e.g. ops, security, reliability) which are the most significant until you're at a fairly large scale.…
Ops, security, and reliability don’t go away when using EC2 either, which is what led the massive cloud explosion. Places switched because they didn’t like having to forecast capacity so hourly billed resources turned on and off at the drop of a hat were super attractive.
> Ops, security, and reliability don’t go away when using EC2 either
They don't go away, but you have to spend considerably fewer resources on it because Amazon does a lot of it for you.
Edit: This effect is even more pronounced when you use Amazon's more specialized managed services, like S3, RDS, Lambda, etc. Then the things you mentioned almost completely go away, as you're letting Amazon completely maintain your infrastructure.
Re: Rolling your own servers with Kubernetes
#74Earlier quoted context omitted.
If you have a well-built and automated bare-metal deployment, it's no harder than switching cloud providers. At the scale where it makes sense to go bare metal, either would be a lot of effort. An extra abstraction layer like k8s makes it a lot easier, which is exciting. It's also precisely why IBM bought Red Hat - a well-built k8s distribution like OpenShift is one of the very few real alternative to public clouds f…
> An extra abstraction layer like k8s makes it a lot easier, which is exciting. It's also precisely why IBM bought Red Hat - a well-built k8s distribution like OpenShift is one of the very few real alternative to public clouds for many companies. OpenShift is built on a prescriptive mentality. They choose everything for you from OS through pipeline and many deviations are unsupported. As you mentioned there are other…
Openshift doesn't choose the pipeline. You can deploy to it however you want. Openshift is literally the same exact thing as kubernetes, with a simpler api and a nice ui. Openshift is extremely flexible and you can use it however you want. Don't know why you think it's so restrictive.
Re: Rolling your own servers with Kubernetes
#75The article seems to focus on K8s with reference to micro-services. How well does K8s do if you're running a monolith?
Using kubernetes without microservices is like using hadoop on a 1000 row csv file
I don't know if that's a fair comparison. If you deploy a monolith you have to set up a custom multi data center deploy and manage all the load balancing/disaster recovery/volume management(databases) yourself. Kubernetes isn't that hard to setup and gives you out of box solutions to all that.
It also gives more flexibility on adding additional services around your monolith. Elk stack, kafka, that kind of stuff. Also gives you a standard api to deploy against. I don't think your metaphor holds up.
Re: Rolling your own servers with Kubernetes
#76I use to enjoy having a cheap desktop under my table or in a closet serving traffic to people across the internet. Computers have gotten faster, software has gotten better, network has gotten faster, things have gotten cheaper. Sadly instead of seeing more of these, most of these are now being outsourced to cloud providers, we have bought and drank the kool-aid that they can do it better and cheap. Which is not true,…
I don't think cost is the benefit of cloud. For tech companies the benefit is scale (you won't know how popular a product is until you deploy). For non-tech companies the benefit is not having to deal with things that aren't related to your core business.
I think you can argue that tech is always related to your core business and you only need a few servers to handle a million simultaneous users but those kinds of arguments aren't usually good enough to businessmen or entrepreneurs.
Re: Rolling your own servers with Kubernetes
#77I use to enjoy having a cheap desktop under my table or in a closet serving traffic to people across the internet. Computers have gotten faster, software has gotten better, network has gotten faster, things have gotten cheaper. Sadly instead of seeing more of these, most of these are now being outsourced to cloud providers, we have bought and drank the kool-aid that they can do it better and cheap. Which is not true,…
How does it work with the consumer ISP? Can you elaborate on any special considerations? Obviously not for customers, but I'm interested for it as a hobby thing.
Re: Rolling your own servers with Kubernetes
#78Earlier quoted context omitted.
How is that related to bare metal vs. clouds? That could have happened on either.
Big cloud providers or some big VC backed companies have the resource to figure out the issues by wrestling with the gigantic and unyielding vendors, or by working around it with their engineering resource. Not many teams have the time for even wanting to understand the issues. This is not an inherent problem of bare metal, but one aspect to consider if you were to choose the path. But you are right, cloud providers…
Except they won't. Not for an esoteric or exotic bug that doesn't affect 99.9% of their customers. Unless your businesses contract costs more than that team of technical and engineering resources(Eg your Netflix et al), it's not worth their time to bother looking into it.
All that assumes they even admit the issue is their hardware not your code, which is a mighty big assumption itself.
Re: Rolling your own servers with Kubernetes
#79>Should you roll your own servers? If you are not certain, the answer is most likely “no”. The staggering growth of AWS happened for a reason. Funny how for many decades companies and people were running their own servers. The hardware was getting cheaper each year. More software became available via open source. Then several ubecorporations entered the hosting/cloud business, and suddenly no one seems to be able to…
I worked in a shop that had dedicated lab equipment and resources. Suddenly buying new equipment that we would use for years became like pulling teeth, no money they said. They couldn't explain what changed. Then just as suddenly they were willing to approve spending more than our one time equipment purchase... per month in monthly cloud costs / some poorly thought out cloud deployments.... Result: -1 Dedicated perso…
Sure, but the accountants got to move it from capEx to opEx and then everyone went out for a beer.
Re: Rolling your own servers with Kubernetes
#80>Should you roll your own servers? If you are not certain, the answer is most likely “no”. The staggering growth of AWS happened for a reason. Funny how for many decades companies and people were running their own servers. The hardware was getting cheaper each year. More software became available via open source. Then several ubecorporations entered the hosting/cloud business, and suddenly no one seems to be able to…
>The hardware was getting cheaper each year. More software became available via open source. Then several ubecorporations entered the hosting/cloud business, and suddenly no one seems to be able to afford their own infrastructure.
The decision framework the executives use isn't just the "hardware+software" -- it's the whole "IT organization".
In other words, it's not "in-house cpu" vs "Amazon's cpu". It's in-house IT employees' speed of tech innovation vs Amazon's engineers'. An example of this disparity was Guardian's disaster with its in-house organization trying to use OpenStack.[1]
For many non-tech companies where IT computing is a cost center, their employees won't be able to match the iteration speed of Google's engineers constantly improving on GCP or Amazon's employees enhancing the features of AWS.
We've all heard the stories where a company's project submits a requisition to internal IT department for 2 development servers for their programmers -- and then the IT bureaucracy tells them that it will take 2 weeks. Over time, the internal IT dept treats the other departments as adversaries instead of customers. Executives get fed up with slow IT departments and get excited when a few clicks on AWS dashboard gets them servers spun up in 10 minutes. It's not just a cpu+hardware comparison.
Companies outsource to AWS/GCP/Azure because it's quicker turnaround with more datacenter features than their internal IT teams can deliver. Most companies are not like Facebook or Dropbox that can maintain an internal IT organization at a high level equivalent to AWS.
[1] https://www.computerworlduk.com/cloud-computing/guardian-goe...