I am a beginner in this and I am trying to figure out what would be the best architecture and workflow for the following use-case (I am using React on front, and nodejs on backend, but this might be irrelevant considering this is a question regarding architecture):
Use-case:
User lands on my page, where I have a table already filled with customers from RDS table. User has an option to either delete a customer (corresponding row) or edit that customer, and all the changes done on frontend should be recorded in a datebase so that next time when user visits the page he/she gets the latest database state. The problem that I have is that I am tasked with implementing this architecture using services such as ECR, ECS ( I opted for Fargate, as serverless solution ), RDS but I have no idea how the workflow should look like and what role would lambdas have in case they are necessary ( or are they? ). Considering also that I need to use RDS, which option PostgreSQL/MySQL/Aurora would be the best fit for this use-case?
What I've tried up till now:
What I've managed to do up till now, is I dockerized my react app (containing the the frontend table where customers will go), pushed it to ECR, created a cluster inside of ECS with a most default task definition holding the ecsTaskExecution Role, a container holding the image from ECR, and a service that's responsible for running the task. I also added Application Load Balancer in front of the ECS cluster so that my react app can be reached from browser (planning to add my personal domain).
Problem:
I am clueless as to who should "speak" to who when it comes to all these individual services, how many containers should I have, are lambdas as functions that will do the deleting & updating needed, or do they only serve as triggers which will leave all the processing to ECS tasks? Basically I am having struggles with imagining the whole picture of the workflow. Any ideas?
Thanks in advance. :)
Well after a few days of experimenting and reading, this is the architecture I came up with:
ReactJS application hosted on S3, NodeJS application ( Express server ) containerized on docker, pushed to ECR and then on ECS (I choose EC2 Linux + Networking for ECS cluster and then according to that I choose EC2 for Task which is responsible for running my ECR container), while for a database I choose MySQL inside of RDS.
So basically the communication is happening between S3 -> ECS -> RDS ( ReactJS -> NodeJS -> MySQL ).
I have a set of AWS Elastic beanstalk using Docker based configuration for both web server and worker server. The way we have setup is that the java process inside docker allocates 70% of the box memory when starting.
Now the first deployment works fine, but when I try to update application version with in-place Rolling update, Elastic beanstalk tries to start an additional docker container with the java process before stopping the existing one. This fails the deploy as the Java server is not able to allocate the required memory. Is there a way that I can setup AWS to kill the old docker instance before starting the new one during deployment?
I even tried Rolling with additional batch, but that one only works for the first batch and then fails for subsequent ones.
immutable updates can be the way to go for you, it basically recreates the EC2 instances completely on every deploy
Open the Elastic Beanstalk console.
Navigate to the management page for your environment.
Choose Configuration.
In the Rolling updates and deployments configuration category,
choose Modify.
Select immutable on deploy policy
Apply
you can check more on how it works here
I was using a free tier aws account in which I had one ec2 machine (Linux). I have a simple website with backend server running on django at 8000 port and front end server written in angular and running on http (80) port. I used nginx for https and redirection of calls to backend and frontend server.
Now for backend build system, I did these 3 main steps (which I automated by running jenkins on the same machine).
1) git pull (Pull the latest code from repo).
2) Do migrations (Updating my db with any new table).
3) Restarting the django server. (I was using gunicorn).
Now, I split my front end and backend server into 2 different machines using auto scaling groups and I am now using ELB (Aws Elastic Load balancer) to route the requests. I am done with the setup. But now I am having problem in continuous deployment. The main thing is that ELB uses auto scaling groups which in turn uses AMI.
Now, since AMI's are created once, my first question is how to automate this process and deploy my latest code in already running aws servers.
Second, if I want to run few steps just once for all the servers like my second step of updating db with new tables then how to achieve that.
And also third if these steps need to run on a machine, then do I need to have another ec2 instance to automate the process of creating AMI, updating auto scaling groups with it and then deploying latest code in that.
So, basically I want to know the best practices that people follow in deploying latest code in aws machines that were created by auto scaling groups with the help of AMI. Also I use bitbucket for code management.
First Question: how to automate 'package based deployment'.
Instead of creating a new AMI for every release, create a baseline AMI which only changes when your new release require OS changes / security patches / etc. Look into tools such as packer to create AMIs automatically. In order to automate your code deployment when it changes, you can use a package-based deployment approach, which means you create a package for every release (Should be part of your CI process), which is stored in some repository such as Nexus, Artifactory, or even a simple S3 bucket.
When you deploy a new instance of your application, it should run some sort of script to pull and unpack/install that package on the instance < this is the basic concept, there are many tools that can help you achieve this, for example, Chef, or AWS CloudFormation.
So essentially, Step 1 should pull the code, create the package and store it in some repository available to your application servers > this can be done offline.
Second Question: How to run other tasks such as updating database schema.
As mentioned above, this can also be part of your 'deployment' automation, so if you are using Chef or even a simple bash script, it can update a database schema before unpacking the new code, this really depends on your database, how you manage it, and who orchestrates the deployment.
For example, you could have a Jenkins job that pulls the new schema and updates your database when ever you rollout a release.
Your third question can be solved by Packer, it can spin up instances, create an AMI, and terminate the instance.
Read more into CICD, and CICD related tools.
I'm developing a prototype IoT application which does the following
Receive/Store data from sensors.
Web application with a web-based IDE for users to deploy simple JavaScript/Python scripts which gets executed in Docker Containers.
Data from the sensors gets streamed to these containers.
User programs can use this data to do analytics, monitoring etc.
The logs of these programs are outputted to the user on the webapp
Current Architecture and Services
Using one AWS EC2 instance. I chose EC2 because I was trying to figure out the architecture.
Stack is Node.js, RabbitMQ, Express, MySQl, MongoDB and Docker
I'm not interested in using AWS IoT services like AWS IoT and Greengrass
I've ruled out Heroku since I'm using other AWS services.
Questions and Concerns
My goal is prototype development for a Beta release to a set of 50 users
(hopefully someone else will help/work on a production release)
As far as possible, I don't want to spend a lot of time migrating between services since developing the product is key. Should I stick with EC2 or move to Beanstalk?
If I stick with EC2, what is the best way to handle small-medium traffic? Use one large EC2 machine or many small micro instances?
What is a good way to manage containers? Is it worth it use swarm and do container management? What if I have to use multiple instances?
I also have small scripts which have status of information of sensors which are needed by web app and other services. If I move to multiple instances, how can I make these scripts available to multiple machines?
The above question also holds good for servers, message buses, databases etc.
My goal is certainly not production release. I want to complete the product, show I have users who are interested and of course, show that the product works!
Any help in this regard will be really appreciated!
If you want to manage docker containers with least hassle in AWS, you can use Amazon ECS service to deploy your containers or else go with Beanstalk. Also you don't need to use Swarm in AWS, ECS will work for you.
Its always better to scale out rather scale up, using small to medium size EC2 instances. However the challenge you will face here is managing and scaling underlying EC2's as well as your docker containers. This leads you to use Large EC2 instances to keep EC2 scaling aside and focus on docker scaling(Which will add additional costs for you)
Another alternative you can use for the Web Application part is to use, AWS Lambda and API Gateway stack with Serverless Framework, which needs least operational overhead and comes with DevOps tools.
You may keep your web app on Heroku and run your IoT server in AWS EC2 or AWS Lambda. Heroku is on AWS itself, so this split setup will not affect performance. You may heal that inconvenience of "sitting on two chairs" by writing a Terraform script which provisions both EC2 instance and Heroku app and ties them together.
Alternatively, you can use Dockhero add-on to run your IoT server in a Docker container alongside your Heroku app.
ps: I'm a Dockhero maintainer
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 months ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Not suitable for this site
Improve this question
I have developed a .NET MVC application and have started playing around with AWS and deploying it via the Visual Studio Toolkit. I have successfully deployed the application using the Elastic Beanstalk option in the toolkit.
As I was going over the tutorials for deploying .NET apps to AWS with the toolkit, I noticed there are tutorials for deploying with both Elastic Beanstalk and CloudFormation. What is the difference between these two?
From what I can tell, it seems like they both essentially are doing the same thing - making it easier to deploy your application to the AWS cloud (setting up EC2 instances, load balancer, auto-scaling, etc). I have tried reading up on them both, but I can't seem to get anything other than a bunch of buzz-words that sound like the same thing to me. I even found an FAQ on the AWS website that is supposed to answer this exact question, yet I don't really understand.
Should I be using one or the other? Both?
They're actually pretty different. Elastic Beanstalk is intended to make developers' lives easier. CloudFormation is intended to make systems engineers' lives easier.
Elastic Beanstalk is a PaaS-like layer on top of AWS's IaaS services which abstracts away the underlying EC2 instances, Elastic Load Balancers, auto-scaling groups, etc. This makes it a lot easier for developers, who don't want to be dealing with all the systems stuff, to get their application quickly deployed on AWS. It's very similar to other PaaS products such as Heroku, EngineYard, Google App Engine, etc. With Elastic Beanstalk, you don't need to understand how any of the underlying magic works.
CloudFormation, on the other hand, doesn't automatically do anything. It's simply a way to define all the resources needed for deployment in a huge JSON/YAML file. So a CloudFormation template might actually create two Elastic Beanstalk environments (production and staging), a couple of ElasticCache clusters, a DynamoDB table, and then the proper DNS in Route53. I then upload this template to AWS, walk away, and 45 minutes later everything is ready and waiting. Since it's just a plain-text JSON/YAML file, I can stick it in my source control which provides a great way to version my application deployments. It also ensures that I have a repeatable, "known good" configuration that I can quickly deploy in a different region.
For getting started quickly deploying a standard .NET web-application, Elastic Beanstalk is the right service for you.
AWS CloudFormation: "Template-Driven Provisioning"
AWS CloudFormation gives developers and systems administrators an easy way to create and manage a collection of related AWS resources, provisioning and updating them in an orderly and predictable fashion.
CloudFormation (CFn) is a lightweight, low-level abstraction over existing AWS APIs. Using a static JSON/YAML template document, you declare a set of Resources (such as an EC2 instance or an S3 bucket) that correspond to CRUD operations on the AWS APIs.
When you create a CloudFormation stack, CloudFormation calls the corresponding APIs to create the associated Resources, and when you delete a stack, CloudFormation calls the corresponding APIs to delete them. Most (but not all) AWS APIs are supported.
AWS Elastic Beanstalk: "Web Apps Made Easy"
AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS.
You can simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring.
Elastic Beanstalk (EB) is a higher-level, managed 'platform as a service' (PaaS) for hosting web applications, similar in scope to Heroku. Rather than deal with low-level AWS resources directly, EB provides a fully-managed platform where you create an application environment using a web interface, select which platform your application uses, create and upload a source bundle, and EB handles the rest.
Using EB, you get all sorts of built-in features for monitoring your application environment and deploying new versions of your application.
Under the hood, EB uses CloudFormation to create and manage the application's various AWS resources. You can customize and extend the default EB environment by adding CloudFormation Resources to an EB configuration file deployed with your application.
Conclusion
If your application is a standard web-tier application using one of Elastic Beanstalk's supported platforms, and you want easy-to-manage, highly-scalable hosting for your application, use Elastic Beanstalk.
If you:
Want to manage all of your application's AWS resources directly;
Want to manage or heavily customize your instance-provisioning or deployment process;
Need to use an application platform not supported by Elastic Beanstalk; or
Just don't want/need any of the higher-level Elastic Beanstalk features
then use CloudFormation directly and avoid the added configuration layer of Elastic Beanstalk.
Cloud Formation is a service that lets you deploy AWS services. You create a template file that describes which services you want. When you deploy that template, Cloud Formation creates the resources for you as a "package". All the resources you defined in your template are started and terminated together. Examples of types of resources that can be created with Cloud Formation are: S3, EC2 instances, AutoScaling, DynamoDb, etc. For EC2, Cloud Formation also gives you the ability to make use of "cfn-init" scripts; which can be used in conjunction with the template to boot strap your instances.
Elastic Beanstalk uses Cloud Formation templates and scipts to: 1. Create a Load Balancer and Auto Scaling Group, 2. Copy your code to S3, 3. Bootstrap an Ec2 instance to Download the code from S3 and deploy it.
Cloud Formation is not as easy to use as EB, but it is much more powerful, because you can create resources other than EC2 instances, control how the cfn-init script, and etc.
There are other differences worth noting. Elastic beanstalk is designed as a container for a single app. I've a set of several websites and services but found it very difficult to deploy multiple websites with beanstalk and was advised, after several attempts, by AWS help to use cloud formation in this situation as it has the extra flexibility.
Theres a really helpful article on bootstrapping AWS cloud formation and updating a running site here thats much clearer than the AWS pages. Still trying to work out if we can deploy from VS straight to the cloud formation template stored on S3 and get it to auto update like beanstalk...
These services are designed to complement each other. AWS Elastic Beanstalk provides an environment to easily deploy and run applications in the cloud. It is integrated with developer tools and provides a one-stop experience for you to manage the lifecycle of your applications. AWS CloudFormation is a convenient provisioning mechanism for a broad range of AWS and third party resources. It supports the infrastructure needs of many different types of applications such as existing enterprise applications, legacy applications, applications built using a variety of AWS resources and container-based solutions (including those built using AWS Elastic Beanstalk).
AWS CloudFormation supports Elastic Beanstalk application environments as one of the AWS resource types. This allows you, for example, to create and manage an AWS Elastic Beanstalk–hosted application along with an RDS database to store the application data. In addition to RDS instances, any other supported AWS resource can be added to the group as well.
Both are for provisioning infrastructure; but they differ in their approach.
Beanstalk: The starting point is the code. I have a NodeJs code I want to upload & run it; please provision the infrastructure for me. (PaaS) Platform as a Service
CloudFormation: The starting point is the infrastructure. Please create an EC2 instance, with one LoadBalancer, Security Group etc so that I can uploaded my NodeJs code to it. Infrastructure as Code (IaC).
Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring based on the code you upload to it, where as CloudFormation is an automated provisioning engine designed to deploy entire cloud environments via a JSON script.
Beanstalk: Gives the developer the ability to manage only code and not systems
Cloud Formation: Simplifies and makes everything easier for a Systems Engineer
If a developer or the dev team is looking for a quick MVP testing, the best option is to quickly get deployed with Beanstalk and check.
When a AWS migration happens, systems engineer will get involved in provisioning and Cloud Formation will help a lot and give much more granular control.
Beanstack internally uses cloudformation.
Beanstalk - Basically helpful for software developers.
Example : You want to start the PC quickly and run an application. You don't buy the PC items (harddisk, ram, Processor) separately. You buy a whole CPU or a laptop of a required config. You dont care how its running inside as you want your application to run for you. Beanstalk gives you this feature of everything ready made with no worries.
Cloudformation - Basically helpful for system engineer/ Hardware.
Example : You want to assemble 100's of PC's and give it to the developers then instead of assembling so many PC's you can just give a list of items and the PC is assembled for you by the retailer.
Similarly create a template and send it to cloudformation it will finish your work with no effort.