3 ms·

Isn't AWS much less prone to customer lock-in? May be I don't have experience with tweaking AWS under heavy high load, but 98% of code I write for backend that

Isn't AWS much less prone to customer lock-in? May be I don't have experience with tweaking AWS under heavy high load, but 98% of code I write for backend that I host on Amazon isn't specific to AWS or it's services in any way.

jrockway 7y ago
Most people are not using generic services on AWS, preferring the Amazon-proprietary things like CloudFormation to open source things like Kubernetes.
- nostrebored 7y ago
  This is a strange comparison. Cloud provider IaC offerings like Cloud Formation are obviously going to be specific to their service. AWS also has EKS for Kubernetes. Things listed as lock in with AWS usually have easy migration paths. E.g. DynamoDB integrates with Database migration service and Lambda functions are easy enough to expose by shifting code to dedicated servers.
  - jrockway 7y ago
    I don't think it's a strange comparison. Cloud providers offer a combination of services that do lock you in and don't lock you in. If you are using EC2 and SSH in to screw around with Linux, you are going to be fine if you get a better deal from GCP. If all of your deployments are managed by a CloudFormation stack and custom scripts that speak the AWS API, you are never going to be able to move. (This is not unique to AWS, of course! Everyone has their value-adds.) A lot of the lock-in is historical. Before there was Kubernetes, there was ECS. I am sure a lot of people embraced containerization and not managing individual machines early, and are now stuck on Amazon's proprietary platform.
bdcravens 7y ago
You can architect an agnostic solution there, but AWS messaging is firmly aimed at lock-in.
- scarface74 7y ago
  And when you do “architect an agnostic solution” you now have the worse of both worlds. You’re spending more on hardware than bare metal and you’re spending just as much on management and development time”. Just because AWS spent years both creating an alternative to Oracle and millions migrating, doesn’t mean that your company is. No matter how often some bushy tailed developer tells the CTO that they used the “repository pattern and standard sql”, they aren’t going to move away from their six figure+ Oracle installation. The risk of regressions are too high and the benefits are usually not worth it.
  - bdcravens 7y ago
    I was responding to the parent comment, which said nothing about Oracle or any specific implementation.
    - scarface74 7y ago
      I’m more responding to the sentiment of “avoiding lock in”, at a certain scale, you’re always “locked into” to your architectural choices where it doesn’t make sense to spend the time or effort to try to avoid it.
  - golergka 7y ago
    Can you please explain how exactly am I having worse of both worlds here? Not trying to prove you wrong, genuinely curious: if I have a generic NodeJS app with PotgreSQL hosted in RDS and, say, use AWS-specific services like S3 and Cloudwatch, am I doing something wrong?
    - scarface74 7y ago
      No. I’m saying just the opposite. You see patterns like this from “architects” who want to avoid “lockin”: - A DBFactory that creates an instance of an OracleRepository that they access through an IGenericRepository interface just in case later on they decide to use a different database and then they don’t take advantage of any Oracle specific features for fear of “lock in”. - A StorageManagerFactory that you call to create a S3StorageManager that implements an IStorageManager just in case later they decide to move from S3 they can “migrate easily” You’ll find people who will spin up a bunch of EC2 instances and host their own logging, queueing, messaging servers to avoid using AWS specific services. Now they are spending more for hosting than just going to a colo and spending just as many man hours babysitting infrastructure. I’m saying that once you choose your foundational infrastructure pieces, no matter what they are, it usually makes sense to go all in instead of creating layers of abstraction.
hiram112 7y ago
Not exactly. If you stick to EC2 or containers with general Linux for your servers, and RDS Postgres and Mysql for DBs, and similarly for other services, you supposedly would be able to move to another cloud without issue. We thought we'd be okay. But when AWS started getting too expensive and we began looking to migrate, we discovered that there was a lot of 'glue' in our stack using bits and pieces of AWS-specific services. A continuous integration was using S3 buckets and Lambda, a few clever devOps guys had found ways to create alarms with SNS and SQS. So while 90% of it was just a matter of moving to general CentOS containers on another platform and spinning up new Postgres and MySql and Mongo instances, that 10% of AWS specific code still causes issues that had to be remedied. If I were in charge of a large infrastructure on AWS, the first thing I'd do is absolutely lock down every service that wasn't explicitly whitelisted, and open them as needed. Not wait till half your operation depends on dozens of AWS services that, while make things easy initially, lock you in to their platform.
- AtlasBarfed 7y ago
  THere needs to be a broad abstraction toolset to enable hybrid cloud. The ones that should be 100% motivated to develop these tools (the Apache ones are ... meh, and terraform/ansible/config management always gets hard-wired to your cloud) are obviously Google and others that are also-rans. Google might not be doing it to keep Amazon out of their roadhouse. There's still meta-tooling for admin and management that are hard to abstract, but come on. K8s is the opportunity to do this, and also serverless to a lesser degree.
- epiphanitus 7y ago
  Impractical thought experiment: Leaving the capital expenditures for the data centers aside, what would it take to build an OS clone of AWS?
  - xchaotic 7y ago
    That doesn’t make sense a lot of what AWS provides is services such as cloud front at scale. You’d still need to test at scale so infrastructure and experience at scale is part of what makes AWS successful and profitable

jrockway 7y ago

Most people are not using generic services on AWS, preferring the Amazon-proprietary things like CloudFormation to open source things like Kubernetes.

nostrebored 7y ago
This is a strange comparison. Cloud provider IaC offerings like Cloud Formation are obviously going to be specific to their service. AWS also has EKS for Kubernetes. Things listed as lock in with AWS usually have easy migration paths. E.g. DynamoDB integrates with Database migration service and Lambda functions are easy enough to expose by shifting code to dedicated servers.
- jrockway 7y ago
  I don't think it's a strange comparison. Cloud providers offer a combination of services that do lock you in and don't lock you in. If you are using EC2 and SSH in to screw around with Linux, you are going to be fine if you get a better deal from GCP. If all of your deployments are managed by a CloudFormation stack and custom scripts that speak the AWS API, you are never going to be able to move. (This is not unique to AWS, of course! Everyone has their value-adds.) A lot of the lock-in is historical. Before there was Kubernetes, there was ECS. I am sure a lot of people embraced containerization and not managing individual machines early, and are now stuck on Amazon's proprietary platform.

bdcravens 7y ago

You can architect an agnostic solution there, but AWS messaging is firmly aimed at lock-in.

scarface74 7y ago
And when you do “architect an agnostic solution” you now have the worse of both worlds. You’re spending more on hardware than bare metal and you’re spending just as much on management and development time”. Just because AWS spent years both creating an alternative to Oracle and millions migrating, doesn’t mean that your company is. No matter how often some bushy tailed developer tells the CTO that they used the “repository pattern and standard sql”, they aren’t going to move away from their six figure+ Oracle installation. The risk of regressions are too high and the benefits are usually not worth it.
- bdcravens 7y ago
  I was responding to the parent comment, which said nothing about Oracle or any specific implementation.
  - scarface74 7y ago
    I’m more responding to the sentiment of “avoiding lock in”, at a certain scale, you’re always “locked into” to your architectural choices where it doesn’t make sense to spend the time or effort to try to avoid it.
- golergka 7y ago
  Can you please explain how exactly am I having worse of both worlds here? Not trying to prove you wrong, genuinely curious: if I have a generic NodeJS app with PotgreSQL hosted in RDS and, say, use AWS-specific services like S3 and Cloudwatch, am I doing something wrong?
  - scarface74 7y ago
    No. I’m saying just the opposite. You see patterns like this from “architects” who want to avoid “lockin”: - A DBFactory that creates an instance of an OracleRepository that they access through an IGenericRepository interface just in case later on they decide to use a different database and then they don’t take advantage of any Oracle specific features for fear of “lock in”. - A StorageManagerFactory that you call to create a S3StorageManager that implements an IStorageManager just in case later they decide to move from S3 they can “migrate easily” You’ll find people who will spin up a bunch of EC2 instances and host their own logging, queueing, messaging servers to avoid using AWS specific services. Now they are spending more for hosting than just going to a colo and spending just as many man hours babysitting infrastructure. I’m saying that once you choose your foundational infrastructure pieces, no matter what they are, it usually makes sense to go all in instead of creating layers of abstraction.

hiram112 7y ago

Not exactly. If you stick to EC2 or containers with general Linux for your servers, and RDS Postgres and Mysql for DBs, and similarly for other services, you supposedly would be able to move to another cloud without issue. We thought we'd be okay. But when AWS started getting too expensive and we began looking to migrate, we discovered that there was a lot of 'glue' in our stack using bits and pieces of AWS-specific services. A continuous integration was using S3 buckets and Lambda, a few clever devOps guys had found ways to create alarms with SNS and SQS. So while 90% of it was just a matter of moving to general CentOS containers on another platform and spinning up new Postgres and MySql and Mongo instances, that 10% of AWS specific code still causes issues that had to be remedied. If I were in charge of a large infrastructure on AWS, the first thing I'd do is absolutely lock down every service that wasn't explicitly whitelisted, and open them as needed. Not wait till half your operation depends on dozens of AWS services that, while make things easy initially, lock you in to their platform.

AtlasBarfed 7y ago
THere needs to be a broad abstraction toolset to enable hybrid cloud. The ones that should be 100% motivated to develop these tools (the Apache ones are ... meh, and terraform/ansible/config management always gets hard-wired to your cloud) are obviously Google and others that are also-rans. Google might not be doing it to keep Amazon out of their roadhouse. There's still meta-tooling for admin and management that are hard to abstract, but come on. K8s is the opportunity to do this, and also serverless to a lesser degree.
epiphanitus 7y ago
Impractical thought experiment: Leaving the capital expenditures for the data centers aside, what would it take to build an OS clone of AWS?
- xchaotic 7y ago
  That doesn’t make sense a lot of what AWS provides is services such as cloud front at scale. You’d still need to test at scale so infrastructure and experience at scale is part of what makes AWS successful and profitable