4 ms·

...in exchange for a number of different problems including (in no particular order): severe vendor lock-in, mediocre to acceptable performance, and relatively

...in exchange for a number of different problems including (in no particular order): severe vendor lock-in, mediocre to acceptable performance, and relatively high cost per unit of performance.

gfodor 12y ago
Yup, and for startups this tradeoff is usually a no-brainer.
personZ 12y ago
I don't personally get the RDS value proposition, but how does it lead to vendor lock-in, much less severe vendor lock-in? I don't believe there is really any lock-in whatsoever -- backup your database and move it wherever you want, whether you're running the pgsql, Mysql, or SQL Server variants of RDS.
- bkeroack 12y ago
  While of course you're correct, it's a bit like saying "you can just pack up your code and run it somewhere else". If the entire architecture and workflow are based around proprietary AWS tools (Elastic Beanstalk, Elastic load balancers, RDS, Cloud Formation, autoscaling, etc) even if your code is technically portable, you're still suffering from vendor lock-in. Arguably worse than the bad old days of the Microsoft monopoly.
  - Xorlev 12y ago
    RDS is just a database though. All the standard tools work with it. Unless you start dipping into more exotic services, it's pretty hard to become locked in. EC2+ELB+RDS are fairly independent. Even autoscaling doesn't lock you in. That said, CloudFormation, SQS, Kinesis, DynamoDB, etc. are all very sticky services.
  - personZ 12y ago
    That's a bit of an extrapolation though, isn't it? Many people simply run VMs that connects to some arbitrary pgsql instance, which might happen to be on RDS if they want to simplify the management of that. Those VMs can absolutely run almost anywhere, and they can connect to just about any instance of pgsql. I heavily use many services on AWS, but can quite literally move the entirety of it to my own servers, Google, Azure, or elsewhere in very short notice. People can choose to use some of the more unique services, but that is not related to RDS.
  - correctdarecord 12y ago
    Where you see 'vendor lock-in', I see the opportunity to leverage somebody else's engineering talent to solve commodity problems that our customers don't pay for.
dahdum 12y ago
Different problems, but vendor lock-in isn't really one of them imho. If you are skilled enough to setup pg instead of using RDS you can always move off it to systems under your control. If you don't have the skills, you can migrate to another provider like Heroku. As far as my experience, they aren't extending PG in non-compatible ways.
lewaldman 12y ago
I really don't get all this yadda yadda about AWS lock-in. Which component on AWS doesn't have a OpenSource counter-part that you, having the time, knowledge (;P) and time for it, could not implement on your own infrastructure? Really... It's an honest question from some one that works as Senior AWS architect on a full time job.
- bkeroack 12y ago
  Imagine you're an early stage startup. You have a handful of overworked, stressed-out engineers trying to ship v1.0. You don't have the time or resources for a dedicated Ops team, so you go with AWS (I think this is a great use case for AWS or any public cloud, btw--it just makes sense at a really early stage startup). You ship your product, get some customers. Fast forward 18-24 months. You have grown enormously, you have lots of customers and revenue projections and expectant investors. Your (now much larger) engineering team has gotten used to AWS conveniences and leveraged a lot of them in the development workflow. Your architecture consists of several layers of ELBs, you have painstakenly set up autoscaling and deployment via Elastic Beanstalk. Your server backups are AMIs. Your data lives in RDS (analytics in Red Shift). Your webservers use Elasticache. SQS is the backbone of your asynchronous job workflow. Customer email traffic goes through SES. Etc. Now your AWS bill is something like $25-30k/month. You're at the point where the pricing differential between real hardware and AWS is getting big, and it will only get worse over time. Now management has to make the hard choice: - Build an Ops team capable of architecting, constructing and deploying new infrastructure on bare metal - 3-6 months of work to go from design to final cut-over - Risk some business interruption in the changeover (downtime, unexpected problems) and slower development iteration until the engineering team gets used to new tools/ways of pushing code out. or - Continue on AWS and eat the bill as cost of doing business. This is vendor lock-in at the most basic level.
  - akurilin 12y ago
    Ultimately this is a good problem to have, no? Your startup is alive and growing, you can afford an ops team, your product proved itself. Most startups will have been dead for years at this point.
  - 12y ago

...in exchange for a number of different problems including (in no particular order): severe vendor lock-in, mediocre to acceptable performance, and relatively high cost per unit of performance.

gfodor 12y ago

Yup, and for startups this tradeoff is usually a no-brainer.

personZ 12y ago

I don't personally get the RDS value proposition, but how does it lead to vendor lock-in, much less severe vendor lock-in? I don't believe there is really any lock-in whatsoever -- backup your database and move it wherever you want, whether you're running the pgsql, Mysql, or SQL Server variants of RDS.

bkeroack 12y ago
While of course you're correct, it's a bit like saying "you can just pack up your code and run it somewhere else". If the entire architecture and workflow are based around proprietary AWS tools (Elastic Beanstalk, Elastic load balancers, RDS, Cloud Formation, autoscaling, etc) even if your code is technically portable, you're still suffering from vendor lock-in. Arguably worse than the bad old days of the Microsoft monopoly.
- Xorlev 12y ago
  RDS is just a database though. All the standard tools work with it. Unless you start dipping into more exotic services, it's pretty hard to become locked in. EC2+ELB+RDS are fairly independent. Even autoscaling doesn't lock you in. That said, CloudFormation, SQS, Kinesis, DynamoDB, etc. are all very sticky services.
- personZ 12y ago
  That's a bit of an extrapolation though, isn't it? Many people simply run VMs that connects to some arbitrary pgsql instance, which might happen to be on RDS if they want to simplify the management of that. Those VMs can absolutely run almost anywhere, and they can connect to just about any instance of pgsql. I heavily use many services on AWS, but can quite literally move the entirety of it to my own servers, Google, Azure, or elsewhere in very short notice. People can choose to use some of the more unique services, but that is not related to RDS.
- correctdarecord 12y ago
  Where you see 'vendor lock-in', I see the opportunity to leverage somebody else's engineering talent to solve commodity problems that our customers don't pay for.

dahdum 12y ago

Different problems, but vendor lock-in isn't really one of them imho. If you are skilled enough to setup pg instead of using RDS you can always move off it to systems under your control. If you don't have the skills, you can migrate to another provider like Heroku. As far as my experience, they aren't extending PG in non-compatible ways.

lewaldman 12y ago

I really don't get all this yadda yadda about AWS lock-in. Which component on AWS doesn't have a OpenSource counter-part that you, having the time, knowledge (;P) and time for it, could not implement on your own infrastructure? Really... It's an honest question from some one that works as Senior AWS architect on a full time job.

bkeroack 12y ago
Imagine you're an early stage startup. You have a handful of overworked, stressed-out engineers trying to ship v1.0. You don't have the time or resources for a dedicated Ops team, so you go with AWS (I think this is a great use case for AWS or any public cloud, btw--it just makes sense at a really early stage startup). You ship your product, get some customers. Fast forward 18-24 months. You have grown enormously, you have lots of customers and revenue projections and expectant investors. Your (now much larger) engineering team has gotten used to AWS conveniences and leveraged a lot of them in the development workflow. Your architecture consists of several layers of ELBs, you have painstakenly set up autoscaling and deployment via Elastic Beanstalk. Your server backups are AMIs. Your data lives in RDS (analytics in Red Shift). Your webservers use Elasticache. SQS is the backbone of your asynchronous job workflow. Customer email traffic goes through SES. Etc. Now your AWS bill is something like $25-30k/month. You're at the point where the pricing differential between real hardware and AWS is getting big, and it will only get worse over time. Now management has to make the hard choice: - Build an Ops team capable of architecting, constructing and deploying new infrastructure on bare metal - 3-6 months of work to go from design to final cut-over - Risk some business interruption in the changeover (downtime, unexpected problems) and slower development iteration until the engineering team gets used to new tools/ways of pushing code out. or - Continue on AWS and eat the bill as cost of doing business. This is vendor lock-in at the most basic level.
- akurilin 12y ago
  Ultimately this is a good problem to have, no? Your startup is alive and growing, you can afford an ops team, your product proved itself. Most startups will have been dead for years at this point.
- 12y ago