Running Parse Server with MongoDB on Digital Ocean - ios

I am one of the developers that have been using Parse as a backend for an iOS app and am now in trouble, because of Facebook shutting the service down. After investigating possible solutions and migrating options, I have decided to go for Digital Ocean to run the open source Parse Server and host my MongoDB there.
As the solution is getting more popular, with amazing guide-throughs popping up every day (like the one by Julien Renaux), I wanted to ask whether there are any known shortcommings or issues you have encountered after implementing such a solution or along the way?
Thank you

Related

Heroku to AWS Migration Advice

From what i've gathered, there are many solutions to my problem but i'd appreciate some suggestions on where to start. here's the stack we're running on heroku currently:
Rails on puma
mongoDB
elasticsearch
redis
mini_magick
What goes into the decision of using Elastic Beanstalk vs OpsWorks vs CloudFormation vs just setting up everything manually myself? Also, I'd really prefer, for financial reasons, not to use some third party service like Docker if possible. The plethora of options leaves me a little confused as to where to begin or how to even choose. Background: right now I really like Heroku b/c i don't have to think too much about sysadmin (on my team i'm the only developer), but we were recently given a lot of annual AWS credits so it seems to make financial sense for us to shift over to AWS.
I want to expand on Mark’s great answer.
Available alternatives
Since you’re the sole developer, Cloud Formation and OpsWorks aren’t good options for you.
With OpsWorks you’ll need to write, or at least be aware of, the Chef automation code that configures your instances. On the other hand, Cloud Formation by itself isn’t enough. It will help you with AWS cloud resources creations, but you will still need to figure out how to orchestrate your applications deployment, just for starters.
Neither of these options can give you everything you need to run and deploy your code like Heroku does right out of the box. You’ll need to implement parts of it by yourself.
Since rolling your own automation on top of EC2 takes even more effort than the options above, I think you have two alternatives within AWS that will fit your needs:
1) Elastic Beanstalk
It’s the closest you can get to Heroku within AWS. You might have to spend some time getting to know the platform at first since it’s not as intuitive as Heroku, but eventually Elastic Beanstalk will provide you with all the tools you need to continue running your applications without spending time on sysadmin tasks.
2) ECS + Empire
Although you mentioned that using Docker is out of question for you, I still would like to highlight the option of using ECS, Amazon’s Docker orchestration service, as an alternative to Heroku.
By itself, ECS doesn’t provide enough automation to do everything you would expect from a PaaS. The service was intended to be used as a building block which you should extend to fit your needs.
Luckily, the guys from Remind have already done this for you. They have released an open source project called Empire, which according to its own description is “a control layer on top of ECS that provides a Heroku-like workflow”.
Empire is compatible with Heroku’s API, and its command line implements the most important features of Heroku.
Empire is an open source project, so if you choose to use it, you should be prepared to dig into its code from time to time. The documentation isn’t perfect, and although there is some traction around the project, the community isn’t very big.
Overall, it’s a good alternative to Heroku if you’re willing to run your applications using Docker -- and why shouldn’t you?
Addons
The main benefit I see to switching from Redis Labs to Amazon’s Redis service (ElastiCache), other than the fact that you have free AWS credit, is that it’s going to be easier (and cheaper) to secure access to your Redis instances when you also run your applications on AWS.
Overall, it’s relatively easy to replicate the addons you’re using with Heroku when you migrate to AWS. For the third-party addons like Elasticsearch you just continue pointing your application to the relevant endpoint. It’s a bit more complicated to replicate Heroku’s native addons like deploy hooks since you can’t continue to use them when you migrate to AWS. In these cases it’s usually possible to find alternative ways of replicating their functionality within AWS.
If you want to learn about how to migrate the most common addons, I’ve written an article that details how to do that, you can find it here: how to replicate Heroku’s addons on AWS.
Hope this helps.
For your Rails app, Elastic Beanstalk is going to be very similar to Heroku. I would suggest using Elastic Beanstalk if you are already familiar with a PaaS like Heroku. It's probably going to be a bit more difficult to configure at first (there are just a lot more options you can configure), but then it will be a very similar deployment process to what you are used to.
Of course Heroku and most (probably all) of those other services you are using run on top of AWS already, so you would really just be switching from one set of services built on AWS to Amazon's own version of those services. You could possibly continue using some of the same services you are using on Heroku. For example I believe MongoLab is the recommended service for MongoDB on Heroku, and it is my preferred MongoDB-as-a-Service on AWS as well. If you want to use those AWS credits for MongoDB you will have to setup the EC2 servers and install and manage MongoDB yourself.
For Redis you could use Amazon's ElastiCache service or RedisLabs. I've found the features and price to be better with RedisLabs than ElastiCache, but you can use your AWS credits with ElastiCache.
For Elasticsearch you would probably want to use Amazon's new managed Elasticsearch service.

Developing FrontEnd App without installing BackEnd

As I'm preparing my team growth, I searched informations for months about advices or good practices when it comes to welcome a FrontEnd Developer.
We are running Rails API on BackEnd and Angular on FrontEnd. Right now, we use 2 separate git repos, one for front and one for back.
Bot are hosted on heroku.
But our developers work with a local BackEnd. As we welcome new frontEnds we don't want them to install the whole huge package and config of Rails.
I looked at different solutions and don't know if it's possible/best :
BackEnd deployed on Heroku and making a tunnel for the FE dev to
access it ( what about CORS ? )
Deploying a Vagrant or RailsBox ? (we tried Docker and didn't work
at all)
Moving the front repo in the back repo ( yes, I know that doesn't
fix the main issue, but I'm wondering if the repo split could be a
stop about our goal ? )
I would definitely merge the repos. This will allow you to deploy a changeset (frontend + backend) across the stack. Otherwise, deployment will get to be complicated at a stage where you don't need that.
I think the best way is to have a one-liner for your frontend-developer to install the backend environment. At uberVU, we used Vagrant for this purpose, but anything works IMO as long as it's a one-liner and works across operating systems.
You have to keep a few facts in mind:
make the configuration tying the frontend to the backend as dumb as possible; have good defaults in place. You don't want frontend people wasting valuable time figuring out how to link the two after running them together
make sure that whatever solution you use, it updates the running backend automatically when they pull in new code. One very frequent mistake in our case was frontend people updating the code and not seeing API endpoints working correctly, etc. Something that watches for filesystem changes and restarts the backend daemons should work. Be careful on whether that works correctly with shared filesystems between the host machine and the virtualization solution you choose
make sure that the virtualization solution you choose runs on Windows and MacOS. While backend devs tend to use MacOS and Linux, frontend developers are also big fans of Windows. The latest versions are more and more handsome.

Ruby on Rails web server

I'm new to web development, and have a question about deploy ruby on rails application.
For what i'm understanding, there are two ways to deploy. One is using cloud server like Heroku (I'm currently using). You just need to upload your project to their cloud server and ready to go.
Another way is build your own server using, for example, apache+passenger. By doing this way, I need to have a physical computer with Ubuntu + Apache + Passenger running continually right?
So my question is which way is better, faster?
Heroku has a form of automated deployment built-in. There are other cloud-based providers which offer a similar sort of service.
The alternative is self-hosted. You don't need a "physical computer", you can use a virtualized server in the cloud just the same. Popular choices are Linode, Digital Ocean and Amazon EC2 which is what Heroku is based on.
"Better" is highly subjective. Do you know how to maintain a server? If the answer to this question is "No", then Heroku is probably the best bet.
If you do know how to maintain a server, you can usually get better performance from your own rig since you have full control over how your application is launched, how long it stays running, and can increase resources at marginal additional cost. The downside is you're responsible for everything should it malfunction.

Ruby/RoR development: locally or server

Our company has started development of own systems "in-house". We already got couple of developers, who will be responsible for writing code in Ruby/RoR.
We are currently discussing about infrastructure and I would like to ask: should we develop everything on local machines, then put it to test server and later to production, or develop everything on development/test server, then publish it for testing and later to production?
Just an update to the description above: under "local machines" I meant developers' desktops and this test/development server is a machine in our office.
It's a valid question, and as such there's a trade-off to consider.
Generally; work locally. Web app development has a natural flow that leads developers to be saving and refreshing browsers many times an hour. All the time you save on network latency will actually add up, and be less frustrating for the developers.
There are downsides to working locally however, you'll need to make sure that your set-up is EXACTLY as it will be on the testing/production servers. That means everything down to your kernel version, apache version, ruby/rails version. DNS is easy, but again must mimic the live situation perfectly in order for AJAX calls etc to work seamlessly.
Even if you ensure all of the above, you will likely have to make a few minor changes when you move the app to a live server, there just always seems to be something in my experience.
Also, running on a live server isn't SO painful for a developer. Saving a source file from a text editor/IDE via FTP should take less than a second even over the internet, and refreshing a remote browser session will give your UI designers a better feel for the real user experience and flow. If you use SVN rather than FTP much the same applies.
Security isn't much of a concern, lock down FTP and SSH to the office IP, but have a backdoor available if a developer needs to edit a source from somewhere else, so they can temporarily open the firewall to their own IP.
I have developed PHP and Rails apps on a remote test server, on an in-office server and on a local machine. After many years doing each, I can say that as a developer, I don't mind any so much.
As a developer, my suggestion is that you need to 1st do all developing work on your local server. After testing, you need to send to client to make it live.
I'm working as a web developer on Ruby on Rails # andolasoft.com, we are following the same procedure. Hope you got the idea.
Thanks

Selecting a Rails host [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm close to picking a Rails host. I think I need a VPS solution, because (1) my Rails app has gems and plugins that I need to install to get it working, and (2) I need an SMTP server to send emails from my rails app out to users.
But then it occured to today...
1) Do I actually need VPS and root access to get my app up and running, just because I need to install gems, or can I just copy my Rails app folder up to a Rails-supporting hosting server and start it?
2) If I get a Google Apps account, which would include a business-class GMail solution, would that give me an SMTP server which I could use to send emails to users?
I'm looking for least-support-needed-solution. I can afford to pay for VPS hosting, and a Google Apps account, but I just wonder if this is really my best option.
UPDATE: It's now been just over three years since I first posted this question and answer. I still prefer AWS for all new deployments of a professional or serious horsepower nature (that is, if I don't self-host), but I also regularly deploy demo and tutorial apps to Heroku. I haven't tried any of the many VPS providers that have popped up such as Linode or DigitalOcean, but generally hear good things about them.
The key thing that keeps me from choosing Heroku for all my apps is cost. Since most of my indie projects outside of work are things where I'd prefer to absolutely minimize costs, AWS remains the better deal between AWS vs. Heroku. AWS (or any VPS provider for that matter) has the nice side effect of teaching you the OS along the way, which turns out to be hugely valuable in the long term.
=======================
So, two years later, here's my update. I've used three services for hosting, and here's my take on each of them (I actually love them all, but for various reasons).
Slicehost (now part of Rackspace Cloud Hosting)
This was the first VPS host I tried, and I loved them. The people there were amazing, support was awesome, and it had a really cool grassroots kind of feel. Now that VPS as a solution is more mainstream, and Rackspace has long since purchased Slicehost, I feel that the service offering is still awesome. If you want a simple way to setup a server, plenty of Linux distro choices, and control over your server, this is an awesome option.
Heroku
Love these guys too. I built a hobby app that is hosted there, rpglogger.com (which as of Nov. 2012 has actually migrated to Amazon Web Services), and developing and deploying to Heroku is a no-brainer. I really like working on Heroku for two reasons:
It's dead simple to setup. It really is as easy as they say, in my experience, to get an app running on their platform.
A single dyno (web server instance) is free. So hobby apps, and smaller apps basically get free hosting. It's not just for hobbies though - their plugin architecture is second-to-none, making the addition of 3rd party plugins such as NewRelic, Exceptional, and anything else on their platform a matter of just a few clicks.
You absolutely cannot beat Heroku for ease of use. Deploying an updated version of your app is literally as simple as pushing to your git repo. Heroku isn't necessarily cheap (for anything other than the small app), but if you're in a situation where you believe developer time is more valuable than having control over the server, then this is an amazing option. You can always migrate your app to any other platform anyhow, if it gets big, or the needs of the app vs. the cost of Heroku no longer make sense for you.
Amazon Web Services
I do quite a few small apps, and AWS reserved instances are awesome. For $60 I can basically get a reserved instance for an entire year. That one server is enough to run 3-4 small apps on the same machine, with more optimized memory usage, and the ability to run multiple web server instances (vs. Heroku's one free dyno, though I hear you can custom config your Heroku dyno using unicorn to get more scalability). Basically, AWS scales really well, and lets you share a server among multiple small apps, or spread a larger app across multiple servers.
On top of that initial cost for the reserved instance, I only have to pay for bandwidth and other AWS usage (S3, for example). I think AWS is an amazing mix of ultimate scalability, great costs, ultimate control, and for enterprise customers who want to build their entire infrastructure in the sky, it can't be beat. Rackspace Cloud Hosting provides similar services, and they're probably comparable for most things. But if what you want is the Swiss army knife of cloud services, I think AWS is still way ahead of everyone else.
===============
So, that being said, I started on Slicehost, then went to AWS, then tried Heroku, and today I spend most of my time back on AWS.
AWS is the kind of platform that, after you invest a little time in setting up your collection of VPS machines, it often makes sense to stay on this platform and leverage their ever increasing set of tools.
Granted, it took me two years of trying several options, and trying every level of management from fully managed servers (i.e. Heroku, where you don't even think of the server, just the app) to fully controlled servers (Slicehost and AWS). After all that I've come to this point where I'm ready to manage my own machines in order to get the flexibility and low costs that I want.
Through automation, the actual management of the servers on AWS becomes a non-event, so I don't spend my time constantly patching my machines, or doing other sysadmin tasks. I just check periodically to see if my servers need reboots, I set them to automatically install all security updates (I happen to deploy to Ubuntu servers), which means I spend 99% of my time (at least day-to-day) writing the application - not managing the servers (managing services is instead an occasional task of a few day's work, and then nothing else for months) - which is where I want to spend my time as a developer.
Neither of your requirements are VPS-specific. I use shared hosting from Site5 and currently run two rails apps through the account, both with gems that are not installed on the server by default and sending email. Installing gems does not require root access.
If you want to use a VPS anyway, both Slicehost and Linode are often recommended for Rails apps. A few more are listed under Deploy on the Rails site. I would encourage you to do some research on your choice in either case. Good luck!
You could check out Ruby on Rails Hosting, What is a good Ruby on Rails hosting service?, Good Ruby on Rails free hosting, and What is a good Ruby on Rails and PHP hosting?.
I personally prefer Heroku which has offers free low-scale hosting and is very easily upgraded. Also, they allow you to install gems (similarly to the gem dependencies and rake gems:install, but with different syntax/files), and send a few free emails (200, but it is easily upgraded).
I hate Heroku, it gives you no control over services you want to use and it's massively over priced. Just try to make use of a gem or service they don't specifically support and you will quickly find the limitations and the horrendous pricing.
Heroku is my host of choice.
You can send messages using GMail SMTP as well as the commercial SMTP plugin.
I have also used Slicehost, Linode, Dreamhost and RailsMachine.
Slicehost/Linode are awesome if you can set up the box yourself.
Dreamhost is cheap-as and great for staging. Sites are ponderously slow at times though.
RailsMachine is second to none as a managed service. Highly recommended for the support and the well-tuned stack.
I prefer linode, aws or so.
linode : is a standard linux server. you can login, install 3rd party dependencies and play around just like in your own server. Installing nginx/rails/ruby is the same way as what you did on your own pc/laptop/server.
heroku : is a service. I have to learn lots of stuffs that are not valuable at all if one day you switch to another platform(e.g. linode) or you have your own real server, for example, check the logs, install databases, or install gems. I have printed out most of its documents and read them in 1/2 days, and then I realize that I can't use these knowledges in my working server( that my company offered to me)
linode is cheap enough, $20 per month.
heroku is not always free. and I don't think it's stable enough for demonstration purpose.(e.g. your free heroku app will fall in sleep in spare time, and will cost you several seconds to wake up. this SEVERAL seconds is long enough to make you lost your customers if they want FAST web app )
so, forget heroku, buy or setup your own VPS, use it for years, then you will be an linux expert.
I use HawkHost for all my hosting needs, and I'm 90% sure they meet all your criteria. They provide web hosting and VPS services for very good prices, and their basic web host plan lets you have Rails applications running as well.
I'm used Joyent host- http://www.joyent.com. It's good Rails host.

Resources