51–60 of 209 posts
Earlier quoted context omitted.
The cost of shiny new tech. "Hey look at all these cool things you could / can do that would lower costs and do other cool things." Weeks or months later you're still learning about how you do the thing that will maybe lower costs and do cool things ....
Meanwhile the market and mindshare has moved on to the next shiny new tech.
Earlier quoted context omitted.
In my last team, our team suffered from a CPU bug and a SSD bug that caused painful debugging nights. We used multithreading heavily, and it could have been library/kernel issues or some bugs in our code, which cover massive amount of potential target code that needed to sort through initially. I don't think small companies can afford such gigantic debugging effort, so either they should rely on their luck (or flaky…
How is that related to bare metal vs. clouds? That could have happened on either.
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 afford their own infrastructure.
Earlier 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…
The article seems to focus on K8s with reference to micro-services. How well does K8s do if you're running a monolith?
All of the following assumes you plan on running more than a single instance of your monolithic application. If that's not the case, then ignore Kubernetes, and be glad you don't have the problems it was designed to solve. If you consider what it takes to manage the end-to-end lifecycle of a single application, monolith or micro-service, you need a solution for the following items: deployments, application configurat…
The rest seems reasonable, but I disagree strongly with that claim. If it's worth using the tool then it's also worth learning how it works.
Even just kubespraying a cluster myself helped me build a much stronger mental model of how Kubernetes works than trying to take over a colleague's black box Kops setup. GKE or another managed service would have been even worse.
Setting up a small cluster isn't that hard, and it will teach you a lot about the internals and how things can go south (and what to do when that inevitably happens).
>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…
Who exactly is saying that no one can afford their own infra anymore?
What some people say is that cloud is usually cheaper than running your own infra. They may be wrong (I'm doubtful myself), but it's a wholly different argument.
I am curious to see how they recommend handling storage on bare metal k8s.
These days I usually recommend that any data an app wants to persist be written to an object store or database.
And that any app that needs to write critical data to a disk should be provisioned with config management on bare metal (or pods statically assigned to machines with attached storage if K8s is a must).
This is mostly due to how tough the problem of storage is on K8s, and how much is at risk when it goes south.
>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…
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, perhaps this is why it's so hard to find good unix and network admins these days.
>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…
It's kinda annoying how the valid criticism of cloud solutions is getting drowned out by criticism on strawmen. Who exactly is saying that no one can afford their own infra anymore? What some people say is that cloud is usually cheaper than running your own infra. They may be wrong (I'm doubtful myself), but it's a wholly different argument.