Elastic beanstalk is a service of Amazon Web Services that allows you to deploy an API or website from the command line and it automatically creates the resources to run it. It allows you to have multiple environments: dev, stage, prod and even create an environment just to test a feature (just by changing a line of code) and then terminate it easily.
Behind the scenes Elastic Beanstalk creates an EC2 instance to run your code (an others AWS resources)
You can set up Elastic and the environment with a simple setting page in AWS where you can configure the type of instance that it will create, the software to run (Node.js, Java, Python and others), the load balancer, security and many others.
Another cool thing about Elastic is that you can set the environment to be Auto Scalable. If your site is under high traffic it automatically creates new instances to handle it.
In the settings page you can set based on CPU usage, Memory, Latency, Disk I/O, Network and other Metric, the creation of new instances of your server. You can set a minimum and a maximum instances created.
If the traffic or server usage goes down it will destroy the instances created so you save money.
This work is done by a Load Balancer created automatically for you.
In my experience I found it a little difficult to know what metric to use and what value to set. I had to set a metric and then test how it responded in high traffic. But it is really difficult to see if everything goes well. You have to check logs and statistics under high pressure and adjust the values entered. You have multiple variations that can change everything.
One cool feature is when you deploy, it launches a new server instance so your site never goes offline. If it fails nothing will happen. You’ll still have your “old” instance running.
Pros:
-
You can add a load balancer and make AWS create multiple instances when the traffic to your site or the amount of API calls is high.
-
You can deploy and the site will not go offline. AWS will create new instances with the new code and have others instances with the old code running while the new ones are created and ready to receive traffic.
-
You can easily deploy from the command line (locally) or with Jenkins server. That will deploy code and create the instances (like a pipelines).
-
You can have multiple environments (in differents domains or subdomains) so you can have a stage test site.. or you can even test different versions of your site.
Cons:
- At first if something fails, you have the temptation to connect to your “instance” and check the logs or see the current memory usage.
You have to remember that if you are using a load balancer Elastic will create multiple instances or in a single instance setup that instance will be created and destroyed in every deployment. The best way is to check inside Elastic the indicators of what is going on: the logs, metrics, health, etc.
-
You can use the local instance memory to save some cache or some values that you need to store, but remember: that memory is erased when you deploy a new code an new instances are created or in a multi instance site, some request can go to one instance and others request to the other (You might need to use some caching system like Amazon MemoryDB for Redis, Memcached or your database to store values).
-
You have to configure 1 instance with Autoscaling. Even if you have a small site
Below some pics from my environments
Autoscaling configuration
1-4 instances
Single Instance without AutoScaling
Example versioning
