I agree completely, but I think the key difference is that if you get stuck trying to build out a feature, your app and users suffer only in the sense that they don’t yet have that feature. If your deployment strategy breaks, then you are probably scrambling, regardless of whether you diy, use a service, etc. Once you’ve had that fear in your heart once or twice, a service like Heroku or Galaxy can look very appealing, especially if you’re running production with paying users.
That being said, if you take a bit of time to get to know DevOps, even if your Heroku app goes down, you can deploy manually to AWS, DO, etc. But you still have to take the time, as you (@Babak) pointed out.
I agree that it’s an important skill to learn but using those skills come with tradeoffs. Heartbleed is a good example. Once that breaks are you able to update dozens of servers yourself? Do you have the time to keep the server OS patched and up to date? Is it cheaper to let Heroku do it for you? Typically clients will save money by having Heroku handle this instead of having me do it (and Heroku can do it better IMHO).
Also lets not forget that if you’re rolling this yourself you’re likely completely dependent on MUP unless you can setup Forever, handle rollbacks for bad releases, SCP’ing or pull down and compiling your app, etc…
IMHO it takes more than just 20-30 hours of learning in a vacuum to be able to do as good of a job as a PaaS (Heroku/Galaxy/etc…). Getting them to work and making them work well enough/reliably to operate business that can lose thousands of dollars when down are two different things.
Just my $0.02! I still think these are things that should be tinkered with, and used on hobby apps, even if you don’t use them in production.
I see your point. About heartbleed–how hard is this anyway?
With proper abstraction, all of the dozens of servers mirrors of each other and updated with a few commands.
Heroku is also more costly than intelligently utilizing Spot Fleet, etc. Another way to look at “I’d rather focus on my app” is this: I’d rather have more money to put into my app. Viz.-- development, design, marketing, advertising, etc.
Consider this for a “hobby” app: an m4.large spot instance costs roughly $15 a month. Spread that over three regions and load balance, you’re looking at like $50/month for serious power and triple redundancy. Sure spot fleets go down, but its really unlikely all instances are going down together if spread across regions. Furthermore, you could serve the front-end JS portion of the app on CloudFront.
With a little thought, for under $100 someone can have a pretty serious setup. Heroku can’t touch that. Galaxy can’t touch that. It’s worth learning.
‘Modulus deploy’ runned quite well to me. One line of code and all running. Database included. Need to say that the non inclusion of database is the only thing that keeps me out of Galaxy. I’d really like to deploy on Galaxy, but until it offers an integrale solution i’ll stay at modulus.io
Yep I agree, that would be a killer combo. The multi region is especially enticing as the only way to do multi region on Heroku that I know of is to use Route53 and multiple apps on different regions. Using EBS is also a nice feature once you have multiple instances. Though I think Apollo will help to greatly reduce the amount of servers needed.
One nice site to learn these is CBT nuggets as they can really dive in deep (on my short list of things to get into): https://www.cbtnuggets.com/search?q=aws
Regarding @jsantana 's pain point of compiling apps locally and uploading a large bundle… you can continue down the manual deployment path and write some scripts so that deploying is a one line command. Looking at MUP source code would be a good starting point (as well as writing down everything you manually have to do).
This is very convenient on day 1 but be aware that having your database in Modulus makes it very hard to switch hosts. You would have to migrate all of your data over to a new host in that case. Also more importantly Modulus and MDG are not spending all of their resources and knowledge on maintaining databases while a dedicated database host only focuses on keeping your data. IMHO the odds of having better DB perf and support are way higher with a dedicated host. My personal favorite for Mongo and RethinkDB is Compose.io as they’ve worked out really well for me (I’ve also used MongoLab and Compose for Mongo DBs).
Here we’ve been using mupx for our oldest production app and galaxy for our newest. mupx is great but I’m a little nervous relying on 3rd parties and each release of Meteor I have to wonder if I can update and still deploy with it. Galaxy has being improving steadily and the SSL integration was a big win. So I will be migrating the mupx app to galaxy soon I think.
After reading this thread through I will definitely be looking at Heroku and also CircleCI. Thanks @SkinnyGeek1010 & @siphion.
After initial deployment via mupx or what-have-you.
If your upload speed is the problem consider building a simple second level file watch (like meteor does) of your build dir to scp only the changed files to the server or a free file sync app via sshfs link. Putting said script on the deployment server to build from the source if it’s all minified and merged for single file deployment might save you time but this would be much better on a staging server, which would save on these concerns. Then deploy the slower way to production if nessecary.
If you just use raw js files during staging (no real build process) you can reload the client after pushing changed files via scp or similar sshfs mount. Anyway it seems if you can’t setup a local dev environment sufficiently and upload speed is a problem and you can’t also alternatively run a staging test server environment it seems like a possible solution to me.
It should be possible the deployment system is smart enough to git the release from your repository automatically and your development environment is beyond a sufficient simulation maybe with load testing ability etc. Once a new release is pushed and maybe a signature signed to authenticate etc. a rolling update is self triggered via git notification API.
Alternatively maybe consider a faster connection?
I’ve not studied Heroku.
As a long time developer and person who likes to deploy a lot of things to a lot of sub-domains, I did not want to pay per-instance prices. Therefore, I have been working on an AWS AMI to solve this problem in a way that satisfied my requirements… here is a sneak peek:
I’ve been using it for six or so weeks now, and it has taken that long to get through all the AWS hoop-jumping to get the AMI packaged, scanned, documented & etc… but as soon as they approve my new logo (last step!) it will be published.
It should be available for free next week in the Amazon AWS Marketplace!
+1 for Heroku. I agree with @SkinnyGeek1010, other points I’d add:
Easy integration for automatic test runners (e.g. CircleCi).
Having automatic per pull request staging apps. This means that every time I create a pull request, a brand new (free) staging app with that code gets automatically spun up (with mongoDB and pre-set settings) so that it can be QA’d or shown to the rest of the team.
I’m still using MUP with AWS. Works great. Had to take a break from app dev which is why I’m still on MUP. However, after several server spikes/restarts, I’m now finding I need to look into horizontal scaling/load balancing and have been looking into options - Galaxy, AWS, cluster, etc.
It seems like cluster is no longer developed and also has a problem supporting multi-core machines. Is there a majority on what to use for horizontal instancing? I think Galaxy looks easy enough, but I’m curious how they scale on AWS behind the scenes. As everyone said for the last few years AWS couldn’t support session-affinity and websocket at the same time across multiple EC2 instances.
You can use nginx / tengine with sticky session and redirect to your meteor instances. We use it with Digital Ocean and I would be very surprised if you can’t do it with EC2 instances.
Nice. And looks like Galaxy rolls its own sticky-session support on AWS that they call “stable sessions”. Seems very cool and well planned. Learn about it here:
I echo this question. Also, can we ssh into a heroku instance? I need to place temp files and templates OUTSIDE the Meteor directory, and usually do that with a ssh to a EC2 instance. Without ssh support, I have no way to access the file system.
I’ve been using heroku for easier deployments, but I don’t think you can access it with ssh. If I need custom file storage I use digital ocean with nginx and mupx or manual deployments using meteor build
You can use fscollection package and state the url from the computer/server, example: /home/user/Documents/... not sure if it works with mup/mupx as I’ve only tested it with manual deployments but I’m pretty sure it would since you are storing the meteor app in /opt/appname folder inside the ubuntu server