4 ms·

I don't personally feel like Lambdas themselves are the hard lock-in. It's the stuff around them that really gets into your code or forces specific patterns. S

by tyingq 4y ago

I don't personally feel like Lambdas themselves are the hard lock-in. It's the stuff around them that really gets into your code or forces specific patterns. SQS, SNS, Dynamo, Kinesis, EventBridge, etc.

preommr 4y ago
Which frankly are the essential parts of a robust cloud architecture. Deploying a server is trivial - just dump it on any kind of compute resource. Managing fault-tolerance and monitoring, etc. between those services is the tricky part.
- mschuster91 4y ago
  IME, not if you're using Terraform with proper modularization and can stick to the commonly available feature set. Have one layer of modules that describe what you want (e.g. a virtual server, database, monitoring) and behind that a separate layer that implements it (e.g. creates an EC2 instance, an RDS database or a CloudWatch alert).
  - scarface74 4y ago
    Terraform is not “cloud agnostic” anymore than using Python with the various cloud providers SDKs. Each provider within TF is tied tightly with the cloud provider. Standard Disclaimer: yes I work at AWS and I do IAC with the CloudFormation or TF depends on what the customer wants
  - Karunamon 4y ago
    That's a nonstarter just because of how you describe the various services at each cloud provider. For instance, Google cloud is big into using "projects" as organizers for resources, where the closest analogue in AWS land is an entirely separate account.
throwawayx35fw 4y ago
In my opinion, SQS shouldn't be on that list. You save a lot of time and resources just using SQS instead of setting up your own servers. And the lock-in is not as problematic as Lambdas etc. It doesn't require much code change to move to an alternative message queue (RabbitMQ etc.), so the lock-in is minimal. In my projects, I just need to change a few lines of configuration code and the actual message processing code should remain the same.

by tyingq 4y ago

preommr 4y ago

Which frankly are the essential parts of a robust cloud architecture. Deploying a server is trivial - just dump it on any kind of compute resource. Managing fault-tolerance and monitoring, etc. between those services is the tricky part.

mschuster91 4y ago
IME, not if you're using Terraform with proper modularization and can stick to the commonly available feature set. Have one layer of modules that describe what you want (e.g. a virtual server, database, monitoring) and behind that a separate layer that implements it (e.g. creates an EC2 instance, an RDS database or a CloudWatch alert).
- scarface74 4y ago
  Terraform is not “cloud agnostic” anymore than using Python with the various cloud providers SDKs. Each provider within TF is tied tightly with the cloud provider. Standard Disclaimer: yes I work at AWS and I do IAC with the CloudFormation or TF depends on what the customer wants
- Karunamon 4y ago
  That's a nonstarter just because of how you describe the various services at each cloud provider. For instance, Google cloud is big into using "projects" as organizers for resources, where the closest analogue in AWS land is an entirely separate account.

throwawayx35fw 4y ago

In my opinion, SQS shouldn't be on that list. You save a lot of time and resources just using SQS instead of setting up your own servers. And the lock-in is not as problematic as Lambdas etc. It doesn't require much code change to move to an alternative message queue (RabbitMQ etc.), so the lock-in is minimal. In my projects, I just need to change a few lines of configuration code and the actual message processing code should remain the same.