Live data from Hacker News

Rolling your own servers with Kubernetes

gravitational.com

81–90 of 209 posts

Re: Rolling your own servers with Kubernetes

#81
post #61

Earlier 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.

A lot of areas of expertise do go away though. I don't need to worry about the electrical features of the building where I'm hosting servers. No worries about whether I set my automated backups for the prod DB right because RDS makes it trivial. No worries about physical security and having to be anal about site access management or physical segregation between hardware and users. And so on and so forth.

Physical server management is in general a liability and cost center.

Re: Rolling your own servers with Kubernetes

#82
post #68

Earlier quoted context omitted.

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.

Also someone got to put it on their resume... probably someone who didn't have to deal with the headaches ;)

Re: Rolling your own servers with Kubernetes

#83
post #61

Earlier 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, which is what led the massive cloud explosion.

I'd argue that in many cases they do get significantly easier in a cloud environment especially for lightweight setups.

For example, if you run a managed sql database in aws backups are largely handled for you. Upgrades take a handful of clicks and ~5 mins. You dont have to think about patching the underlying operating system.

Broadly speaking, cloud providers give you lots of tools to make things that were fiddly much easier.

Re: Rolling your own servers with Kubernetes

#84

Earlier quoted context omitted.

Running into one of those exact issues (cloudformation stacks getting stuck in really weird states) right now. A real pain in the ass, because I have zero control or visibility into it.

Is switching to Terraform an option?

Based on our own research - probably. But it requires tooling to integrate into a CI/CD pipeline, conversion of existing CF stack definitions to Terraform definitions, and a lossy/downtime laden migration.

For a team with the goals of IAC, hands-off, and high-availability infrastructure, migrating is a pain.

Re: Rolling your own servers with Kubernetes

#85

I 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,…

As an ex big iron commercial UNIX sysadmin, let me tell you; they can do it way better than most sysadmins.

Developing IT policies for physical security, server security, update policies, purchasing, wiring and so on takes a huge amount of knowledge, and the possibility that a middle-of-the-road sysadmin is not only competent at, but excels, in all those areas is literally zero.

Cloud providers have world-class experts in each area whose sole responsibility is providing for their specific area. It's economies of scale at its best. It doesn't mean that it's always the best choice, but having to have someone do full-time server maintenance at no additional value to yourself or customers is just a huge drag.

Re: Rolling your own servers with Kubernetes

#86
post #43

Earlier quoted context omitted.

> spend weeks arguing with AWS support Yup. We've run into that repeatedly. The "we didn't notice anything on our side, please send more screenshots and logs" gets really old when working with "managed services". Network packet losses/truncations, EKS control plane failures, cloudformation stacks getting stuck in really wierd states, inconsistent cloudformation implementations for new and existing services, ENI weird…

Cloudformation is a tragedy in itself.

The idea behind CloudFormation is great, though. Platform-native IAC with promised first party support for all future projects, and backfilling existing services. Plus, it supports deep integrations with first-party supported configuration management services.

The problem is that the reality has not lived up to the promise, and "first party support" means "only the first party can support".

Re: Rolling your own servers with Kubernetes

#87
Some thoughts:

1) Do you really need to invest a million dollars in bin-packing containerized stateless microservices?

2) You don't have to use K8s to get the benefits of rolling your own servers. In fact, I'd argue you should do the latter well before you do the former.

3) Definitely hire someone who has done it before. You will save so much time and money your head will spin.

4) Do not just build a rack full of random commodity gear. Make sure it is suited specifically for your purposes, and then weigh the cost of service contracts and managed colo against a $100k+ cage monkey on call 24/7.

5) Do not fall for the "We've got , we don't need redundant hardware!" lie. The more parts of your system rely on lots of hardware, the more fragile your system becomes. Distributed decentralized services become a PITA when the underlying gear is flaky, and centralized services require it. Do not underestimate the shittiness of your colo; always design for the most redundancy you can get for what you have. If you can run dual power, do it. Dual network stacks, do it. Redundant disks, do it. Remote management, do it. Outside modem to a management port on the router, do it. Always be postponing entropy. Later, when you become a FAANG (yeah right) you'll have the time and money to automate away some of the redundancy issues.

6) It's sometimes harder to upgrade disk or bandwidth on an existing machine than it is to just buy another machine, but the more machines you have, the more problems (and overhead costs), and there is an upward limit on the scaling of most services without rebuilding them. So buy big on local disk and network, and buy new machines to expand cpu and memory. The redundancy and performance issues inherent to SAN/NAS often make local disks a better choice, as they are unlikely to impact your whole network at once, you can fix/upgrade them piecemeal, and they are less difficult to manage/operate.

7) Don't DIY critical components such as data replication; it's surprisingly hard. In fact, don't even believe vendors if they claim they can solve X for you with some magic software or hardware. Get them to show you a live demo on your own network.

8) Don't forget that in 3 years you'll be replacing it all.

Re: Rolling your own servers with Kubernetes

#88
So before we had an IT team that would maintain the bare metal servers. Now we need "Cloud Engineers" to maintain the cloud infrastructure working properly. I don't know if the argument of externalize the maintenance of the servers is valid since the complexity of the cloud services is just increasing everyday.

Re: Rolling your own servers with Kubernetes

#89
post #53

>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…

Back then you basically had to do it, so everyone did. These days you have to compete with companies that make use of the flexible offerings of AWS/GoogleCloud/Azure. Which for small companies is a large advantage, since it makes it possible to start up with almost no money, and scale up smoothly, while letting your employees be focused on the product you offer for your customers.

Re: Rolling your own servers with Kubernetes

#90

isn't this what they all sell nowadays? A prettier UI on top of kubernetes? - Kubermatic by loodse - rancheros - even mesosphere is kinda that now, except the first two are opensource, but definitely not the only solutions I personally deploy kubespray here and there, but I would still recommend smartos for normal humans, unless they want to setup an elk + kafka cluster or whatever else you might want to do.

upvoted for triton+smartos - hear hear
Post reply on HN