4 ms·

Sometimes there's value in building bespoke solutions. If you don't need many of the features of the off-the-shelf solution, and find the complexity overwhelmin

by imiric 4y ago

Sometimes there's value in building bespoke solutions. If you don't need many of the features of the off-the-shelf solution, and find the complexity overwhelming and the knowledge and operational costs too high, then building a purpose-built solution to fit your use case exactly can be very beneficial. You do need lots of expertise and relatively simple applications to replace something like k8s, but 37signals seems up to the task, and judging by the article, they picked their least critical apps to start with. It sounds like a success story so far. Kudos to them for releasing MRSK, it definitely looks interesting. As a side note, I've become disgruntled at k8s becoming the defacto standard for deploying services at scale. We need different approaches to container orchestration, that do things differently (perhaps even rethinking containers!), and focus on simplicity and usability instead of just hyper scalability, which many projects don't need. I was a fan of Docker Swarm for a long time, and still use it at home, but I wouldn't dare recommend it professionally anymore. Especially with the current way Docker Inc. is managed.

skor 4y ago
> wouldn't dare recommend it professionally anymore please provide more insight, thanks
- worldsayshi 4y ago
  It seems a bit confusing. Here's some context: https://github.com/docker/roadmap/issues/175 https://github.com/docker/roadmap/issues/175
  - jacooper 4y ago
    Doesn't seem to change anything though? Swarm is still alive and well?
    - worldsayshi 4y ago
      Yeah I'm a bit surprised to hear that. I had only heard a lot of teams giving up swarm when it was deprecated. Didn't know they just restructured the project.
      - jacooper 4y ago
        Yup its crappy communication from docker, the ticket is asking for clarity to put an end to the swarm is dead meme. Even mirantis is back supporting swarmkit and adding new features.
kobalsky 4y ago
> and focus on simplicity and usability instead of just hyper scalability I don't get why people in IT need a boogeyman. Looks like "k8s is hard" is the new "pointers are hard" we use to scare other people now.
- imiric 4y ago
  That's not a great comparison, but it works in a sense. Not all languages and applications benefit from pointers. The issue is not about k8s being hard. Yes, it has a steep learning curve, but many technologies do. The issue is that learning all of its intricacies, and maintaining it and the services that run on top of it, requires valuable resources many companies don't have, especially early on. And the benefits it provides are, for the most part, not needed early on in a project's lifecycle, and often never. In financial terms, it's very high risk, with low ROI. If there's a solution that lowers the investment and maintenance costs, while being valuable in the short and long term, then that's generally a more favorable solution for most projects that don't operate at Google's scale.
  - IOT_Apprentice 4y ago
    There is the learning curve, which can be challenging for organizations that aren’t experienced or exposed to scale and performance expectations. When a company moves away from being insular & proprietary to using open source there is a period of churn that ripples through the deployment, implementation and day to day operations aspect of products that live either on customer premises or a cloud platform new to everyone. There, what YOU know from experience and have evolved and worked through is unknown—because it is all new. And “training” (such as it is) is left as an exercise for each individual. I’d expect that is the norm for the traditional non startup firms, globally.
- chillfox 4y ago
  There is a very big difference from being a user of K8s and being someone maintaining a K8s cluster. If you are a user of K8s, then yeah, deploying apps is pretty simple most of the time. Maintaining a K8s cluster on the other hand becomes very complex and hard the moment you have use cases that are a few steps off the happy path. The K8s documentation is not sufficient for operating a K8s cluster on your own hardware, you end up having to go spelunking in the code to see how things work (this is from experience).
mikepurvis 4y ago
I'm happy with my usage of k8s, but I think it's unfortunate that current container abstractions are so oriented around imperative assembly in "layers". I want a way to run NixOS in a container and have it feel first class— existing approaches either require installing everything every time with no caching, or pre-building and manually lifecycling your container (streamLayeredImage), or knowing upfront what you're going to need (Nixery).
xp84 4y ago
> simplicity and usability instead of just hyper scalability This is such a key phrase here. If I'm starting a small SaaS company tomorrow, my ideal for setting up infrastructure would be a stack which can for now look similar to what this article sets up (especially with the tremendously lower bills), but with an easy migration path to k8s, should I hit the jackpot and have that 'very good problem to have' of too many customer requests to handle. My big issue with k8s, and honestly with other big fancy toolsets, is that getting started with it requires you to choose between: - Hire several seasoned cloud orchestration experts, preferably with the platform you've chosen (AWS, GCP, Azure) who will know how to troubleshoot this beast when you have a mysterious issue, or: - YOLO it! Just follow the basic tutorials to set k8s up, and hope you don't end up sitting up all night with a site that's refusing connections while your customers flee. The first one is the only responsible choice but it's going to add another half million to your cash burn, and that's on top of the high-margin "managed" service cloud bills like RDS. So I can see why people are drawn to a system where instead of paying for k8s and "Postgres in a box" they can pay for a simple server and have simple tooling to deploy, back up, etc.
wankle 4y ago
> Especially with the current way Docker Inc. is managed. I was reviewing GCP's Free Tier today, they have the same approach, if they need to change or drop services they agree to give 30 days notice, same as Docker did. It's probably common for other cloud companies offering free stuff as well. All the negative attention Docker received was fully and wholly undeserved.
- ericb 4y ago
  > I was reviewing GCP's Free Tier today, they have the same approach Google is notoriously bad about this and gets negative attention from it, so the comparison isn't favorable, and the publicity is still wholly deserved.
  - rschoultz 4y ago
    >> I was reviewing GCP… > Google is notoriously bad at this… Do you mean Google or GCP? We don’t see complaints about AWS because Amazon closes Dash buttons or Spark, and also Azure is not seen in any worse light due to Microsoft discontinues Skype and what not. Can we name one remotely popular service of GCP that has been shut down at all?
  - wankle 4y ago
    I can't think of a single incident where GCP actually dropped a free tier; I actually see new free tier stuff added since the last time I looked. If you can provide some excellent links to reflect your view, that I've somehow missed along the lines; it would be interesting to compare. Until then, I maintain the Docker publicity is undeserved and if I had to guess, was brought on by podman astroturfers who have been polluting the web the past 2 years claiming how great podman is.
jameshart 4y ago
I think people overindex on thinking that Kubernetes is about scalability. Honestly, its inbuilt horizontal scaling systems are pretty lacking. Scaling is not actually K8s's strong suit - sure, you can make it scale, but that takes effort and customization. But what K8s, at base, is actually useful for is availability. You tell K8s how many instances of a thing to run; it runs them; if any of them stop running, it detects that and tries to fix it. When you want to deploy a new version, it replaces the old instances with new ones, while ensuring traffic still gets served. And it does all of this over a substrate of shared underlying server nodes, in such a way that if any of those servers goes down, it will redistribute workloads to compensate. All of that is useful even if you don't care about scale.

by imiric 4y ago

skor 4y ago

> wouldn't dare recommend it professionally anymore please provide more insight, thanks

worldsayshi 4y ago
It seems a bit confusing. Here's some context: https://github.com/docker/roadmap/issues/175 https://github.com/docker/roadmap/issues/175
- jacooper 4y ago
  Doesn't seem to change anything though? Swarm is still alive and well?
  - worldsayshi 4y ago
    Yeah I'm a bit surprised to hear that. I had only heard a lot of teams giving up swarm when it was deprecated. Didn't know they just restructured the project.
    - jacooper 4y ago
      Yup its crappy communication from docker, the ticket is asking for clarity to put an end to the swarm is dead meme. Even mirantis is back supporting swarmkit and adding new features.

kobalsky 4y ago

> and focus on simplicity and usability instead of just hyper scalability I don't get why people in IT need a boogeyman. Looks like "k8s is hard" is the new "pointers are hard" we use to scare other people now.

imiric 4y ago
That's not a great comparison, but it works in a sense. Not all languages and applications benefit from pointers. The issue is not about k8s being hard. Yes, it has a steep learning curve, but many technologies do. The issue is that learning all of its intricacies, and maintaining it and the services that run on top of it, requires valuable resources many companies don't have, especially early on. And the benefits it provides are, for the most part, not needed early on in a project's lifecycle, and often never. In financial terms, it's very high risk, with low ROI. If there's a solution that lowers the investment and maintenance costs, while being valuable in the short and long term, then that's generally a more favorable solution for most projects that don't operate at Google's scale.
- IOT_Apprentice 4y ago
  There is the learning curve, which can be challenging for organizations that aren’t experienced or exposed to scale and performance expectations. When a company moves away from being insular & proprietary to using open source there is a period of churn that ripples through the deployment, implementation and day to day operations aspect of products that live either on customer premises or a cloud platform new to everyone. There, what YOU know from experience and have evolved and worked through is unknown—because it is all new. And “training” (such as it is) is left as an exercise for each individual. I’d expect that is the norm for the traditional non startup firms, globally.
chillfox 4y ago
There is a very big difference from being a user of K8s and being someone maintaining a K8s cluster. If you are a user of K8s, then yeah, deploying apps is pretty simple most of the time. Maintaining a K8s cluster on the other hand becomes very complex and hard the moment you have use cases that are a few steps off the happy path. The K8s documentation is not sufficient for operating a K8s cluster on your own hardware, you end up having to go spelunking in the code to see how things work (this is from experience).

mikepurvis 4y ago

I'm happy with my usage of k8s, but I think it's unfortunate that current container abstractions are so oriented around imperative assembly in "layers". I want a way to run NixOS in a container and have it feel first class— existing approaches either require installing everything every time with no caching, or pre-building and manually lifecycling your container (streamLayeredImage), or knowing upfront what you're going to need (Nixery).

xp84 4y ago

> simplicity and usability instead of just hyper scalability This is such a key phrase here. If I'm starting a small SaaS company tomorrow, my ideal for setting up infrastructure would be a stack which can for now look similar to what this article sets up (especially with the tremendously lower bills), but with an easy migration path to k8s, should I hit the jackpot and have that 'very good problem to have' of too many customer requests to handle. My big issue with k8s, and honestly with other big fancy toolsets, is that getting started with it requires you to choose between: - Hire several seasoned cloud orchestration experts, preferably with the platform you've chosen (AWS, GCP, Azure) who will know how to troubleshoot this beast when you have a mysterious issue, or: - YOLO it! Just follow the basic tutorials to set k8s up, and hope you don't end up sitting up all night with a site that's refusing connections while your customers flee. The first one is the only responsible choice but it's going to add another half million to your cash burn, and that's on top of the high-margin "managed" service cloud bills like RDS. So I can see why people are drawn to a system where instead of paying for k8s and "Postgres in a box" they can pay for a simple server and have simple tooling to deploy, back up, etc.

wankle 4y ago

> Especially with the current way Docker Inc. is managed. I was reviewing GCP's Free Tier today, they have the same approach, if they need to change or drop services they agree to give 30 days notice, same as Docker did. It's probably common for other cloud companies offering free stuff as well. All the negative attention Docker received was fully and wholly undeserved.

ericb 4y ago
> I was reviewing GCP's Free Tier today, they have the same approach Google is notoriously bad about this and gets negative attention from it, so the comparison isn't favorable, and the publicity is still wholly deserved.
- rschoultz 4y ago
  >> I was reviewing GCP… > Google is notoriously bad at this… Do you mean Google or GCP? We don’t see complaints about AWS because Amazon closes Dash buttons or Spark, and also Azure is not seen in any worse light due to Microsoft discontinues Skype and what not. Can we name one remotely popular service of GCP that has been shut down at all?
- wankle 4y ago
  I can't think of a single incident where GCP actually dropped a free tier; I actually see new free tier stuff added since the last time I looked. If you can provide some excellent links to reflect your view, that I've somehow missed along the lines; it would be interesting to compare. Until then, I maintain the Docker publicity is undeserved and if I had to guess, was brought on by podman astroturfers who have been polluting the web the past 2 years claiming how great podman is.

jameshart 4y ago

I think people overindex on thinking that Kubernetes is about scalability. Honestly, its inbuilt horizontal scaling systems are pretty lacking. Scaling is not actually K8s's strong suit - sure, you can make it scale, but that takes effort and customization. But what K8s, at base, is actually useful for is availability. You tell K8s how many instances of a thing to run; it runs them; if any of them stop running, it detects that and tries to fix it. When you want to deploy a new version, it replaces the old instances with new ones, while ensuring traffic still gets served. And it does all of this over a substrate of shared underlying server nodes, in such a way that if any of those servers goes down, it will redistribute workloads to compensate. All of that is useful even if you don't care about scale.