Taking inventory of Heroku for an AWS migration
• Mark Eschbach
Heroku has served us well however there are secruity requirements which they can’t meet at an actionable price. Time to see what knowledge I glean about the sizes of the instances we should use.
Reading notes on the DoorDash migration
DoorDash published their approach to migration, written in Apirl 2015. From the performance aspect it’s been memory and not execution power which I’ve mainly seen as a drawback. Raw cost efficiency I can understand their argument however once you move up to IaaS you now have to pay someone to maintain and monitor that platform. Definitely could make the system more reliable for the same hosting costing though, providing redundancy. I think I’ve only encountered a single issue with our deployments to heroku; I have a much large issue with maintaining fastlane pushing to Apple. Only reason control is an issue in my opinion is the lack of building a fully secure system out of the box. I’m not saying their system is insecure but in an age of VPCs and VPNs they could at least setup soft networks between the nodes for you. All gripes aside, Heroku is a great get off the ground platform and has served us well. Our primary motivation for migration is related to security work though.
They complained they want the power of infrastructure then complain about needing infrastructure. Typical argument for Docker of it’s a snapshot of the system state. Awesome feature of Docker. However unless one is using the AWS’s container service you are still on the hook for managing the underlying system. Worse off by leaving Heroku you must now manage the secruity of the nodes.
Overall I’m glad their migration worked out however I was really hoping for additional details there. I think the key take away fro me is the Heroku 2x
dyno level is equal to c3.large
when the author wrote the article.
AWS architecture notes
I found a reason for using a reverse proxy at the edge tier besides security: to route reporting requests transparently to the application developer. Node problem domains place interesting requirements on the instances. The edge reverse proxy and application nodes are IO+CPU load heavy with CPU being dependent upon IO operations. The proxy node is probably the most IO heavy since in theory most of the requests entering should be shunted to an ELB. In application nodes CPU is higher priority to get data crunched and out. The database tier will need a decent amount of CPU but it’s fully IO heavy with a lower emphesis on the CPU.