4 ms·

or Do you?

by beagledude 8y ago

or Do you?

toomuchtodo 8y ago
You don't. EDIT: 99 times out of 100, you don't.
- jmkni 8y ago
  But, maybe?
  - toomuchtodo 8y ago
    Maybe you'll become a billionaire. But probably not. Your monolith in a container will take you far, before we go down the treacherous path of microservices (for team demarcation, not technical scaling, but maybe technical scaling!), container lifecycle management, inbound load balancing, internal load balancing, service mesh and discovery, and all the fun that container orchestration at scale encompasses (are you ready to cry for a bit when you're running on no sleep and you can't determine why your orchestrator is unable to retrieve container images from your registry?).
    - diminoten 8y ago
      How old are you?
      - toomuchtodo 8y ago
        Almost 40, 20+ years of tech experience.
        diminoten 8y ago
        Are you concerned that you're taking a stance here that's more reflective of your years of experience than of the changing trends in tech? Experience can be a crutch too, especially in a field that gets upended by new concepts every 3-5 years. I hope you're cognizant of that. What worked 5 years ago is a joke today, in many cases.
        toomuchtodo 8y ago
        Not concerned at all. I get paid to de-risk, not to ride the hype train. > What worked 5 years ago is a joke today, in many cases. Postgresql was first released in 1997. Lots of the web still runs on PHP, Python 2, and large amounts of Java. What you call a joke, I call a sustainable business and an amortized cost. No one is paying you to use shiny tools, they're paying you to solve business problems.
        diminoten 8y ago
        Refusing to adopt innovation because it doesn't match with what you knew when you were a technical contributor is risky, too. Sticking to Python2 is risky. Using a version of Postgres released 5 years ago (9.3) is risky, using legacy PHP is risky, relying on the JVM and Java developers to solve problems that other tech stacks solve faster/better is risky. What you call a sustainable business with amortized costs I call an un-turnable ship that wastes money dealing with problems that were solved years ago.
        toomuchtodo 8y ago
        I think you misunderstand. I am not refusing to adopt innovation. I'm refusing to be underpaid to "innovate". If you want to spend sleepless nights troubleshooting beta software in production, it is not my place to stop you. It is my place to not recommend said software to businesses, and this is extremely easy to demonstrate to decision makers. If you do recommend software to a business that isn't proven (and Kubernetes is still very much unproven, it's first release was only 3 years ago), and it fails, you should be accountable for your poor judgement.
        diminoten 8y ago
        The only misunderstanding that's taking place here is how unproven you think the tech being discussed is. No one is suggesting you spend sleepless nights troubleshooting beta software in production. K8s is not beta software, and the fact that you have to misrepresent my position as such is a pretty good indicator that you don't find my actual position (use solid software even if it's new, as long as it's solid, which k8s is) to be objectionable. I wish you'd start there...
- beagledude 8y ago
  but what if? Imagine.
  - toomuchtodo 8y ago
    I imagine if you have an ops team, they're going to continue to pray every time you have to upgrade k8s or a supporting underlying service and the expectation is that everything will continue to function without dropping an inbound request. I imagine they are going to be less than impressed being on call for something that is essentially still in beta. And if you have no ops and your devs are responsible for it, god help you unless you're leaning heavily on a Kubernetes managed service (which is of course, as we recently saw with Google's outage [1], no guarantee everything will work flawlessly). My hesitation and cautiousness doesn't come from being a greybeard curmudgeon, it comes from a healthy dose of skepticism that this is The One True Path that will Solve All The Problems. I am cautiously optimistic it might be a stable, proven ecosystem, eventually. But it isn't today. When making technology decisions, imagine that you're the one with the pager at 3am and work backwards accordingly. [1] https://news.ycombinator.com/item?id=18428497 https://news.ycombinator.com/item?id=18428497
    - jeletonskelly 8y ago
      Man, I wish I could give you more upvotes for this sentiment. Making the decision to put the livelihood of a company on any platform is not to be taken lightly. As an SRE I feel like I have to take a slightly conservative approach to new technologies.
      - toomuchtodo 8y ago
        Do me a favor and pay it forward. When technology decisions are made, look at them with a conservative eye. Make absolutely sure the technology selected is being selected for the right reasons (ie not resume driven development, premature optimization, culture signaling, or because it's "new" it must be better). It'll pay dividends for whomever has to operate it, as well as the business.
    - gaius 8y ago

or Do you?

toomuchtodo 8y ago

You don't. EDIT: 99 times out of 100, you don't.

jmkni 8y ago
But, maybe?
- toomuchtodo 8y ago
  Maybe you'll become a billionaire. But probably not. Your monolith in a container will take you far, before we go down the treacherous path of microservices (for team demarcation, not technical scaling, but maybe technical scaling!), container lifecycle management, inbound load balancing, internal load balancing, service mesh and discovery, and all the fun that container orchestration at scale encompasses (are you ready to cry for a bit when you're running on no sleep and you can't determine why your orchestrator is unable to retrieve container images from your registry?).
  - diminoten 8y ago
    How old are you?
    - toomuchtodo 8y ago
      Almost 40, 20+ years of tech experience.
      - diminoten 8y ago
        Are you concerned that you're taking a stance here that's more reflective of your years of experience than of the changing trends in tech? Experience can be a crutch too, especially in a field that gets upended by new concepts every 3-5 years. I hope you're cognizant of that. What worked 5 years ago is a joke today, in many cases.
        toomuchtodo 8y ago
        Not concerned at all. I get paid to de-risk, not to ride the hype train. > What worked 5 years ago is a joke today, in many cases. Postgresql was first released in 1997. Lots of the web still runs on PHP, Python 2, and large amounts of Java. What you call a joke, I call a sustainable business and an amortized cost. No one is paying you to use shiny tools, they're paying you to solve business problems.
        diminoten 8y ago
        Refusing to adopt innovation because it doesn't match with what you knew when you were a technical contributor is risky, too. Sticking to Python2 is risky. Using a version of Postgres released 5 years ago (9.3) is risky, using legacy PHP is risky, relying on the JVM and Java developers to solve problems that other tech stacks solve faster/better is risky. What you call a sustainable business with amortized costs I call an un-turnable ship that wastes money dealing with problems that were solved years ago.
        toomuchtodo 8y ago
        I think you misunderstand. I am not refusing to adopt innovation. I'm refusing to be underpaid to "innovate". If you want to spend sleepless nights troubleshooting beta software in production, it is not my place to stop you. It is my place to not recommend said software to businesses, and this is extremely easy to demonstrate to decision makers. If you do recommend software to a business that isn't proven (and Kubernetes is still very much unproven, it's first release was only 3 years ago), and it fails, you should be accountable for your poor judgement.
        diminoten 8y ago
        The only misunderstanding that's taking place here is how unproven you think the tech being discussed is. No one is suggesting you spend sleepless nights troubleshooting beta software in production. K8s is not beta software, and the fact that you have to misrepresent my position as such is a pretty good indicator that you don't find my actual position (use solid software even if it's new, as long as it's solid, which k8s is) to be objectionable. I wish you'd start there...
beagledude 8y ago
but what if? Imagine.
- toomuchtodo 8y ago
  I imagine if you have an ops team, they're going to continue to pray every time you have to upgrade k8s or a supporting underlying service and the expectation is that everything will continue to function without dropping an inbound request. I imagine they are going to be less than impressed being on call for something that is essentially still in beta. And if you have no ops and your devs are responsible for it, god help you unless you're leaning heavily on a Kubernetes managed service (which is of course, as we recently saw with Google's outage [1], no guarantee everything will work flawlessly). My hesitation and cautiousness doesn't come from being a greybeard curmudgeon, it comes from a healthy dose of skepticism that this is The One True Path that will Solve All The Problems. I am cautiously optimistic it might be a stable, proven ecosystem, eventually. But it isn't today. When making technology decisions, imagine that you're the one with the pager at 3am and work backwards accordingly. [1] https://news.ycombinator.com/item?id=18428497 https://news.ycombinator.com/item?id=18428497
  - jeletonskelly 8y ago
    Man, I wish I could give you more upvotes for this sentiment. Making the decision to put the livelihood of a company on any platform is not to be taken lightly. As an SRE I feel like I have to take a slightly conservative approach to new technologies.
    - toomuchtodo 8y ago
      Do me a favor and pay it forward. When technology decisions are made, look at them with a conservative eye. Make absolutely sure the technology selected is being selected for the right reasons (ie not resume driven development, premature optimization, culture signaling, or because it's "new" it must be better). It'll pay dividends for whomever has to operate it, as well as the business.
  - gaius 8y ago