3 ms·

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. M

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.
  - scarface74 8y ago
    Over time, we will have an “exit strategy” that makes it “someone else’s problem” and then we will be well enough capitalized to migrate if needed. Or the Twitter model - very bad architecture that always crashed, find “product market fit” and then get funding to fix any issues. Or the company goes out of business, I put X years of AWS experience on my resume and make out like a bandit as an overpriced consultant. I don’t see the downside....
    - wolco 8y ago
      The downside could be going for a new round and not getting that valuation because projected costs prevent scaling.
      - redisman 8y ago
        I don't really see cloud-provider competition lessening or hardware getting more expensive and less efficient or the VMs getting worse at micro-slicing in the next 5 years. So why would I be worried about rising costs?
        scarface74 8y ago
        Speaking of micro slicing..... https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...
      - notduncansmith 8y ago
        I think spending one of the newly-raised millions over a year or so can help there, including hiring senior engineers talented enough to fix the shitty architecture that got you to product-market-fit. This isn’t an inherently bad thing, it just makes certain business strategies incompatible with certain engineering strategies. Luckily for startups, most intermediate engineers can get you to PMF if you keep them from employing too much abstraction.
        scarface74 8y ago
        Isn’t employing too many abstractions just what many here are advocating - putting a layer of abstraction over the SDKs abstractions of the API? I would much rather come into a code base that just uses Python + Boto3 (AWS’s Python SDK) than one that uses Python + “SQSManager”/“S3Manager” + Boto3.
        notduncansmith 8y ago
        That is indeed what many here are advocating. There are only so many possible interfaces or implementations, and usually abstracting over one or the other is an effort in reinventing the wheel, or the saw, or the water clock, and not doing the job as well as some standard parts glued together until quite far into the endeavor.

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.
- scarface74 8y ago
  Over time, we will have an “exit strategy” that makes it “someone else’s problem” and then we will be well enough capitalized to migrate if needed. Or the Twitter model - very bad architecture that always crashed, find “product market fit” and then get funding to fix any issues. Or the company goes out of business, I put X years of AWS experience on my resume and make out like a bandit as an overpriced consultant. I don’t see the downside....
  - wolco 8y ago
    The downside could be going for a new round and not getting that valuation because projected costs prevent scaling.
    - redisman 8y ago
      I don't really see cloud-provider competition lessening or hardware getting more expensive and less efficient or the VMs getting worse at micro-slicing in the next 5 years. So why would I be worried about rising costs?
      - scarface74 8y ago
        Speaking of micro slicing..... https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...
    - notduncansmith 8y ago
      I think spending one of the newly-raised millions over a year or so can help there, including hiring senior engineers talented enough to fix the shitty architecture that got you to product-market-fit. This isn’t an inherently bad thing, it just makes certain business strategies incompatible with certain engineering strategies. Luckily for startups, most intermediate engineers can get you to PMF if you keep them from employing too much abstraction.
      - scarface74 8y ago
        Isn’t employing too many abstractions just what many here are advocating - putting a layer of abstraction over the SDKs abstractions of the API? I would much rather come into a code base that just uses Python + Boto3 (AWS’s Python SDK) than one that uses Python + “SQSManager”/“S3Manager” + Boto3.
        notduncansmith 8y ago
        That is indeed what many here are advocating. There are only so many possible interfaces or implementations, and usually abstracting over one or the other is an effort in reinventing the wheel, or the saw, or the water clock, and not doing the job as well as some standard parts glued together until quite far into the endeavor.