Why you can’t use Heroku free dynos in multiple servers dependent application
Week 12 GSoC 2020 Final Coding Phase with AnitaB.Org
Final week at last!!! I’m both excited and sad. Excited because I’ll soon get more time to myself and freedom to do things I have set my mind to. This include spring cleaning (even though spring is still a while from now, but hey… the house is a mess coz I can’t really do too much on the usual chores during GSoC… 🤣). Soon I also can spend more time with the family. Why am I sad with GSoC is ending? Of course, because I’ve got used to the routine in GSoC and loving the interactions with my team of mentors. So, sad that soon it won’t be the same… But, hey… I’ll definitely hang around 🤞 and hope to continue making contribution to BridgeInTech project in particular, as well as the other AnitaB projects while being active in its open source community 🥰
So, here’s my final blog. Well, for GSoC only that is, coz I’m planning to continue writing blogs every now and then just as another hobby 😎. Remember my blog last week with the title`Challenge in keeping Authentication cookie on a remote server`? Today I’m gonna give you the breaking news on why my attempt to deploy BridgeInTech application to Heroku as remote servers had terribly gone wrong.
Disclaimer
First of all, I have to state that this blog is in no way intending to make Heroku look bad. Not at all. Heroku to me is such a great tool that has become one of the important learning steps for a new developer like me to learn about Platform As A Service (PAAS), application deployment, remote servers, and much more. I am grateful that it has sooo many perks that makes developers life easier. So, no..no..no. This blog is not about making a bad name for Heroku. I just want to share with you why choosing Heroku to host BridgeInTech multiple servers on free dynos is not a viable solution. That’s all.
Ok, now that we have that out of the way, let’s talk about the findings.
Performance issues
**What is the situation?**
* BridgeInTech is an application that uses 2 REST APIs (BIT API and MS API) with only one API facing the user (on BIT frontend) which is the BIT REST API. Both APIs is connected to the same postgreSQL through through two separate schemas, one specific to BIT and the other specific to MS.
**Why is this a problem?**
This situation resulted in an extensive use of resources on both processing/computing and network bandwith. It also affects the processing time with the continuous internal requests redirected to MS API. On a local environment where only one user have access to the application, performance is not an issue, but when the system is used in a remote environment and accessible to multiple users, the number of users and requests affects the system performance negatively. The remote server BridgeInTech currently using are the Heroku free dynos, which have limited power and capacity that adds to performance deterioration further. The challenges of using Heroku free servers can be seen from the following information:
* Limited power
Below is the snapshot of Heroku dynos performance characteristic
NOTE: Notice that free dyno is not a dedicated server. This could mean all three servers BIT uses (BIT backend, MS backend and BIT frontend) which are all on free dynos will share this already limited capacities.
* Limited Process/threads limits
NOTE: Put in mind that free dyno being not a dedicated server could mean this limited process/threads are also shared between the three BIT servers above.
* Dyno sleeping
Free dyno will sleep every 30 minutes when no traffic is received. This could be challenging when a user who’s in the proces of filling in a form, steps away from their computer for a while (assuming longer than 30 minutes and no other user using the server at the same time) then comes back to continue to work with the form, only to find out that they already got kicked out from the server and need to re-login (any filled information could get lost in the process). Although, this is a very unlikely event (can’t imagine how a server with multiple users can be idle for longer than 30 minutes, especially when the application has a global-based user).
* Limitation on Hobby tier
BIT Heroku postgreSQL is using the Heroku hobby-dev tier. Heroku explains the limitation that comes with this type of tier here:
The most standout point to me on the above is the maximum storage size of 1GB that BIT can use on its current hobby-dev tier. Well,…. with multiple users on remote servers, hmmmm 🤔🤔…
Ok, here comes the “BIG BANG”. Remember that in the previous blog I was focusing and highly suspected the Authentication Cookie being the culprit of why the response on authentication token is soooo random when testing BridgeInTech application on the Heroku servers?
Guess what!! Even if BIT has a perfect well prepared Authentication mechanism put in place in its code, testing BIT application on Heroku remote servers will guarantee end up in a failure.
Here’s why…..
**MAIN ISSUE WITH HEROKU**
Problems that come with this limitation:
* Point 1: Apps running on free or hobby dynos can have only one dyno running per process type.
**Impact on BIT**: BIT and MS backend servers are both using the same process type (`web: gunicorn`), but due to Heroku free dynos limitation above, only one of them can run at a time. This means system integration between BIT and MS backend servers is impossible to achieve.
* Point 2: Apps running on free dynos are limited to a maximum of two concurrently running dynos.
**Impact on BIT**: All BridgeInTech three apps are running on free dyno, but due to Heroku free dynos limitation above, only two can run concurrently. This means BridgeInTech system integration between all of its 3 servers is never going to happen.
💥💥💥
**Conclusion: Running multiple servers like BIT backend, MS backend and BIT frontend on Heroku free dynos is not possible.**
**Potential solution: upgrade the Dyno (comes with a cost) or use AnitaB AWS server**
Alright, That’s it for my final coding phase in GSoC. Perhaps I’ll make a “closure blog” for this GSoC after my final presentation that is due end of this week. so, stay in touch 😉
