I am considering the pros and cons of moving an app from Sashido to something self-hosted at i.e. Heroku or some other hosting platform. Would love to hear what the community see as pros and cons with moving vs staying with Sashido.
Thanks!
Claes
1 Like
For me biggest pro is everything is under my control. But this also leads a con which is i have to manage everything. Self hosting is also cheaper in long run. Also sashido doesn’t support latest parse servers. İ guess latest version they support is 3.6.0 which is older. You can’t take advantage of latest parse server features like file triggers which introduced in version 4.2.0
Self Hosted
Pros:
- Everything is under your control.
- Cheaper in long run especially if your app will serve many people.
Cons: - You have to manage everything.
Yes you have to manage everything but when I do stress test against my servers, parse server doesn’t crash except if there isn’t enough ram. When available ram is zero, parse will crash. But this also depends on your usage. Parse generally uses little ram. Ram only got full if you are fetching over 100.000 parse object. And even for 100k objects 1.5gb ram will be more than enough. For few hundred objects ram will not be an issue.
1 Like
Thanks a lot for your input! Much appreciated 
That is a great question and it means embarking on an exciting journey full of new discoveries.
This autodidact crash course will teach you to look at your app from many new angles. You will take new considerations into account that will help you build a more efficient, secure and resilient app. You will learn a lot about topics you may have never heard of or which you only knew by name.
Generally, you will likely encounter challenges of the following categories when moving from a hosted provider to self-hosting (provider agnostic):
Concept
- Some of your current approaches may become unfeasible or inefficient. You may need additional services that come included with a hosted provider. For example, you may need to look for a CDN provider to cost-effectively serve content to clients, something your hosted provider may have done for you in the background.
Migration
- If you want to migrate a live app, you will benefit from a migration plan that allows you to plan transitioning the database data, any storage content, APIs, DNS entries, client connection URL, etc. It is usually beneficial to test this out with a sample environment and plan safe points you can return to if you need to abort the migration.
Costs
- The maybe most often encountered surprise: Make sure you fully understand the new cost structure when self-hosting. You may suddenly be billed separately for things like log storage, DNS queries, and load balancer traffic. It is nothing that you didn’t already pay before in an all-inclusive pricing model, but suddenly a minor configuration change can mean a significant change in cost. To manage that, you are provided with a detailed billing dashboard that allows you to break down costs on a per-component basis.
- Support packages may suddenly become a separate cost point. While hosted providers often include basic support as part of your flat-rate, this is usually not the case with cloud service providers.
Scaling
- While a hosted solution gives you just a handful of scaling sliders, you suddenly have to consider scaling separately for every component in your entire architecture. That means you will develop a more differentiated understanding of scaling as you go along. This will allow you to optimize and provision your components exactly as you need them and give you additional cost saving opportunities.
Security
- You will have to secure the architecture components yourself. Especially if you consider migrating an existing live app, that is something to pay attention to from the start, otherwise you may create vulnerabilities that you may not notice until it’s too late.
- Security means not just protecting against data theft or service interruption, but also protecting your environment from unexpected costs. For example, a DDoS attack will suddenly not just mean that your service is impacted, but your bill can go up into the thousands. This risk is usually carried by the hosted provider, but cloud service provider usually explicitly shift the risk to you. You are billed for your resources, regardless of who or what is using them. Some cloud service providers even offer some sort of insurance package against these risks, but you could also look for external insurance cover.
Time
- You will need to invest time to learn as you go. You will go from mainly worrying about your business logic to worrying about many new aspects and topics that you may not have encountered previously.
If this sounds like a lot, it should not discourage you. Quite the contrary, the time and effort you invest will be worthwhile through the knowledge and competence you acquire. You will never look at an app the same way as before.
2 Likes
Hi, I am evaluating a self-hosted option over the back4app due to 2 reasons:
- I want to integrate ElasticSearch
- Back4app does not give the control over the versions of MongoDB and Parse Server
Do you think we could use my very limited knowledge as an advantage and write a detailed guide on how to deploy a simple, but easily scalable self-hosted solution? I could imagine that I would go through that painful learning process under your advices and supervision and I would write down a guide with that would track all my steps? I believe that it could help someone in future as it has to also explain it in detail (because I have never worked with any backend and can do programming only in swift).
I understand that every app has different needs and also depending on how the scale of the app changes and maybe I simplify it too much, but I think there must be a starting point that suits the most applications that can grow like:
- Put this and that into Kubernetes on such and such machine…
- These are the steps to set Kubernetes for one microservice of MongoDB that might be scaled later…
- These are the steps to set other microsercices like Parse Server, ElasticSearch…
- Set these and these parameters to make it a bit secure…
… not really trying to over-optimise everything, just keep thing flexible and then I could also document the costs of each feature/part…
I am sure this would be a lot of work and I would also need a lot of assistance, but it might be worth of doing for me to understand and learn and also could be great help for some independent developers that are trying to bring app a new idea and don’t want to build up technology debt due to limited knowledge.
What do you thing?
I’m not sure you’ll find a free 1-on-1 tutor for your project here, but you could just document your learning process and post any issues you encounter in the respective forums (Parse Community Forum, StackOverflow, ServerFault, etc) as you go along and then share the document with the Parse Community.
There are a lot of Parse Server deployment and performance optimization guides out there, so you may want to start with a search, for example: https://community.parseplatform.org/t/share-your-performance-tips