4 ms·

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-devel

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.

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.