Read on Twitter
I worry a lot about the way people will use EFS support for Fargate, because I think it's another candy-vs-vegetables situation https://aws.amazon.com/about-aws/whats-new/2020/04/aws-fargate-launches-platform-version-14/
There are lots of valid use cases for EFS with Fargate. But when people see something that looks familiar, they are often going to choose it over more cloud-native solutions that have an initial learning curve but a lower total cost of ownership.
EFS is an opaque storage mechanism. It has no data plane API that isn't nfs. You can't inspect the contents without creating a compute node and mounting it. You can't create lifecycle hooks to take action on changes to the data stored in it.
I'm worried about people throwing shared config into EFS as a file, rather than putting that file in S3, or using Parameter Store. I'm worried about people inventing their own communication mechanisms through EFS, rather than using services like SQS.
I worry that people are going to try to use EFS for things that work for multi-process on a shared disk, find that it doesn't work well across a properly distributed system, and then blame EFS, Fargate and AWS, rather than recognizing that they should be building differently.
