3 ms·

(Comment based on experience from an earlier version) I tried it a while ago (more than 1yr ago) and was taken aback by the number of AWS constructs it uses. I

by vivegi 4y ago

(Comment based on experience from an earlier version) I tried it a while ago (more than 1yr ago) and was taken aback by the number of AWS constructs it uses. I wasn't sure what all it was creating on the backend and what the impact of those constructs on the product's recurring billing would be. As-is the cloud abstraction makes it a bit difficult to know (i.e., estimate) what your operating costs are going to be (without using some tools). The Amplify toolset while well-intentioned and already bakes in a lot of AWS guidance/best practice, you feel a loss of fine-grained control over your application's architecture and that was the reason why I did not use it. It may make sense to use it for certain category of apps where you don't have heavy load (i.e., high opex). The speed of development is certainly helpful for prototyping. But, as others have mentioned, the biggest downside comes from the loss of fine-grained control and when you need to go outside of the Amplify framework to integrate or add stuff, it can become a challenge. They may have addressed some of these issues in the latest version. I will have to try it out though.

api 4y ago
> was taken aback by the number of AWS constructs it uses. That's a feature. It's designed to herd you into total dependence on AWS cloud.
sneak 4y ago
> As-is the cloud abstraction makes it a bit difficult to know (i.e., estimate) what your operating costs are going to be (without using some tools). I frequently wonder if this is by design. When you prototype/launch, these are zero or so close to it that you can ignore them. By the time you have product/market fit and start to scale, you are too busy to replace the expensive and tightly-coupled backend with something more cost-effective. It's not really a bait and switch, but it's really the worst kind of insidious lock-in.
- blowski 4y ago
  That’s AWS’s pricing model. And SalesForce, Azure, and many of enterprise SaaS offerings.
- ec109685 4y ago
  It seems like product market fit is such a hard thing to achieve that anything that makes it easier has advantages, and then once that is achieved, you have many options to improve the tech.
philsnow 4y ago
> I tried it a while ago (more than 1yr ago) and was taken aback by the number of AWS constructs it uses. I wasn't sure what all it was creating on the backend and what the impact of those constructs on the product's recurring billing would be. This is common for AWS sales demos. In this case there are cost externalities, but I'm more used to caring about authn/authz externalities, where the flashy demo makes you think "it's so easy" but then you get into the nitty-gritty of making sure that whatever thing is safe to deploy in a production environment. You have to dive very deep into AWS docs and forum posts (hopefully, but less likely if it's a newer AWS product) to find all the ways to limit access to the thing and especially by the thing, especially since so many AWS demos come with IAM policies that are littered with asterisks.
- vivegi 4y ago
  True that. I found it a better bet to use Infra-as-Code and defining everything from the ground up (in the AWS ecosystem, AWS-CDK works well for IaC). It takes some time, but at least we know fully well what constructs are explicitly instantiated and how the dependencies evolve.

by vivegi 4y ago

api 4y ago

> was taken aback by the number of AWS constructs it uses. That's a feature. It's designed to herd you into total dependence on AWS cloud.

sneak 4y ago

> As-is the cloud abstraction makes it a bit difficult to know (i.e., estimate) what your operating costs are going to be (without using some tools). I frequently wonder if this is by design. When you prototype/launch, these are zero or so close to it that you can ignore them. By the time you have product/market fit and start to scale, you are too busy to replace the expensive and tightly-coupled backend with something more cost-effective. It's not really a bait and switch, but it's really the worst kind of insidious lock-in.

blowski 4y ago
That’s AWS’s pricing model. And SalesForce, Azure, and many of enterprise SaaS offerings.
ec109685 4y ago
It seems like product market fit is such a hard thing to achieve that anything that makes it easier has advantages, and then once that is achieved, you have many options to improve the tech.

philsnow 4y ago

> I tried it a while ago (more than 1yr ago) and was taken aback by the number of AWS constructs it uses. I wasn't sure what all it was creating on the backend and what the impact of those constructs on the product's recurring billing would be. This is common for AWS sales demos. In this case there are cost externalities, but I'm more used to caring about authn/authz externalities, where the flashy demo makes you think "it's so easy" but then you get into the nitty-gritty of making sure that whatever thing is safe to deploy in a production environment. You have to dive very deep into AWS docs and forum posts (hopefully, but less likely if it's a newer AWS product) to find all the ways to limit access to the thing and especially by the thing, especially since so many AWS demos come with IAM policies that are littered with asterisks.

vivegi 4y ago
True that. I found it a better bet to use Infra-as-Code and defining everything from the ground up (in the AWS ecosystem, AWS-CDK works well for IaC). It takes some time, but at least we know fully well what constructs are explicitly instantiated and how the dependencies evolve.