My stack is Wildfly, angular, spring, RDS, cloudfront. Frontend resources (html/js etc) are stored in app (ie delivered by Wildfly).
For backend and DB I can deploy with zero downtime with 2 EC2 behind ELB, but I am not sure how to handle this scenario:
User get old js/html from our server -> deployment of new version done -> user click on something which use old api (eg, the new version has a new mandatory param)
Is there a way to avoid this? I can only think of putting default value for the new param. Or would API versioning make sense here?
Another question: what if the frontend resources are delivered by cloudfront + s3? how to make the deployment of new resources to s3 in sync with backend?
I can only think of putting default value for the new param. Or would
API versioning make sense here?
This sounds like exactly what API versioning is intended to solve. You would change API versions anytime there is a change that would break clients of the previous version.
Another question: what if the frontend resources are delivered by
cloudfront + s3? how to make the deployment of new resources to s3 in
sync with backend?
Deploying them at the same time is up to you. That's part of your deployment process that you need to automate somehow. You can use versioning and order of deployment to help some here. For example, if your entire front-end is deployed on S3:
Deploy a new version of your API, under a new API version number
Deploy new static UI resources
Issue a CloudFront cache invalidation
Users start seeing new front-end resources that reference the new back-end API version
If your front-end UI is a mix of EC2 server dynamic resources and S3 static resources, and the EC2 UI components and the API are updated as part of the same deployment, then you can use a version prefix for your static resources on S3 to allow multiple versions to be available at once. For example:
Deploy new static UI resources to S3, with a new version prefix. This ensures that both the previous version(s) of the S3 resources and the new version are available at the same time.
Deploy the EC2 app, which updates both the EC2 UI components and the API
Users start loading the new version of the app from EC2, which references static resources under a new version prefix, which CloudFront then caches and serves
Obviously those are just a few scenarios and your situation probably differs in some way. In general you need to use versioning of any resources (static S3 resources, API resources, etc.) and a smart deployment order, to ensure that the end user doesn't see an interruption in service.
Related
I want to deploy NextJS on AWS using AWS CDK for a POC and was looking at options. In the NextJS docs, it says that we can just create an instance and run npm run build && npm start, it will start the service for us. However, this is not the most optimised way of deploying.
Vercel deploys this in the most optimized way possible:
How can I do the same with AWS? How can I serve the static assets and pages via Cloudfront CDN and the server side rendered pages and APIs via either Lambda or ECS? Is there a step by step guide that I can follow to split out the build files for the same?
Other options I explored
AWS Amplify: As it is a premium service, I feel doing all this by my self would be a lot cheaper and gives me more flexibility in CDK (I am not sure how Amplify works behind the scenes to deploy the nextjs assets on a S3 + Cloudfront + Lambda stack)
serverless framework: There is a plugin to deploy nextjs. But, I want to have full control over the deployment and don't want to depend on any external framework. Want to do it natively using AWS CDK.
Any pointers to do this natively using AWS CDK would be helpful. Thanks.
Deploying Next.js as a serverless application requires a bunch of services when you don't want to pack the whole Next.js server into a single Lambda.
My current setup of AWS services to achieve this looks like the following:
It consists of 3 main resources:
CloudFront
This works as a serverless reverse proxy that routes the traffic from the Internet to S3 (JavaScript, prerendered pages) or Lambda (Server rendered pages).
When using the image optimization capabilities of Next.js you also need an extra service that provides the API for it.
S3
Since you don't want to invoke Lambdas just to serve static content, you need a S3 bucket where those files are stored and served from.
Lambda
The Lambdas are then used to serve the server generated pages (SSR & API).
They contain a minimal version of the Next.js server (e.g. without the static files that are served from S3).
I built this setup with Terraform, so there is no native CDK solution available at this time.
But most of it could be simply translated to CDK since the model behind Terraform and CDK is pretty much the same.
Source code of the Terraform module is available on GitHub: https://github.com/milliHQ/terraform-aws-next-js
AWS Amplify and the "Applications" feature within AWS Lambda seem to have a few things in common:
Both seem to be a wrapper around several AWS resources
Both walk you through a guided setup to provision a working AWS stack
Both set up some CI/CD pipelines for you so that Git commits trigger a build and deploy
So what are the differences between these two services, and what are some scenarios where you might want to choose one over the other?
AWS Amplify is a toolchain for front-end developers to interact with AWS resources. It provides a cli program to manage resources and (JS/Android/iOS) libraries to integrate them into your front-end applications.
It doesn't 'wrap' resources, but is merely a convenience layer to manage them (it is somewhat similar to AWS SAM); Amplify generates CloudFormation templates, stores those locally, and uses aws-cli to provision them. Note that Amplify can also be used just as a front-end library to integrate resources that are already set up.
AWS Lambda Applications is an actual AWS service, or rather a feature of AWS Lambda. It groups related resources, so they can be managed and deployed as if it was a single resource.
... what are
some scenarios where you might want to choose one over the other?
Amplify is aimed at web- and mobile developers: it allows them to manage backend resources without much backend knowledge.
It is not a matter of 'using one over the other'; they can actually be used in conjunction with each other.
I am looking at using AWS to host the website for my personal business. The website is simple and (currently) does not require a server. My website is written in React and does have some npm packages installed and also uses a router to navigate to other pages on my site.
Will an S3 bucket host a website that has routes and dependencies? What if my site grows and I eventually need a server. Will I be able to attach an EC2 instance to my site?
Option 1:
Take a look at AWS Amplfiy as it might manage everything for you in Option 2 and super easy to get started. I use this for several website. Usually only takes minutes to get working if you already have an AWS account.
In short, from the AWS Console you can connect your app from GitHub, BitBucket, GitLab, and AWS CodeCommit. It usually will auto detect the type of project you have.
Amplify will create a managed S3 bucket and setup CloudFront you. It also registers a webwook with GIT so whenever you commit on a specific branch will rebuild and publish your site. You can even have multiple branch so www.acme.com -> master and working.acme.com -> branch
Option 2:
S3 <--- CloudFront <-- Lambda#Edge <-- Browser
EC2 <--|
Store you file in S3
Use CloudFront (Content Delivery Network)
Create a Lambda#Edge to handle your routing.
Then in the future you can an EC2 server.
Look at the answer for the Lambda#Edge Multiple Cloudfront Origins with Behavior Path Redirection
I am a total beginner and just completed the first version of my web application.
I am using Docker, Nginx, Angular & Django. Note that the backend works on static files and uses a simple database for User Registration.
I want to deploy it to a free, cloud solution. I heard that I can use AWS Elastic Beanstalk but found a bit complicated both the configuration and the pricing policy.
Question
Can anybody guide me through what to consider or even better, what selection I have to make in order to host my web app on AWS without a charge?
PS: I don't know If I have to mention this, but in case the web app attracts a satisfying number of users, I would adjust the implementation in order the user to be able to upload and use my services upon their own data (and not upon the csv files). In this case, I might have to use other AWS services or migrate to another cloud solution. Just to say that both of them are welcome!
You can easily host an Angular app on AWS within the free tier (1 year) limits. I have hosted a handful of Angular apps so far using AWS S3 + AWS Cloudfront.
AWS S3 is used to host your static files. You first do a ng serve --prod where the Angular compiler will generate a /dist folder (in your project directory) containing all the static files (i.e. js, images, fonts, etc) required to run your angular app. Then you upload all your static files onto a AWS S3 bucket.
AWS Cloudfront is a cloud caching service. As the word "cache" suggests, it caches your static files. By setting up a Cloudfront cache in-front of your S3 bucket, it allows you to bypass the monthly 20,000 GET requests limited for free tier - because users' HTTP requests will be served from the Cloudfront cache instead of, directly from your S3 bucket. Cloudfront free tier gives you 2 million HTTP(S) requests per month.
The good thing about hosting on AWS S3 instead of an EC2 instance (P.S. Elastic beanstalk also creates EC2 instance) is that you can have multiple S3 buckets and Cloudfront distributions in 1 free tier account. As long as you stay within the limits, S3: 2,000 PUT Requests, 20,000 GET request; Cloudfront: 2million HTTPS requests. You can end up hosting several apps with one AWS free tier account. But if you're using EC2, you're almost limited to only 1 instance (because 31days x 24 hours = 744hrs which is 6 hours shy of the 750 hours limit). Unless you set up for your EC2 instances to turn on and off.
There are plenty of guides demonstrating how to do this, here are some of them:
Deploy an Angular with S3 and CloudFront
Use S3 and CloudFront to host Static Single Page Apps (SPAs) with HTTPs and www-redirects
Assuming you know how to deploy to a linux machine, Elastic Beanstalk is not useful for your use case (it's for automated scaling). I would do the following:
AWS S3 to deploy your angular app using Static Website hosting (one possible tutorial is this https://medium.com/#peatiscoding/here-is-how-easy-it-is-to-deploy-an-angular-spa-single-page-app-as-a-static-website-using-s3-and-6aa446db38ef
Amazon ECS( Container service) is used to deploy your containers. This will help with that step.
OR
Simple Amazon EC2 (its a linux server) with the entire environment set up with docker.
What are your suggestions for how I should creating maintenance/administration pages that allow me to add/modify/report on entries in my DynamoDB tables on AWS?
What I would like to do is to create web pages that are hosted in AWS S3 but allow me to script Dynamo DB access.
I'm trying to avoid setting up something like a LAMP stack on another host.
Without any backend code... JavaScript (or a derivative). Try the AWS SDK for JavaScript. Or, you can use API Gateway, Lambda and JavaScript. Either work with S3-only hosting. Lambda could hide some implementation details behind an API and you don’t need to worry about managing servers. More moving parts is the trade-off.