5 ms·

I like the idea the author mentions of message queues in the database. It also sounds like it would be easier to separate if need be. I also like the idea of ke

I like the idea the author mentions of message queues in the database. It also sounds like it would be easier to separate if need be. I also like the idea of keeping everything in a single database as long as possible. Even if it turns out not to scale, it is a lot easier to figure out your business logic in that environment. Anything which avoids microservice madness and Kubernetes keenness as long as possible is very attractive to me. Maybe slightly contrary to the spirit of the article, but a few days ago there was talk about implementing the backend in your database here: https://news.ycombinator.com/item?id=25290339 https://news.ycombinator.com/item?id=25290339. Someone mentioned how Cloudfare was initially implemented on a single Postgres database: https://news.ycombinator.com/item?id=22883548 https://news.ycombinator.com/item?id=22883548

LoSboccacc 6y ago
I agree against microservices where they aren't in real need, and that a single database can go along way if well designed, since ram today is abundant everywhere and stuff like moving indexes on dedicated disks with dedicated iops is as easy as ever. but why the hate against kubernetes? even your bog standard java three tier app gets some tangible benefit from being dockerized (repeatability, whole os image versioning) and placed in a node that abstract everything else (load balancing, routing, rolling deployments etc) at the lowest level, it's just a descriptor for infrastructure, it impacts nothing of your app or business logic unless you want it to. even single node testing environments are covered one way or another (my fav now is minikube), the only real limit is one having a requirement for self hosting.
- valenterry 6y ago
  > but why the hate against kubernetes? You seem to equate kubernetes and containerization. Kubernetes is just too complex for most usecases, that's all. There are simpler solutions (in the sense of less powerful) that still allow using containers and scale-out but are less maintenance.
  - LoSboccacc 6y ago
    you need something to run the containers anyway, and with all the management overhead docker and other systems adds, one can just cut the chase and let an orchestrator do it
    - valenterry 6y ago
      Or one can use a service that does the orchestration in a certain way so that one does not have to care about it, as long as one can live with the constraints of the service. E.g. AWS Fargate or GC Run.
      - rualca 6y ago
        > E.g. AWS Fargate or GC Run. I really can't understand this line of reasoning. How exactly is something like Fargate simpler than Kubernetes? I understand the argument in favour of using Docker Swarm over deploying your own Kubernetes on premises or on heterogeneous cloud, but Fargate? And using GC Run to run containerized apps completely missed the point of containerization. Containers are way more than a simple way to distribute and run isolated apps.
        valenterry 6y ago
        Well, Fargate is simpler in the way that I define CPU+RAM, give it an image, tell it how many of them to run in parallel and let it run. If something crashes it will be restarted. If I want to deploy I push a new image. That's pretty much it. The container cannot be accessed from the outside except for the defined interfaces like http, the containers cannot discover each other unless I use something else to coordinate between them. That is all restrictive, but it also makes things simple. I still need to do health-check and such - so if I don't really need long running containers, I can make it even simpler by using lambda. (well in theory, I don't like lambda, but that's because of the implementation only)
        rualca 6y ago
- dathinab 6y ago
  > but why the hate against kubernetes? Because it adds a massive account of (to some degree hidden) complexity. Especially it adds a lot of additional (potential subtle) failure modes. And while this is more a property of micro services then of kubernets, there is some demand for a more opinionated simpler alternative. (There had been a HN article about that recently).
- twic 6y ago
  > even your bog standard java three tier app gets some tangible benefit from being dockerized (repeatability, whole os image versioning) Whole OS apart from the kernel. It's rare that a Java app has a dependency on a particular OS version, but, in my experience, even rarer that the dependency does not include the kernel.
  - jfengel 6y ago
    That was one of Java's big original selling points: write once, run anywhere. They dropped that kinda fast. With, like, version 1.1.
    - twic 6y ago
      No, not at all. People routinely develop on OS X and deploy on Linux without issue. Here, though, i just meant that i can develop on Ubuntu 18.04, build on CentOS 6, and deploy on RHEL 7 without issue.
      - jfengel 6y ago
        I mean, they dropped the slogan. The idea still held up, and in a lot of ways, still does, though the jungle of different versions and Maven version hell makes it less universal than the initial hope.
- jpcooper 6y ago
  Reproducibility is great. I would probably employ Docker for that if that were my role. However, this is completely from my own limited personal experience: I've worked with multiple devops people at earlier stage companies who have harped on about how we needed to focus on potential future scale when the company had hardly any customers. This was detrimental to our ability as programmers to understand the domain and requirements due to everything being so much harder to implement and test. It's not that I didn't try. I am also not convinced you need to worry too much about things like load balancing in the beginning. In these contexts, I never saw Kubernetes being used for reproducibility alone.
  - LoSboccacc 6y ago
    Most of the app I write have a sla and a load balancer is a great piece to have ready for simplifying/automating rolling updates, even if the backend has a single node
    - jpcooper 6y ago
      Fair enough.
Cthulhu_ 6y ago
There is definitely merit in your comment - basically, solve your problem first - but in practice, extracting functionality (such as a message queue), especially if the system is older, is very difficult and expensive, so it's put off so it becomes even more expensive. I've seen a few projects where instead of committing to a large re-architecting of an existing application, or extracting specific components, they went for a full rewrite. I don't think they were very successful (maybe for the managers that pushed for a new department to be cobbled together from consultants and self-employed folk), because the problem was not well-understood and they over-engineered towards e.g. microservices and/or everything into an event bus before understanding the problem and the consequences of their decisions. At one project, I'm convinced the decision to rewrite was political (the existing application was a C#/.NET application, the new manager Decided to have the new stuff made in Java on AWS. Oh and for every IT system to be migrated to AWS as well. Then the army of consultants and self-employed folk Decided to go for a microservices architecture linked together on an event bus (AWS Kinesis, for some reason), spent two years developing only to realize that hey, having a separate 'order' and 'inventory' microservice is kinda tricky when you actually have to check inventory to make an order. [/rant over])
- jpcooper 6y ago
  On the grand scale of things, I don't have that many years of work experience under my belt. What do you think would be the optimal evolution of a company from day 1 would be in this context? Obviously it's all speculation, but I would be interested to know how you think the message queue on database idea would go if implemented from the start.
  - necovek 6y ago
    TBH, that's the most obvious solution for eg. task management. I am sure majority of applications started at least 10 years ago started off their task management using the app database for queue management, before the proliferation of messaging queues. The couple webapps I worked on moved to a rabbitmq-based solution relatively painlessly (though old BaseTasks tend to linger for a long while still).
  - 6y ago

LoSboccacc 6y ago

I agree against microservices where they aren't in real need, and that a single database can go along way if well designed, since ram today is abundant everywhere and stuff like moving indexes on dedicated disks with dedicated iops is as easy as ever. but why the hate against kubernetes? even your bog standard java three tier app gets some tangible benefit from being dockerized (repeatability, whole os image versioning) and placed in a node that abstract everything else (load balancing, routing, rolling deployments etc) at the lowest level, it's just a descriptor for infrastructure, it impacts nothing of your app or business logic unless you want it to. even single node testing environments are covered one way or another (my fav now is minikube), the only real limit is one having a requirement for self hosting.

valenterry 6y ago
> but why the hate against kubernetes? You seem to equate kubernetes and containerization. Kubernetes is just too complex for most usecases, that's all. There are simpler solutions (in the sense of less powerful) that still allow using containers and scale-out but are less maintenance.
- LoSboccacc 6y ago
  you need something to run the containers anyway, and with all the management overhead docker and other systems adds, one can just cut the chase and let an orchestrator do it
  - valenterry 6y ago
    Or one can use a service that does the orchestration in a certain way so that one does not have to care about it, as long as one can live with the constraints of the service. E.g. AWS Fargate or GC Run.
    - rualca 6y ago
      > E.g. AWS Fargate or GC Run. I really can't understand this line of reasoning. How exactly is something like Fargate simpler than Kubernetes? I understand the argument in favour of using Docker Swarm over deploying your own Kubernetes on premises or on heterogeneous cloud, but Fargate? And using GC Run to run containerized apps completely missed the point of containerization. Containers are way more than a simple way to distribute and run isolated apps.
      - valenterry 6y ago
        Well, Fargate is simpler in the way that I define CPU+RAM, give it an image, tell it how many of them to run in parallel and let it run. If something crashes it will be restarted. If I want to deploy I push a new image. That's pretty much it. The container cannot be accessed from the outside except for the defined interfaces like http, the containers cannot discover each other unless I use something else to coordinate between them. That is all restrictive, but it also makes things simple. I still need to do health-check and such - so if I don't really need long running containers, I can make it even simpler by using lambda. (well in theory, I don't like lambda, but that's because of the implementation only)
        rualca 6y ago
dathinab 6y ago
> but why the hate against kubernetes? Because it adds a massive account of (to some degree hidden) complexity. Especially it adds a lot of additional (potential subtle) failure modes. And while this is more a property of micro services then of kubernets, there is some demand for a more opinionated simpler alternative. (There had been a HN article about that recently).
twic 6y ago
> even your bog standard java three tier app gets some tangible benefit from being dockerized (repeatability, whole os image versioning) Whole OS apart from the kernel. It's rare that a Java app has a dependency on a particular OS version, but, in my experience, even rarer that the dependency does not include the kernel.
- jfengel 6y ago
  That was one of Java's big original selling points: write once, run anywhere. They dropped that kinda fast. With, like, version 1.1.
  - twic 6y ago
    No, not at all. People routinely develop on OS X and deploy on Linux without issue. Here, though, i just meant that i can develop on Ubuntu 18.04, build on CentOS 6, and deploy on RHEL 7 without issue.
    - jfengel 6y ago
      I mean, they dropped the slogan. The idea still held up, and in a lot of ways, still does, though the jungle of different versions and Maven version hell makes it less universal than the initial hope.
jpcooper 6y ago
Reproducibility is great. I would probably employ Docker for that if that were my role. However, this is completely from my own limited personal experience: I've worked with multiple devops people at earlier stage companies who have harped on about how we needed to focus on potential future scale when the company had hardly any customers. This was detrimental to our ability as programmers to understand the domain and requirements due to everything being so much harder to implement and test. It's not that I didn't try. I am also not convinced you need to worry too much about things like load balancing in the beginning. In these contexts, I never saw Kubernetes being used for reproducibility alone.
- LoSboccacc 6y ago
  Most of the app I write have a sla and a load balancer is a great piece to have ready for simplifying/automating rolling updates, even if the backend has a single node
  - jpcooper 6y ago
    Fair enough.

Cthulhu_ 6y ago

There is definitely merit in your comment - basically, solve your problem first - but in practice, extracting functionality (such as a message queue), especially if the system is older, is very difficult and expensive, so it's put off so it becomes even more expensive. I've seen a few projects where instead of committing to a large re-architecting of an existing application, or extracting specific components, they went for a full rewrite. I don't think they were very successful (maybe for the managers that pushed for a new department to be cobbled together from consultants and self-employed folk), because the problem was not well-understood and they over-engineered towards e.g. microservices and/or everything into an event bus before understanding the problem and the consequences of their decisions. At one project, I'm convinced the decision to rewrite was political (the existing application was a C#/.NET application, the new manager Decided to have the new stuff made in Java on AWS. Oh and for every IT system to be migrated to AWS as well. Then the army of consultants and self-employed folk Decided to go for a microservices architecture linked together on an event bus (AWS Kinesis, for some reason), spent two years developing only to realize that hey, having a separate 'order' and 'inventory' microservice is kinda tricky when you actually have to check inventory to make an order. [/rant over])

jpcooper 6y ago
On the grand scale of things, I don't have that many years of work experience under my belt. What do you think would be the optimal evolution of a company from day 1 would be in this context? Obviously it's all speculation, but I would be interested to know how you think the message queue on database idea would go if implemented from the start.
- necovek 6y ago
  TBH, that's the most obvious solution for eg. task management. I am sure majority of applications started at least 10 years ago started off their task management using the app database for queue management, before the proliferation of messaging queues. The couple webapps I worked on moved to a rabbitmq-based solution relatively painlessly (though old BaseTasks tend to linger for a long while still).
- 6y ago