![]() ![]() Cron jobs: we didn’t delete the Heroku cron jobs even though we turned off the dyno and put the app on maintenance.It wasn’t completely explicit but thankfully we it soon enough. We created this production app in a DO project who was meant to be for staging, thus the NODE_ENV environment variable “Staging” was passed and we didn’t get analytics and sentry errors for a full day.The DNS transfer took about 15 minutes, some of the requests were progressively going to DO until 100% was on them. Our production app was ready and we just had to change our DNS to point from our Heroku to Digital Ocean. We decided to migrate on a Saturday, this would leave us enough time to check everything and fix any incoming bugs throughout the weekend if anything arises. Migrating our production server on the weekendĪxolo is a tool teams use mostly on weekdays. This seemed to work fine and I decided it was time to migrate our production environment. ![]() Migrating Starting our migration with our staging environmentīefore migrating fully we migrated our Staging environment and tested all of our core services. Building our droplet with a Linux server to send out cron jobs or look for a service that provides this service. Unlike Heroku Cron jobs are not natively handled in DO, and I havn’t seen any DO addons doing the job. As for the Redis Database, I’ve decided to create a new one on DO, which was also straightforward. I’ve personally linked our GitHub repository and added all of our environment variables. I wanted to build and migrate my apps on something as easy and straightforward as Heroku so I chose to build what DO (digital ocean) calls apps, with a fully managed infrastructure, see Digital Ocean App platform.Ĭreating an app on DO was as easy as building on top of Heroku. Droplet for example allows you to create a virtual machine in a few steps. Building on Digital oceanĭigital Ocean has a whole list of what you can build on top of their cloud providers. So pricing and scaling our server was the main reason we looked out for migration of our cloud provider. So that means that the next time we want to scale vertically our Heroku cost will raise from $210 to $560 (considering we have 2 dynos at $250 + 1 Redis addon at $120). This isn’t much but as we are growing I know we will have to switch our Heroku server to a Performance-M Dyno with 2.5GB Ram. Without a database, this comes down to $210 per month. Heroku-Redis addon(250Mb memory, 200 connection limit) Here is a summary of our expenses on Heroku just for that one server: Our costs on Heroku before the migration Itemsģx Standard-2x dynos (1 Gb ram) at $50 each We’ve been running out of Heroku credits for 6+ months and we can see the servers' cost increasing every month as the traffic grows. Upgrading servers and dyno on Heroku become pricey. Every once in a while a new big client comes in and we need to upgrade our server and optimize our code. We’ve been scaling our servers on Heroku, both vertically (upgrading our server ram) and Horizontally (adding dynos). As of today, those webhooks represent around 30k HTTP requests per day on our server. We subscribe to webhooks from GitHub, GitLab, and Slack.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |