Amplify: the good, the bad and the ugly
This article is part of a series of articles that talk about AWS Amplify, but also how to migrate it to a more flexible and extensible infrastructure.
Amplify is an excellent framework for many reasons: (1) ease of use, (2) fast-paced development process, but also (3) speed to market. Throughout this article I will explain the advantages of having such framework, but also the reasons of migrating to a full control infrastructure. Additionally, I will walk you through all the obstacles that I found during the process, but also share with you the lessons learned. Before going further in the article I would like to apologise for the massive amount of gifs regarding one of the best westerns (and movies) of all time.
The good
When i first started using amplify, I got pretty overwhelmed by the amount of documentation available. I got quickly impressed by the amount of features available out of the box and how easy it was to deploy them using their CLI. For my use case, i required a vast number of features, namely:
- Authentication (provided by Cognito)
- Database (provided by DynamoDB)
- Analytics (provided by Pinpoint)
- Hosting (provided by Amplify)
- API (provided by Appsync)
In 15–20 minutes i was able to have a whole infrastructure created and deploy. How cool is that? 🤓
I totally recommend reading the documentation of each one just to have an overview of what they can do, but also to assess the value to your project.
Getting deeper into the framework allowed me to better understand how things worked under the hood. If i was impressed with Cloudformation before starting my journey on amplify, i got even more interested on it after achieving a good understanding level on the amplify framework.
If you are on a startup or a project that have time, budget and resource constraints, i think amplify is the right answer to you.
The bad
My journey in amplify turn out to be more challenging than I was expecting. Not everything was a bed of roses! As the product increases, new features arise, requirements are changed and platforms evolve. That means that I had to adapt data models, authentication details, tracking more events, create more endpoints, etc…
These big amount of changes might come with a price. At first, all those changes might not mean any drastic consequence to the system. However, it may happen that sometimes resources may get tangled during deployment which means that you will have a non-solvable problem. This is a “not so likely” issue that happens. If you are not so experienced with aws services, it will be painful to solve that problem. Fortunately, It didn’t gave me much effort to solve those issue as I had the pleasure to explore aws in the past.
On the other hand, the flexibility and customisation of features might be a limitation. As amplify still in a very young age, you might not be able to fully customise each feature in a way you would like, not because the sub-feature is not going to be supported (which might happen in some cases), but also due to the massive prioritisation list that aws got in hands.
Last but not least, you for any reason, you need to update resources manually, please don’t. The framework is meant to work by using only one source of truth: the CLI. Is totally recommended to not change values by hand, or by mistake, change a file that is generated as soon you commit new amplify changes.
When it comes to price, depending on the set of features that you use, you may get some surprises at the end of the month 😄. If, for some reason, you want to add elastic search to improve the performance of you text-based searches, you may need to take special care about how the bill evolves. As also referred previously, the lack of customisation sometimes forces you to use some configurations that you don’t want or don’t need.
The ugly
Don’t take this title seriously! I tried to follow the article theme as much as possible 🎉 😃. There will come a moment in your product lifecycle that may require that you take full ownership of the cloud resources, or event if you want to change the provider for a particular feature. Those are just two reasons of having to migrate from amplify to a complete new approach. It will depend on the requirements of the product in the long run. Nevertheless, i will try to give my two scents about how the migration was done for a particular feature described above, but also the reason of the move. In my particular case, the major reason to detach from amplify was mainly customisation and ownership of the product infrastructure.
Authentication (provided by Cognito)
The product I was working on tried to improve the way users signed up. Our marketing target included users that were not very fond or experienced with technology. With that in mind, we decided to proceed with a passwordless solution as it seemed a simpler way to attract those users and motivate them to use the application. Depending on whether you move to another authentication provider or keep with cognito, besides the implementation details and constraints, you will always need to make a user migration due to the way credentials are managed. On our specific case, we decided to keep cognito as we were already experienced with it, but also the ease of use. This particular topic deserves to be covered in another article as it was a very extensive and complex problem to solve.
Database (provided by DynamoDB)
**Very important**: By any means, do not remove the database from amplify if you don’t have a duplicate dynamoDB table created. If you remove the database from amplify, all resources related are going to be removed as well, including your tables. According to a ticket that opened back in the day, the problem seems to be solved. Confirm that this works as expected with test resources first before proceeding to your used resources. In a negative case, you will need to create your new table and migrate all data to the new one. Additionally, you might need to attach a dynamoDB stream to the old one and apply changes to the new table, so you keep changes as much up-to-date as possible. This latter approach is more a failsafe if you have a large amount of users in a live environment.
Analytics (provided by Pinpoint)
On our product, analytics got replaced by firebase as it offered more flexibility, more metric features, ability to add feature toggles and A/B testing. All those features were extremely important to test the value of specific features, but also monitor the usage of features.
Hosting (provided by Amplify)
It will depends of what you want to achieve. If you are still using aws resources, the migration is pretty simple to achieve. At first, you will need to create a S3 bucket configure to host a static website (for more info here). In order to deploy the developed frontend code, you just need to upload the final bundle to S3. To apply all your changes and make them visible to the end users, you will need to configure cloudfront in order to work with S3 (for more info here). Additionally, if you need to configure rewrites and redirects, the annoying part was to create a lambda function just for that.
API (provided by Appsync)
The only thing you need to keep in order to keep things working fine is your schema. My solution included the migration to EC2 instance with ECS. This is just one solution. You have plenty of options available. Our main goal was to keep the current schema as much similar as possible with appsync so the cost of change would not be too big.
Final Thoughts
As the amplify docs state, the main purpose of the framework is to give a set o tools and features that allow developers to build a quick and easy applications on AWS. However, the decision of which approach to use will depend on your product requirements and speed to market. My personal experience with amplify is quite positive as it allowed me to increase my knowledge in several aws services, but also develop a product that required to have an MVP in the market ASAP.
