5 ms·

I agree. I recently created a private cloud infrastructure on Digital Ocean. It would have been easier and faster (and more polished) if I'd gone with AWS, but

I agree. I recently created a private cloud infrastructure on Digital Ocean. It would have been easier and faster (and more polished) if I'd gone with AWS, but then I would know how to use AWS, and would not know how to do these things myself. Why learn about HAProxy, keepalived, tinc, etc when you've got AWS to handle it all for you? Answer: Because relying on a service to abstract the inner workings for you is a path to the dark side.

deleted 11y ago
[deleted]
toomuchtodo 11y ago
Not sure why you're being downvoted. Abstraction is for ease of use, not ignorance as to what's occurring under the hood.
- rubiquity 11y ago
  > Abstraction is for ease of use, not ignorance as to what's occurring under the hood. I'm stealing this. I love it!
- davidrusu 11y ago
  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. :-)
rubiquity 11y ago
Agreed. I wouldn't be on AWS if not for the fact that they're the only large, on-demand instance creation service that will also sign a BAA for our HIPAA needs. Even though we make use of the AWS specific tools like ELBs and VPCs, we still configure all the under-the-hood equivalents such as iptables, nginx, etc. ourselves.
- pilom 11y ago
  WHY?!?! Just go to beanstalk and have it done for you or use Puppet/chef to manage it for everything.
  - rubiquity 11y ago
    I'm not sure if you interpreted that as configuring it all ourselves as in manually, but we use Ansible for configuration management.
lazyant 11y ago
It depends where you want to stop the abstraction, you don't write assembly code or your own database/web server, you are just drawing an arbitrary line on products as a service (and I'm not disagreeing with the sentiment).
deegles 11y ago
I use cloud services because there's only one of me and I would rather be developing features. They also let me think at higher levels of abstraction. I also like to think of using a cloud service as "hiring" the entire staff working on that product + benefiting from all of the accumulated knowledge that's been baked in. That makes a cloud service a huge bargain to me.
moondev 11y ago
I'm interested to learn how you setup a vpc on digital ocean considering they don't even offer that.
- jtreminio 11y ago
  They do, but it's very limited. Their private IPs only work within the same datacenter, so you lose the benefit of distributing your infrastructure globally. The solution that worked well for me was using tinc to set up a VPN so all my servers, no matter what datacenter they're sitting in, can communicate with each other using private IP addresses (tinc has added benefit of encrypting, which DO's private network does not). If you're needing help, I'm currently looking for more contract work :) Check my profile for contact information.
  - moondev 11y ago
    But you are still sitting on the same network as everyone else correct? That doesn't sound like a vpc. This is a case of the wrong tool/service for the job. You need advanced networking and spent all this time duct taping it together on DO when you could have a real VPC on aws with security groups, subnetting etc. Not to mention locked in to DO's limited instance types. Don't get me wrong, DO fills a niche for quick one-off type applications but it is absolutely no substitute for a real IAAS like aws, gcp, azure... Investing time in trying to turn it in to one is a waste and way worse than perceived "lock-in". You also could have just as easily rolled your own setup the same way on AWS, so i'm not sure what argument is other than cost. (btw t2.nano instances are $4.75 a month) http://www.ec2instances.info/?cost=monthly http://www.ec2instances.info/?cost=monthly
deleted 11y ago
[deleted]
skywhopper 11y ago
The key is to focus on the services that you can add value to over and above what the AWS managed services offer. There's no reason to futz around with building and maintaining a load-balancer infrastructure if Amazon's ELB does everything you need (unlikely, I will admit). AWS and other cloud services just provide an additional set of tools that may or may not be useful.
fapjacks 11y ago
Plus also: $$$$$$$$$$$$$$$$$$$$

deleted 11y ago

[deleted]

toomuchtodo 11y ago

Not sure why you're being downvoted. Abstraction is for ease of use, not ignorance as to what's occurring under the hood.

rubiquity 11y ago
> Abstraction is for ease of use, not ignorance as to what's occurring under the hood. I'm stealing this. I love it!
davidrusu 11y ago
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. :-)

rubiquity 11y ago

Agreed. I wouldn't be on AWS if not for the fact that they're the only large, on-demand instance creation service that will also sign a BAA for our HIPAA needs. Even though we make use of the AWS specific tools like ELBs and VPCs, we still configure all the under-the-hood equivalents such as iptables, nginx, etc. ourselves.

pilom 11y ago
WHY?!?! Just go to beanstalk and have it done for you or use Puppet/chef to manage it for everything.
- rubiquity 11y ago
  I'm not sure if you interpreted that as configuring it all ourselves as in manually, but we use Ansible for configuration management.

lazyant 11y ago

It depends where you want to stop the abstraction, you don't write assembly code or your own database/web server, you are just drawing an arbitrary line on products as a service (and I'm not disagreeing with the sentiment).

deegles 11y ago

I use cloud services because there's only one of me and I would rather be developing features. They also let me think at higher levels of abstraction. I also like to think of using a cloud service as "hiring" the entire staff working on that product + benefiting from all of the accumulated knowledge that's been baked in. That makes a cloud service a huge bargain to me.

moondev 11y ago

I'm interested to learn how you setup a vpc on digital ocean considering they don't even offer that.

jtreminio 11y ago
They do, but it's very limited. Their private IPs only work within the same datacenter, so you lose the benefit of distributing your infrastructure globally. The solution that worked well for me was using tinc to set up a VPN so all my servers, no matter what datacenter they're sitting in, can communicate with each other using private IP addresses (tinc has added benefit of encrypting, which DO's private network does not). If you're needing help, I'm currently looking for more contract work :) Check my profile for contact information.
- moondev 11y ago
  But you are still sitting on the same network as everyone else correct? That doesn't sound like a vpc. This is a case of the wrong tool/service for the job. You need advanced networking and spent all this time duct taping it together on DO when you could have a real VPC on aws with security groups, subnetting etc. Not to mention locked in to DO's limited instance types. Don't get me wrong, DO fills a niche for quick one-off type applications but it is absolutely no substitute for a real IAAS like aws, gcp, azure... Investing time in trying to turn it in to one is a waste and way worse than perceived "lock-in". You also could have just as easily rolled your own setup the same way on AWS, so i'm not sure what argument is other than cost. (btw t2.nano instances are $4.75 a month) http://www.ec2instances.info/?cost=monthly http://www.ec2instances.info/?cost=monthly

deleted 11y ago

[deleted]

skywhopper 11y ago

The key is to focus on the services that you can add value to over and above what the AWS managed services offer. There's no reason to futz around with building and maintaining a load-balancer infrastructure if Amazon's ELB does everything you need (unlikely, I will admit). AWS and other cloud services just provide an additional set of tools that may or may not be useful.

fapjacks 11y ago

Plus also: $$$$$$$$$$$$$$$$$$$$