4 ms·

I would say it's the complete opposite of lock-in. If more cloud providers follow suit, then one day you might be able to simply `git push` to a different provi

I would say it's the complete opposite of lock-in. If more cloud providers follow suit, then one day you might be able to simply `git push` to a different provider, then wipe away all your old infrastructure. I'm overstating things, but 12 factor apps should be very easy to migrate, excluding things like databases, DNS records, user roles, etc. But I think this might already be true if you're comparing Heroku with AWS.

problems 10y ago
Correct me if I'm wrong, but all the build and deployment steps are being managed via Amazon-specific tools directly, which want you only to use Amazon-specific services, no? That sounds like lock-in to me. It's pretty trivial to do this kind of thing with Jenkins or Gitlab CI and those don't have that issue. And then you can deploy however you want to any provider.
- matthewaveryusa 10y ago
  build an interface around it and then make one AWS implementation and one jenkins/gitlab ci implementation? You only lock yourself in if you allow yourself to lock yourself in.
- nathan_f77 10y ago
  Sure, but Heroku also manages all your build and deployment steps. Migrating away from Heroku is as easy as pushing your code somewhere else, then deleting the app on Heroku. Ideally all of these build and deployment steps are automated for you, because let's face it, most web applications and APIs have very, very similar hosting requirements. Maybe I don't really understand the concept of lock-in. I've never felt "locked in" to anything on AWS, unless you're talking about contracts for reserved instances.
  - noobiemcfoob 10y ago
    Lambda is a good example. You can't pick up and move a lambda solution to another provider without significant overhead, the lock in. Architecturely, migrating a lambda to another compute platform shouldn't be too difficult if its structured well and functionally, but it's still work that would need to be done.
- bentruyman 10y ago
  From what I can tell, this is a web interface wrapper around a suite of Amazon tools – but nothing is forcing you to exclusively use them once you've created your project. > It's pretty trivial to do this kind of thing with Jenkins or Gitlab CI I think you might be trivializing what's being offered here. This is bigger than a CI server.
  - jmagoon 10y ago
    Can you help me understand what is being offered here? Is it basically a wrapper for, in the Rails world, spin up EC2 instance -> install make / git -> clone repo -> bundle install -> install nginx -> configure nginx to whatever app server they have decided you will be using -> set up CI server? I wonder if you can customize how the recipe gets built? It basically just seems like an AWS specific deployment recipe as a service for people who might not be familiar with a tool like Ansible. Is that accurate?

problems 10y ago

Correct me if I'm wrong, but all the build and deployment steps are being managed via Amazon-specific tools directly, which want you only to use Amazon-specific services, no? That sounds like lock-in to me. It's pretty trivial to do this kind of thing with Jenkins or Gitlab CI and those don't have that issue. And then you can deploy however you want to any provider.

matthewaveryusa 10y ago
build an interface around it and then make one AWS implementation and one jenkins/gitlab ci implementation? You only lock yourself in if you allow yourself to lock yourself in.
nathan_f77 10y ago
Sure, but Heroku also manages all your build and deployment steps. Migrating away from Heroku is as easy as pushing your code somewhere else, then deleting the app on Heroku. Ideally all of these build and deployment steps are automated for you, because let's face it, most web applications and APIs have very, very similar hosting requirements. Maybe I don't really understand the concept of lock-in. I've never felt "locked in" to anything on AWS, unless you're talking about contracts for reserved instances.
- noobiemcfoob 10y ago
  Lambda is a good example. You can't pick up and move a lambda solution to another provider without significant overhead, the lock in. Architecturely, migrating a lambda to another compute platform shouldn't be too difficult if its structured well and functionally, but it's still work that would need to be done.
bentruyman 10y ago
From what I can tell, this is a web interface wrapper around a suite of Amazon tools – but nothing is forcing you to exclusively use them once you've created your project. > It's pretty trivial to do this kind of thing with Jenkins or Gitlab CI I think you might be trivializing what's being offered here. This is bigger than a CI server.
- jmagoon 10y ago
  Can you help me understand what is being offered here? Is it basically a wrapper for, in the Rails world, spin up EC2 instance -> install make / git -> clone repo -> bundle install -> install nginx -> configure nginx to whatever app server they have decided you will be using -> set up CI server? I wonder if you can customize how the recipe gets built? It basically just seems like an AWS specific deployment recipe as a service for people who might not be familiar with a tool like Ansible. Is that accurate?