Now this architecture should be fine for the initial go live, when the customer base isn't large, but we intend to syphon more and more of our customers from our existing Magento e-commerce site to this new solution, and I have some concerns about scalability. Eventually there would be a lot of traffic/visitors/network throughput/db queries running through the solution, so has anyone got experience on building out a 'beefier' AWS architecture for Umbraco?
E.g. having databases for read and write separately, instance sizing, caching (what type and where to use it) or any other performance/architecture tips as I don't think the pattern shown in the AWS article will support a huge amount of traffic (particularly with only a single database instance for 'everything').
AWS is definitely scalable and the diagram shows how a simple Umbraco site could be scaled.
Though scalability design is a mixture of how you design your application and the infrastructure behind it.
A good example of a scalable complex umbraco solution could be a popular ecommerce site with a forum. The infrastructure behind it would be an elastic load balancer, which routes a specific domain to a master ec2 instance that is used by admins to manage content and products in the CMS. Then a bunch of slaves. The master and slaves sit in different target groups. ELB use target groups to determine where to route traffic to based on domain. The database(s) can be hosted on RDS, which can be scaled vertically and horizontally. RDS scales horizontally by using replication sets, which generally accepts write commands to a single RDS instance and then replicates it across to all replication. The read commands get routed to all replication sets. This is all configuration.
If your concerned about that not being enough, you can split your databases across multiple RDS instances.
However you can also get EC2 instances that come with SQL server preinstalled and you can do it yourself. Rds is just a AWS's solution.
In terms of caching, you can use cloud front or cloud flare for pages that can be cached. There is AWS elastic which hosts elastic search whereby you can index content into that can be a quick way to search for content or any sort of data without going to the database or running complex searches on the EC2 instance. And as well as that, you can also load balance AWS Elastic behind the ELB.
In terms of ELB type, application type is very good. You can then set up automated SSL setup and renewal which is provided at no extra cost.
I use both Azure and AWS but I have found AWS to be the most flexible. But it's a more steeper learning curve.
Scalability of Umbraco on AWS
Hi all. My organization is looking to prototype a click & collect / deliver site using Umbraco 7. It will likely be hosted in AWS using the standard pattern (or a variation of) shown here - https://aws.amazon.com/blogs/devops/run-umbraco-cms-with-flexible-load-balancing-on-aws/
Now this architecture should be fine for the initial go live, when the customer base isn't large, but we intend to syphon more and more of our customers from our existing Magento e-commerce site to this new solution, and I have some concerns about scalability. Eventually there would be a lot of traffic/visitors/network throughput/db queries running through the solution, so has anyone got experience on building out a 'beefier' AWS architecture for Umbraco?
E.g. having databases for read and write separately, instance sizing, caching (what type and where to use it) or any other performance/architecture tips as I don't think the pattern shown in the AWS article will support a huge amount of traffic (particularly with only a single database instance for 'everything').
Keen to hear peoples thoughts! :)
AWS is definitely scalable and the diagram shows how a simple Umbraco site could be scaled.
Though scalability design is a mixture of how you design your application and the infrastructure behind it.
A good example of a scalable complex umbraco solution could be a popular ecommerce site with a forum. The infrastructure behind it would be an elastic load balancer, which routes a specific domain to a master ec2 instance that is used by admins to manage content and products in the CMS. Then a bunch of slaves. The master and slaves sit in different target groups. ELB use target groups to determine where to route traffic to based on domain. The database(s) can be hosted on RDS, which can be scaled vertically and horizontally. RDS scales horizontally by using replication sets, which generally accepts write commands to a single RDS instance and then replicates it across to all replication. The read commands get routed to all replication sets. This is all configuration.
If your concerned about that not being enough, you can split your databases across multiple RDS instances.
However you can also get EC2 instances that come with SQL server preinstalled and you can do it yourself. Rds is just a AWS's solution.
In terms of caching, you can use cloud front or cloud flare for pages that can be cached. There is AWS elastic which hosts elastic search whereby you can index content into that can be a quick way to search for content or any sort of data without going to the database or running complex searches on the EC2 instance. And as well as that, you can also load balance AWS Elastic behind the ELB.
In terms of ELB type, application type is very good. You can then set up automated SSL setup and renewal which is provided at no extra cost.
I use both Azure and AWS but I have found AWS to be the most flexible. But it's a more steeper learning curve.
is working on a reply...