4 ms·

What lock-in? I'm genuinely curious, I can't imagine it would be hard at all to move my service from Fargate to anything else. It's just docker containers and D

What lock-in? I'm genuinely curious, I can't imagine it would be hard at all to move my service from Fargate to anything else. It's just docker containers and DNS, I haven't done anything Fargate specific.

pbalau 7y ago
These days "vendor lock-in" seems to be code word for "have no idea how this thing works".
tilolebo 7y ago
Seems like vendor lock-in is the new term for "Not Invented Here". I also fail to see how Fargate locks you in: as you say, it's just docker and DNS, with a sprinkle of environment variables if you use it with SSM Parameter Store.
llarsson 7y ago
I assume what is referred to is rather of the "we have built all this internal tooling, release pipelines and processes, internal know-how even among non-developers" etc that any technology choice is accompanied by. These effectively lock you in and costs real money to replace.
- tilolebo 7y ago
  I get that, although in many cases the AWS-specific tooling needed to build and deploy services running on Fargate is minimal. It's basically logging in to ECR and triggering an ECS service update (2 API calls). I voluntarily keep out the networking and IAM parts out, as I believe they are also needed for a Kubernetes cluster. What I don't get is that many people seem to think that they are lock-in free just by choosing Kubernetes. But: 1. Kubernetes itself is a very, very opinionated piece of software. You are not free, you have to go the Kubernetes way. 2. The overhead of learning and maintaining Kubernetes is real, compared to a more managed solution like Fargate. 3. If you use Kubernetes, you still have to set up the underlying infrastructure. This infra is still vendor specific. If you go for a managed Kubernetes like GKE or EKS, you still have to deal with a vendor-specific API.
  - airocker 7y ago
    I would rather run kops and not GKE/EKS. Also, if needed, for the vendor specific infra we can use terraform. I believe Kubernetes stack is more intuitive than any AWS (or GC or Azure) software. The open source approach will spur innovation that will outclass Fargate by miles. Fargate provides single instances, you would need networks/routes/Load balancers/auto scalers to make anything meaningful. I bet they will all be provided as AWS way of doing the same if Fargate gets any traction.
    - scarface74 7y ago
      And you’re still locked in to your cloud provider with Terraform since every provisioner is cloud provider specific.
      - airocker 7y ago
        At least the code is uniform and extendable.
        scarface74 7y ago
        Saying your code is uniform because the syntax is the same is about like saying developing a website with Java and developing an Android app is “uniform”.
- tilolebo 7y ago
  "Don't get locked up into avoiding lock-in" https://martinfowler.com/articles/oss-lockin.html https://martinfowler.com/articles/oss-lockin.html
  - airocker 7y ago
    """ Gregor Hohpe is a technical director in Google Cloud’s office of the CTO. """ He definitely has the intent to market.
jasonlotito 7y ago
Fargate provisioning is tied to AWS, unlike Kubernetes or other systems that aren't Cloud Vendor specific. If I build tooling around Kubernetes, I can move from Google to EKS without needing to change it. However, if I build tooling around Fargate, it's useless outside of AWS. Keep in mind, this doesn't make it bad or impossible to move out. Just more work. That all being said, I still like Fargate even with it tying me to using AWS. I think the pros out-weight the cons.
- scarface74 7y ago
  Realistically, if you are running at a scale to actually need K8s and not just doing Resume Driven Development, what are the chances that your CTO is actually going to risk moving their entire infrastructure to another cloud provider?
l33tman 7y ago
The docker containers are the least complicated bit in production deploys. Orchestrating all the up/down-scaling and releasing, binding of IP-numbers, DNSes etc.. that's where the potential "lock-in" comes (although I would say from my experience that the main problem with Fargate is it's several times more expensive than simply putting ECS on spot instances).
streetcat1 7y ago
The vendor lock-in is having to code/deploy against AWS API instead of Kubernetes API. It is no different than coding to Solaris or windows API. The problem with AWS (or any cloud provider) is that nobody can create its own cloud services. See the case of Mongo DB. AWS is a closed source platform, which can be extended only by Amazon. This will be more evident once more operators will be created for kuberentes.
- staticassertion 7y ago
  What API am I coding against? I don't get it, I don't touch any Fargate API. My Fargate cluster runs DGraph, an open source database, which my clients connect to the same way they would if it were on EC2.
  - streetcat1 7y ago
    Right, this is hidden from you via the AWS cli tools and UI. But, as in any OS, there is an API. Yes, Farage does add the serverless features over EC2. However, you are in AWS ecosystem.
    - staticassertion 7y ago
      Sorry, but no? There is no API. My service runs in a container. It knows literally nothing about Fargate. I use an open source database on it. My clients use an open source client to talk to that database, and rely on DNS for service discovery. The only AWS specific APIs I rely on are for my eventing system - S3 + SQS, which sit in a generic library that I could easily swap out for fsnotify, rabbitmq, etc. None of that has to do with Fargate.

pbalau 7y ago

These days "vendor lock-in" seems to be code word for "have no idea how this thing works".

tilolebo 7y ago

Seems like vendor lock-in is the new term for "Not Invented Here". I also fail to see how Fargate locks you in: as you say, it's just docker and DNS, with a sprinkle of environment variables if you use it with SSM Parameter Store.

llarsson 7y ago

I assume what is referred to is rather of the "we have built all this internal tooling, release pipelines and processes, internal know-how even among non-developers" etc that any technology choice is accompanied by. These effectively lock you in and costs real money to replace.

tilolebo 7y ago
I get that, although in many cases the AWS-specific tooling needed to build and deploy services running on Fargate is minimal. It's basically logging in to ECR and triggering an ECS service update (2 API calls). I voluntarily keep out the networking and IAM parts out, as I believe they are also needed for a Kubernetes cluster. What I don't get is that many people seem to think that they are lock-in free just by choosing Kubernetes. But: 1. Kubernetes itself is a very, very opinionated piece of software. You are not free, you have to go the Kubernetes way. 2. The overhead of learning and maintaining Kubernetes is real, compared to a more managed solution like Fargate. 3. If you use Kubernetes, you still have to set up the underlying infrastructure. This infra is still vendor specific. If you go for a managed Kubernetes like GKE or EKS, you still have to deal with a vendor-specific API.
- airocker 7y ago
  I would rather run kops and not GKE/EKS. Also, if needed, for the vendor specific infra we can use terraform. I believe Kubernetes stack is more intuitive than any AWS (or GC or Azure) software. The open source approach will spur innovation that will outclass Fargate by miles. Fargate provides single instances, you would need networks/routes/Load balancers/auto scalers to make anything meaningful. I bet they will all be provided as AWS way of doing the same if Fargate gets any traction.
  - scarface74 7y ago
    And you’re still locked in to your cloud provider with Terraform since every provisioner is cloud provider specific.
    - airocker 7y ago
      At least the code is uniform and extendable.
      - scarface74 7y ago
        Saying your code is uniform because the syntax is the same is about like saying developing a website with Java and developing an Android app is “uniform”.
tilolebo 7y ago
"Don't get locked up into avoiding lock-in" https://martinfowler.com/articles/oss-lockin.html https://martinfowler.com/articles/oss-lockin.html
- airocker 7y ago
  """ Gregor Hohpe is a technical director in Google Cloud’s office of the CTO. """ He definitely has the intent to market.

jasonlotito 7y ago

Fargate provisioning is tied to AWS, unlike Kubernetes or other systems that aren't Cloud Vendor specific. If I build tooling around Kubernetes, I can move from Google to EKS without needing to change it. However, if I build tooling around Fargate, it's useless outside of AWS. Keep in mind, this doesn't make it bad or impossible to move out. Just more work. That all being said, I still like Fargate even with it tying me to using AWS. I think the pros out-weight the cons.

scarface74 7y ago
Realistically, if you are running at a scale to actually need K8s and not just doing Resume Driven Development, what are the chances that your CTO is actually going to risk moving their entire infrastructure to another cloud provider?

l33tman 7y ago

The docker containers are the least complicated bit in production deploys. Orchestrating all the up/down-scaling and releasing, binding of IP-numbers, DNSes etc.. that's where the potential "lock-in" comes (although I would say from my experience that the main problem with Fargate is it's several times more expensive than simply putting ECS on spot instances).

streetcat1 7y ago

The vendor lock-in is having to code/deploy against AWS API instead of Kubernetes API. It is no different than coding to Solaris or windows API. The problem with AWS (or any cloud provider) is that nobody can create its own cloud services. See the case of Mongo DB. AWS is a closed source platform, which can be extended only by Amazon. This will be more evident once more operators will be created for kuberentes.

staticassertion 7y ago
What API am I coding against? I don't get it, I don't touch any Fargate API. My Fargate cluster runs DGraph, an open source database, which my clients connect to the same way they would if it were on EC2.
- streetcat1 7y ago
  Right, this is hidden from you via the AWS cli tools and UI. But, as in any OS, there is an API. Yes, Farage does add the serverless features over EC2. However, you are in AWS ecosystem.
  - staticassertion 7y ago
    Sorry, but no? There is no API. My service runs in a container. It knows literally nothing about Fargate. I use an open source database on it. My clients use an open source client to talk to that database, and rely on DNS for service discovery. The only AWS specific APIs I rely on are for my eventing system - S3 + SQS, which sit in a generic library that I could easily swap out for fsnotify, rabbitmq, etc. None of that has to do with Fargate.