8 ms·

But that is the whole point of using cloud services that are tightly integrated with each other. I can not do it as efficiently as Amazon myself can not be call

But that is the whole point of using cloud services that are tightly integrated with each other. I can not do it as efficiently as Amazon myself can not be called "propriety lock-in".

chrischen 8y ago
Said efficiencies are not due to Amazon, just that the services are colocated in the same facility. If I put the node service and a database on the same box I'd get the same performance, and actually probably better since Amazon would still have them on separate physical hardware.
- scarface74 8y ago
  It’s not about performance, then I have to support all of that infrastructure myself.
  - chrischen 8y ago
    I'm talking about his statement: "Connecting to AWS managed services (s3, kinesis, dynamodb, sns) don't have this overhead so you can actually perform some task that involves reading/writing data." That is due to network and colocation efficiencies. The overhead of managing such services yourself is another matter.
    - scarface74 8y ago
      Not just the network overhead, the maintenance and setup overhead. I can spin up an entire full stack in multiple accounts just by creating a CloudFormation template. I’ve done stress testing by spinning up and tearing down multiple VMs played with different size databases, autoscaled read replicas for performance. Ran a spot fleet, etc. When you need things now you don’t have time to requisition hardware and get it sent to your colo.
      - chrischen 8y ago
        As far as spinning up and down, a lot of this is solved with docker, while also being relatively platform independent.
        scarface74 8y ago
        So Docker allows me to scale up MySQL Read replicas instantaneously? And I still have to manage infrastructure.
        chrischen 8y ago
        Well, you can use a container service or use EC2 still.
        scarface74 8y ago
        And then you still have more stuff to manage now based on the slim chance that one day years down the road you might rip your entire multi Az redundant infrastructure, your databases, etc with all of the read replicas to another provider.... And this doesn’t count all of the third party hosted services. Aurora (Mysql) redundantly writes your data to six different storage devices across multiple availability zones. The read replicas read from the same disks. As soon as you bring up a read replica, the data is already there. You can’t do that with a standard Mysql read replica.
  - state_less 8y ago
    The infrastructure, or interfaces is where the lock-in comes in. Each non-portable interface adds another binding, so it's not as easy as swapping out the provider as the OP pointed out, once you've been absorbed into the ecosystem of non-portable interfaces. You have to abstract each service out to be able to swap out providers. If you use open source interfaces, or even proprietary interfaces that are portable, it's easier to take your app with you to the new hosting provider. The non-portable interfaces are crux of the matter. If you could run lambda on Google, Azure or your own metal, folks wouldn't feel so locked-in.
    - scarface74 8y ago
      As I said. I can run the Node/Express lambda anywhere without changing code. But, I could still take advantage of hosted Aurora (MySQL/Postgres), DocumentDB (Mongo), ElasticCache (Memcached/Redis) or even Redshift (Postgres compatible interface) without any of the dreaded “lock-in”.
      - state_less 8y ago
        It sounds like you have a preference for choosing portable interfaces when it comes to storage. And you've abstracted out the non-portable lambda interface. My position isn't don't use AWS as a hosting provider, it's that you ought to avoid being locked into a proprietary non-portable interface when possible.
        scarface74 8y ago
        Not really. My company has plenty of business risks. Out of the those, a dependency on AWS is the least of them.
        chrischen 8y ago
        Vendor lock in isn't really a problem initially. It's something that creeps up on you over time.

But that is the whole point of using cloud services that are tightly integrated with each other. I can not do it as efficiently as Amazon myself can not be called "propriety lock-in".

chrischen 8y ago

Said efficiencies are not due to Amazon, just that the services are colocated in the same facility. If I put the node service and a database on the same box I'd get the same performance, and actually probably better since Amazon would still have them on separate physical hardware.

scarface74 8y ago
It’s not about performance, then I have to support all of that infrastructure myself.
- chrischen 8y ago
  I'm talking about his statement: "Connecting to AWS managed services (s3, kinesis, dynamodb, sns) don't have this overhead so you can actually perform some task that involves reading/writing data." That is due to network and colocation efficiencies. The overhead of managing such services yourself is another matter.
  - scarface74 8y ago
    Not just the network overhead, the maintenance and setup overhead. I can spin up an entire full stack in multiple accounts just by creating a CloudFormation template. I’ve done stress testing by spinning up and tearing down multiple VMs played with different size databases, autoscaled read replicas for performance. Ran a spot fleet, etc. When you need things now you don’t have time to requisition hardware and get it sent to your colo.
    - chrischen 8y ago
      As far as spinning up and down, a lot of this is solved with docker, while also being relatively platform independent.
      - scarface74 8y ago
        So Docker allows me to scale up MySQL Read replicas instantaneously? And I still have to manage infrastructure.
        chrischen 8y ago
        Well, you can use a container service or use EC2 still.
        scarface74 8y ago
        And then you still have more stuff to manage now based on the slim chance that one day years down the road you might rip your entire multi Az redundant infrastructure, your databases, etc with all of the read replicas to another provider.... And this doesn’t count all of the third party hosted services. Aurora (Mysql) redundantly writes your data to six different storage devices across multiple availability zones. The read replicas read from the same disks. As soon as you bring up a read replica, the data is already there. You can’t do that with a standard Mysql read replica.
- state_less 8y ago
  The infrastructure, or interfaces is where the lock-in comes in. Each non-portable interface adds another binding, so it's not as easy as swapping out the provider as the OP pointed out, once you've been absorbed into the ecosystem of non-portable interfaces. You have to abstract each service out to be able to swap out providers. If you use open source interfaces, or even proprietary interfaces that are portable, it's easier to take your app with you to the new hosting provider. The non-portable interfaces are crux of the matter. If you could run lambda on Google, Azure or your own metal, folks wouldn't feel so locked-in.
  - scarface74 8y ago
    As I said. I can run the Node/Express lambda anywhere without changing code. But, I could still take advantage of hosted Aurora (MySQL/Postgres), DocumentDB (Mongo), ElasticCache (Memcached/Redis) or even Redshift (Postgres compatible interface) without any of the dreaded “lock-in”.
    - state_less 8y ago
      It sounds like you have a preference for choosing portable interfaces when it comes to storage. And you've abstracted out the non-portable lambda interface. My position isn't don't use AWS as a hosting provider, it's that you ought to avoid being locked into a proprietary non-portable interface when possible.
      - scarface74 8y ago
        Not really. My company has plenty of business risks. Out of the those, a dependency on AWS is the least of them.
        chrischen 8y ago
        Vendor lock in isn't really a problem initially. It's something that creeps up on you over time.