4 ms·

No. Abstraction is for higher level thinking. Dev Ops is still young so we are seeing many attempts at providing these abstractions but it is a very large domai

No. Abstraction is for higher level thinking. Dev Ops is still young so we are seeing many attempts at providing these abstractions but it is a very large domain to abstract over and thus hard to make a non leaky abstraction. Given a non leaky abstraction, ignorance of whats under the hood is just fine.

deleted 11y ago
[deleted]
jtreminio 11y ago
What I was trying to say was more along the lines of a 3rd-party service abstracting the work is not a good idea in the long-term. It is unthinkable right now, but what will happen with Amazon/AWS goes bankrupt and no longer exists? All these AWS Certified Engineers who are not actually devops will suddenly be lost. On the flipside, if you learn everything from the ground up and then jump on AWS or whatever service is available, you will be in a much better position when the day comes to move away and to something else. Abstractions in something like programming languages is fine because the language won't simply disappear one day - you'll evolve as a programmer and will be stronger for it.
- davidrusu 11y ago
  I see what you are saying, and I agree with you that betting on any of the current abstractions is probably not a good idea. But I really believe someone will figure this problem out, and at that point Dev Ops will be done. There is just to much money to be made.
- moondev 11y ago
  > It is unthinkable right now, but what will happen with Amazon/AWS goes bankrupt and no longer exists? All these AWS Certified Engineers who are not actually devops will suddenly be lost. Or they could just read this document and move to GCP. https://cloud.google.com/docs/google-cloud-platform-for-aws-professionals https://cloud.google.com/docs/google-cloud-platform-for-aws-...
  - toomuchtodo 11y ago
    It's all virtualization/containerization/object|relational storage, no matter how you cut it. Know the fundamentals, and you'll be fine. Everything else is rhinestone marketing.
krisdol 11y ago
Ignorance of what's under the hood is also called vendor lock-in, which is great for vendors but I can't see it ever being good for clients.
sergiosgc 11y ago
> Given a non leaky abstraction, ignorance of whats under the hood is just fine. Minus vendor lock-in. Once you have your infrastructure dependent on ELB, S3, Redshift and all the other AWS niceties, you are effectively locked into Amazon. Locked, in the sense that migrating out has a relevant knowledge cost (deprecation of knowledge of AWS, need for gain in alternative knowledge). It's not a dumb choice, but it's also not clear for either side. Running your own iron is much much cheaper. For my case (email service provider), our bill estimate on AWS would be about 300k€/year, while running our own servers costs 84k€/year (split at 48k€ depreciation and 36k€ operational costs).
- toomuchtodo 11y ago
  > It's not a dumb choice, but it's also not clear for either side. Running your own iron is much much cheaper. For my case (email service provider), our bill estimate on AWS would be about 300k€/year, while running our own servers costs 84k€/year (split at 48k€ depreciation and 36k€ operational costs). Something to note about US orgs: New depreciation rules allow you to depreciate $500K/year in hardware, in that year. That means that gear is yours, forever, whereas that $500K/year in opex to AWS is recurring forever.
  - pnathan 11y ago
    can you link to a detailed analysis of that?
    - toomuchtodo 11y ago
      Did you want a link to the new depreciation rules? Or a specific scenario?
      - pnathan 11y ago
        Link to the rules, and/or some analysis by a well-regarded accountant. I'd like to route the information internally. :-)

deleted 11y ago

[deleted]

jtreminio 11y ago

What I was trying to say was more along the lines of a 3rd-party service abstracting the work is not a good idea in the long-term. It is unthinkable right now, but what will happen with Amazon/AWS goes bankrupt and no longer exists? All these AWS Certified Engineers who are not actually devops will suddenly be lost. On the flipside, if you learn everything from the ground up and then jump on AWS or whatever service is available, you will be in a much better position when the day comes to move away and to something else. Abstractions in something like programming languages is fine because the language won't simply disappear one day - you'll evolve as a programmer and will be stronger for it.

davidrusu 11y ago
I see what you are saying, and I agree with you that betting on any of the current abstractions is probably not a good idea. But I really believe someone will figure this problem out, and at that point Dev Ops will be done. There is just to much money to be made.
moondev 11y ago
> It is unthinkable right now, but what will happen with Amazon/AWS goes bankrupt and no longer exists? All these AWS Certified Engineers who are not actually devops will suddenly be lost. Or they could just read this document and move to GCP. https://cloud.google.com/docs/google-cloud-platform-for-aws-professionals https://cloud.google.com/docs/google-cloud-platform-for-aws-...
- toomuchtodo 11y ago
  It's all virtualization/containerization/object|relational storage, no matter how you cut it. Know the fundamentals, and you'll be fine. Everything else is rhinestone marketing.

krisdol 11y ago

Ignorance of what's under the hood is also called vendor lock-in, which is great for vendors but I can't see it ever being good for clients.

sergiosgc 11y ago

> Given a non leaky abstraction, ignorance of whats under the hood is just fine. Minus vendor lock-in. Once you have your infrastructure dependent on ELB, S3, Redshift and all the other AWS niceties, you are effectively locked into Amazon. Locked, in the sense that migrating out has a relevant knowledge cost (deprecation of knowledge of AWS, need for gain in alternative knowledge). It's not a dumb choice, but it's also not clear for either side. Running your own iron is much much cheaper. For my case (email service provider), our bill estimate on AWS would be about 300k€/year, while running our own servers costs 84k€/year (split at 48k€ depreciation and 36k€ operational costs).

toomuchtodo 11y ago
> It's not a dumb choice, but it's also not clear for either side. Running your own iron is much much cheaper. For my case (email service provider), our bill estimate on AWS would be about 300k€/year, while running our own servers costs 84k€/year (split at 48k€ depreciation and 36k€ operational costs). Something to note about US orgs: New depreciation rules allow you to depreciate $500K/year in hardware, in that year. That means that gear is yours, forever, whereas that $500K/year in opex to AWS is recurring forever.
- pnathan 11y ago
  can you link to a detailed analysis of that?
  - toomuchtodo 11y ago
    Did you want a link to the new depreciation rules? Or a specific scenario?
    - pnathan 11y ago
      Link to the rules, and/or some analysis by a well-regarded accountant. I'd like to route the information internally. :-)