Datasquiz specializes in CRM and Marketing Automation, Big Data Analytics, and Web Hosting. We have been running a physical hosting infrastructure for several years, and migrated to Amazon Web Services for our PHP hosting. After a few weeks of fun, i wanted to share with you all our experience, and hopefully help in the decision making when it comes to considering a scalable cloud hosting platform.
First of all, Amazon AWS isn’t easy. Sure, you can easily create an account, and spin a few EC2 instances here and there, maybe even start a few other services that works together, but doing it right is a lot more complex. A lot of companies claim expertise on AWS, but we see a lot of basic best practices being ignored, which in the long run means higher running costs, security issues and scalability issues.
Amazon has basically stripped down the complete hosting stack to components, which now becomes customizable and measurable. Disk I/O for example, which on smaller instances gets limited, or CPU capabilities which again, is limited and works with a system of credit (accumulate CPU credit when idle, exhaust CPU resources when used which mean you have no other choice but to add another instance). Of course, you could also go with a more powerful instance, but i’m trying to illustrate that becoming aware of the system limitations is important to build a scalable application.
Amazon also has a system of permissions that is very interesting. Each application can run under an “IAM” account, which can be restricted to the most granular level of permission you can find to the most “administrator” level access there is. IAM users can inherit permissions from a “role”, which can also be attributed to services, while groups can link a bunch of IAM users together, and also attribute permissions inherited via the group. Permissions are defined via “policies” which are stored in JSON format, and can be attributed to users, groups, roles, or applications themselves like an S3 bucket.
When running a web application on Amazon, you have to consider the micro-services Amazon offers, and how you can leverage them to reduce your costs and increase redundancy. One example i used earlier is the CPU credit your small instance may have. A properly well tuned small instance will save you money for your web server for example, but what happens when you do a nightly backup of your server ? you will run fast through your CPU credit, slow down your entire web application and require to scale up which will increase your costs ! Instead, you may want to look at a complete different solution, like imaging your volumes, or storing content on a S3 Bucket (cheap static storage), and backup from there to an Amazon Glacier to reduce your storage costs..What this means is that you can no longer think “classic” hosting, you have to think “scalability” and spread out your web components.
This is a simple example, but there are many more : typically, for a PHP application, you should be able to strip your application to AWS services :
This is a small example of architecture considerations, but i hope this helps understanding that it’s not just a “take this, put it on EC2” mentality, because even if you could take that approach, you will not save costs and increase reliability that way.
Amazon runs in 14 regions of the globe, and provide 38 availability zones (different segments within a region). You can therefore really scale an plan a proper disaster recovery policy across different zones of the planet. However, i found some services are not always available right away in all regions. One example would be Amazon EFS (an elastic file system) which is not available yet in Asia-Pacific. This means that when you architect a web application, and look at the available services to accomplish your architecture, you need to make sure the service runs in your region.
There are also “global” services like CloudFront for example which are offered in regions, but can only be accessed via some applications by switching regions. The example i have is using CloudWatch (amazon logs monitoring), which does not provide you the CloudFront metrics unless you switch regions. This is no big deal if you are only looking at logs once in a while, but can be annoying if you rely on these metrics with alarms and programmatic actions.
AWS offers a CLI interface that’s quite powerful, and that really makes cloud hosting a massive advantage compares to a classic infrastructure. The AWS console (where you administrate your environment) is basically a big java script console which underneath triggers CLI actions… Once you configure your profile via an access key and secret, you are then able to stop services, start new instances, decrease or increase size, and configure pretty much any Amazon service to your liking directly from your environment.
That’s where the strength of the AWS cloud lies : your environment can then scale based on events happening real time on your application, and you like you can code a function to accomplish a certain task based on inputs, you can program your Amazon cluster of services to “adapt” to a situation. This is a fundamental change which, once well understood, becomes a real asset. Of course, this also raises security concerns as it introduces a potential backdoor to your infrastructure, allowing malicious code to start new services, and you end up with a huge bill ! That’s why best practices needs to be followed, with a dedicated role or IAM user allowed only certain levels of access via well-defined policies, timely rotation of access keys, and proper monitoring and alarms in place.
I hope this gives you a better picture of what the cloud means to your applications. It is certainly not a magical solution that reduces your bill instantly, and to be properly implemented it requires planning and most of the time architecture reviews. But once it is in place, it takes care of itself ! Amazon is also coming with new services every year, which basically means more elasticity in your implementation.
Again, a common mistake is to take a physical infrastructure, and replicate it on Amazon : although it may be temporary, you definitely want to leverage those services offered to reduce complexity, increase security and ultimately benefit from a service managed and updated for you by Amazon. I have covered only a few examples of what AWS can do for you. I hope this helped, and if you have any question feel free to reach out to us !
wordpress theme by initheme.com