17 ms·

> You need a fairly sophisticated DevOps organization to successfully run microservices. This doesn't really make a difference if you run at a scale that requir

by oxff 4y ago

> You need a fairly sophisticated DevOps organization to successfully run microservices. This doesn't really make a difference if you run at a scale that requires that sophistication anyhow, but it is very likely that you are not Google Correct. Don't use tools aimed for Google levels of complexity if you're not dealing with Google levels of complexity.

pid-1 4y ago
That said, gitlab.com itself runs on K8s.
- mooreds 4y ago
  k8s isn't only for microservices. You can containerize up normal applications (12 factor or otherwise architected) and run them on k8s. Is it a good idea? Depends. On the plus side: You have one underlying runtime and orchestration layer, with a lot of useful primitives (including and especially around deployments). On the negative: You introduce yet another layer of complexity and abstraction.
  - james_marks 4y ago
    YALCA
  - Spivak 4y ago
    You just described the counter to “don’t run things designed for Google if you’re not Google.” The real advice is “don’t run stacks that make trade-offs or give up guarantees to be able to scale to a size you’re not at or solve problems you don’t have.”
    - prescriptivist 4y ago
      The systems in kubernetes for horizontal auto scaling are extremely nice and work very well for our large monolith. At this point I can't imagine deploying any system with significant batch or online workloads any other way. We switched to k8s early on in the company and that little bit of work to get it operating with HPAs, etc has paid off in dividends over time.
ezekiel11 4y ago
serverless environments do not carry the devops overhead involved with kubernetes or other container orchestration.
- tmp_anon_22 4y ago
  For non-trivial workloads serverless does still require a lot of orchestration and domain knowledge of cloud-specific features and constraints. Kubernetes is for sure its own beast, but its a ton of work regardless (for gains that at the end of the day aren't what you thought they would be...). Serverless is amazing when you use it the way its intended. Its not there to replace your entire ec2 workload.
  - ezekiel11 4y ago
    your assessment would've been correct 3 or 4 years ago but there's just no need to scaffold ec2, mysql db inside a vpc. You can upload your environment via docker and start serving serverless. You can then use serverless db that is 90% cheaper and far less hassle than scaling up or down ec2 instances/rds, configuring vpc, setting up nat gateways etc my view is that if you are not on serverless, you are wasting resources that could otherwise been dedicated to building out domain knowledge our team focuses on optimizing each function and less on devops/scaling. the plumbing work is gone and all we do is now translate business requirements. security concerns are also largely removed. its a great time to be on serverless, it had to overcome lot of doubt but it is here to stay. no need to pay $5 / month either for your weekend projects. even if your project hits front page, it will still work, the billing is not even that bad for what you are getting.
    - mooreds 4y ago
      > serverless db that is 90% cheaper > building out domain knowledge What about all the knowledge that is contained in applications, services and libraries that run on RDBMs? I'm serious, one of the reasons I shy away from serverless is I want to put together components at a higher level than functions. But maybe I'm missing something?
    - 4y ago
vinceguidry 4y ago
Slight correction, you can't run tools aimed for Google levels of complexity because Google doesn't release the tools they use to handle their scale. They don't use k8s to manage their infrastructure, they use Borg. K8s doesn't scale to Google's needs. Also, nobody's running at Google scale.
- hinkley 4y ago
  And nobody should be. We’ve talked many times before about how ridiculous their amount of hardware is. There are really only two arguments for “why” that make sense to me: One, they are succeeding in spite of a very large degree of excess hardware. Two, all that hardware is about advertising. Schadenfreude wants it to be #1, but I suspect it’s actually #2. And I hope that some day - soon - “overtracking your users” becomes a hot button topic in consumer safety, maybe not as serious as industrial pollution but pretty close.
jchw 4y ago
"Don't use tools aimed at Google levels of complexity" is a take that has become quite popular, but it's definitely lacking nuance. Tools are pretty multi-faceted and rarely have a single selling point. For example, Kubernetes solves a whole boatload of general service orchestration problems in a unified way; perhaps it's true that you only ever need this at Google scale, but you can certainly benefit from it at almost any scale where it runs. (Which is a lot. k3s is pretty light.) Does that mean you should write microservices for your toy? Probably not. But the trade-off calculus for microservices is not scale. It is a lot of things. If you had an application that was extremely trivial to run as decoupled services, and the boundaries between them are not liable to change much, maybe you really should use microservices from zero, and benefit from better failure isolation among other things. But yes, probably not. Still, I think the idea that microservices are not really a great idea is a flimsy justification for Ruby on Rails in general. It's fair enough to say that if your language, framework and library choices are working for you and your product, you aren't beholden to justify them really. That said, that doesn't mean they couldn't be better with different decisions, and it's sincerely hard to determine that. Sometimes, I get the feeling that articles in this vein are just as much about convincing the authors that they made the right choice as it is convincing anyone else. But it's not really that important, since I don't really feel you actually need to convince much of anyone, if you like your decision.
- projectazorian 4y ago
  > Sometimes, I get the feeling that articles in this vein are just as much about convincing the authors that they made the right choice as it is convincing anyone else. But it's not really that important, since I don't really feel you actually need to convince much of anyone, if you like your decision. They don't need to convince us random HN readers, that's true. But they do need to convince new hires, potential clients, and internal stakeholders that Rails is still the right choice. If you've ever worked on a large Rails SaaS app you know this subject comes up a lot. Now when the subject comes up they can just send folks a link to the blog post, it's very convenient to have around for this purpose.
deleted 4y ago
[deleted]
nikanj 4y ago
Anyone can have Google levels of complexity, it just requires a dedicated engineering team. Having Google levels of traffic is another thing, but it's easy enough to get Google levels of complexity.
- rk06 4y ago
  Traffic is part of Google level complexity. The things you need to account when you are dealing with 1 million requests per day is significantly different from 1 million requests per second.

by oxff 4y ago

pid-1 4y ago

That said, gitlab.com itself runs on K8s.

mooreds 4y ago
k8s isn't only for microservices. You can containerize up normal applications (12 factor or otherwise architected) and run them on k8s. Is it a good idea? Depends. On the plus side: You have one underlying runtime and orchestration layer, with a lot of useful primitives (including and especially around deployments). On the negative: You introduce yet another layer of complexity and abstraction.
- james_marks 4y ago
  YALCA
- Spivak 4y ago
  You just described the counter to “don’t run things designed for Google if you’re not Google.” The real advice is “don’t run stacks that make trade-offs or give up guarantees to be able to scale to a size you’re not at or solve problems you don’t have.”
  - prescriptivist 4y ago
    The systems in kubernetes for horizontal auto scaling are extremely nice and work very well for our large monolith. At this point I can't imagine deploying any system with significant batch or online workloads any other way. We switched to k8s early on in the company and that little bit of work to get it operating with HPAs, etc has paid off in dividends over time.

ezekiel11 4y ago

serverless environments do not carry the devops overhead involved with kubernetes or other container orchestration.

tmp_anon_22 4y ago
For non-trivial workloads serverless does still require a lot of orchestration and domain knowledge of cloud-specific features and constraints. Kubernetes is for sure its own beast, but its a ton of work regardless (for gains that at the end of the day aren't what you thought they would be...). Serverless is amazing when you use it the way its intended. Its not there to replace your entire ec2 workload.
- ezekiel11 4y ago
  your assessment would've been correct 3 or 4 years ago but there's just no need to scaffold ec2, mysql db inside a vpc. You can upload your environment via docker and start serving serverless. You can then use serverless db that is 90% cheaper and far less hassle than scaling up or down ec2 instances/rds, configuring vpc, setting up nat gateways etc my view is that if you are not on serverless, you are wasting resources that could otherwise been dedicated to building out domain knowledge our team focuses on optimizing each function and less on devops/scaling. the plumbing work is gone and all we do is now translate business requirements. security concerns are also largely removed. its a great time to be on serverless, it had to overcome lot of doubt but it is here to stay. no need to pay $5 / month either for your weekend projects. even if your project hits front page, it will still work, the billing is not even that bad for what you are getting.
  - mooreds 4y ago
    > serverless db that is 90% cheaper > building out domain knowledge What about all the knowledge that is contained in applications, services and libraries that run on RDBMs? I'm serious, one of the reasons I shy away from serverless is I want to put together components at a higher level than functions. But maybe I'm missing something?
  - 4y ago

vinceguidry 4y ago

Slight correction, you can't run tools aimed for Google levels of complexity because Google doesn't release the tools they use to handle their scale. They don't use k8s to manage their infrastructure, they use Borg. K8s doesn't scale to Google's needs. Also, nobody's running at Google scale.

hinkley 4y ago
And nobody should be. We’ve talked many times before about how ridiculous their amount of hardware is. There are really only two arguments for “why” that make sense to me: One, they are succeeding in spite of a very large degree of excess hardware. Two, all that hardware is about advertising. Schadenfreude wants it to be #1, but I suspect it’s actually #2. And I hope that some day - soon - “overtracking your users” becomes a hot button topic in consumer safety, maybe not as serious as industrial pollution but pretty close.

jchw 4y ago

"Don't use tools aimed at Google levels of complexity" is a take that has become quite popular, but it's definitely lacking nuance. Tools are pretty multi-faceted and rarely have a single selling point. For example, Kubernetes solves a whole boatload of general service orchestration problems in a unified way; perhaps it's true that you only ever need this at Google scale, but you can certainly benefit from it at almost any scale where it runs. (Which is a lot. k3s is pretty light.) Does that mean you should write microservices for your toy? Probably not. But the trade-off calculus for microservices is not scale. It is a lot of things. If you had an application that was extremely trivial to run as decoupled services, and the boundaries between them are not liable to change much, maybe you really should use microservices from zero, and benefit from better failure isolation among other things. But yes, probably not. Still, I think the idea that microservices are not really a great idea is a flimsy justification for Ruby on Rails in general. It's fair enough to say that if your language, framework and library choices are working for you and your product, you aren't beholden to justify them really. That said, that doesn't mean they couldn't be better with different decisions, and it's sincerely hard to determine that. Sometimes, I get the feeling that articles in this vein are just as much about convincing the authors that they made the right choice as it is convincing anyone else. But it's not really that important, since I don't really feel you actually need to convince much of anyone, if you like your decision.

projectazorian 4y ago
> Sometimes, I get the feeling that articles in this vein are just as much about convincing the authors that they made the right choice as it is convincing anyone else. But it's not really that important, since I don't really feel you actually need to convince much of anyone, if you like your decision. They don't need to convince us random HN readers, that's true. But they do need to convince new hires, potential clients, and internal stakeholders that Rails is still the right choice. If you've ever worked on a large Rails SaaS app you know this subject comes up a lot. Now when the subject comes up they can just send folks a link to the blog post, it's very convenient to have around for this purpose.

deleted 4y ago

[deleted]

nikanj 4y ago

Anyone can have Google levels of complexity, it just requires a dedicated engineering team. Having Google levels of traffic is another thing, but it's easy enough to get Google levels of complexity.

rk06 4y ago
Traffic is part of Google level complexity. The things you need to account when you are dealing with 1 million requests per day is significantly different from 1 million requests per second.