I'm working on a project based on Microservice architecture in Laravel, which means I'll have many small apps and Databases, I'm confused weather I should buy AWS EC2 or Digital Ocean's hosting. My concern is pricing, In numbers I'm having a 100% price difference and getting Digital Ocean's hosting in 50% of the price with more features then what I'm getting on AWS.
Please suggest me what would be the better option.
We faced exactly the same choices for our live service that deploys a laravel API and multiple react apps.
There is no generic correct answer to a question "what tool/provider is better?" as it depends on your circumstances. Cost is a particularly tricky question. Are we just talking about the cost of getting something live, or the cost of running an elastically scalable service, or the cost of running a highly available elastic service that spans data centre availability zones such that it isn't taken down by an outage in a single data centre zone?
Digital Ocean ("DO") is very highly promoted in the Laravel community so it was "the default" for the development team when I joined a startup about two months from go-live. When I asked "what about data centre availability zones" the answer at the time for Digital Ocean was that they didn't support it and we would have to set-up in two different DO data centres and work on our own mechanism (e.g. DNS) to switch between them if DO had a major outage in one place. Yet on AWS they have availability zones and also Elastic Load Balancer so its far easier to get a setup going that is "future ready" if you intend to be running a very successful large scale service a year after launch.
In the end we went live on openshift.com which is a shared kubernetes service running on AWS. So our live DNS points at the Elastic Load Balancer of a shared Kubernetes cluster were we rent space for our containers. The cluster we are on has containers by other companies and runs across many AWS EC2 virtual machines. Yet they are not dedicated to us so we only pay a small fraction of the costs. Yet if any one virtual machines crashes where our containers are running openshift kubernetes automatically starts a replacement container on another virtual machine. So we have automated high availability and crash recovery but only pay-as-we-go for the memory and CPU we currently use. We can scale up more containers anytime we want by using changing the replica count. Openshift has internal load balancing so that a single internal service IP with an internal DNS name automatically points at however many containers we want to run of a particular type. That solves discovery between our services. If you deploy a redis instance from the built-in catalog it is instantly available on a private IP with a DNS entry only viable in your project. That sort of ”discovery” feature is really important when you are running microservices at scale.
With our setup, we get a great low-cost price for a very professional, elastic, highly scalable, fully automated infrastructure-as-code setup, that has all the advantages of AWS ELB, and all the advanced features of kubernetes for microservices.
Edit: I wrote a tutorial for my experiences running laravel backend with a reactjs frontend on openshif.com that is over at https://gist.github.com/simbo1905/d27ba7218a2fd71fcb4f0fcede82fd6d
There are a couple of additional considerations to take into account when you compare your service between AWS and Digital Ocean.
If you know your service needs to be hosted on instances and you can estimate your performance needs well then you can buy reserved instances which give you between 30 and 50% off the listed price.
If you are in the early stages of a project you should also be able to run your service for free for 12 months. After that you should be able to estimate what reserved instances to use.
Keep in mind that various AWS services can significantly reduce your service costs while costing barely anything themselves such as API gateway caching, Cloudfront and Lambda@Edge.
Also AWS autoscaling features should allow you to use peaks and troughs in traffic to optimise your costs. You do need some basic scale for that though.
But more importantly Lambda should be your service of choice for microservices. It has a billing granularity of 100ms and 128Mb memory and a permanent free tier for a certain amount of "grains". It therefore can work like auto scaling, but with a startup and shutdown time of 100ms eliminating all costs where your service is actually not used.
This is kind of a subjective question but I will try to answer it as objectively as I can. Naturally you can list the advantages and disadvantages of the possible choices. Both choices offer about the same availability if I understand correctly. AWS is never cheapest in the price comparisons that I read. So that gives DigitalOcean an advantage.
For reasons from my management, I use AWS all the time but if I would start a project today then I would go for DigitalOcean because I also have seen price comparisons where AWS is never cheapest. Competition is good for everybody and therefore it is good to buy from competitors so that AWS feels a competition.
If features and pricing is your main concern and if DigitalOcean can do it, then you have convincing arguments to use DigitalOcean.
If complete automation with something like Cloudformation is your goal and if you already know AWS very well, then you might want to go with AWS instead because you already know it.
I would suggest to use AWS as this platform is far more mature than DO. You start with one app, but I assume more apps will be deployed. If you deploy and investigate everything yourself it costs also a lot of money. Imagine that you want to deploy a HA postgres cluster in DO, good luck with that. In AWS it is just a matter of a couple of clicks.
If your main concern is pricing, try Linode - an AWS alternative. Linode is a cloud service provider recently purchased by Akamai.
It has great support, docs and you can create Kubernetes cluster there very fast comparing to other cloud providers, where you can deploy your Laravel app.
Disclaimer, I wrote the linked article.
