I'm developing a meteorjs application and wondering what is better , actually deploying in meteor js cloud is elegant , free , and work perfectly, but is this will still free , is their any limit or compensation .
This question is very obscure by nature and will receive mostly opinionated answers. I have a feeling it will be closed before too long but for archival sake and to answer your question. Meteor's current free deployment has no guarantee of uptime and shuts down the app when not in use until another user attempts to access your app. For demo's and prototyping this should be fine.
However I would highly suggest that if you need something reliable and for use in a production environment stay far away from the current Meteor service for deployment. You are limited to a database size and how much access you have to things such as the file server. There are many great services out there that allow you to deploy just as easily.
Check out modulus.io for super simple deploys. If you are on more of a budget you can choose a service such as Digital Ocean or any other VPS service that allows you to install Ubuntu and use something such as MUP which is a great package made by Arunoda for deploying to Ubuntu based systems.
Related
When I run my app locally, it's nice and fast, however, when I deploy to Vercel, things get very very slow. My app is a NextJS app, using Prisma as the db client. The database is an Amazon RDS Postgres instance. I'm pre-launch so there's no real traffic, so I don't think there are issues with connections or that I need a pgbouncer setup... though I don't really know how to audit that either.
Any tips I'd love to hear em!
Might be worthwhile to use the browser Dev Tools, specifically the Network and Performance tabs, to see if you can find what is slowing you down.
You could also check out using the React Dev Tools and look at the Profiler tool there, but that has to be run locally, which may not be as useful, since you say the app runs fast locally
I work for a small web startup. They have decided to use OpenStack as IaaS and then on top of it, cloudfoundry as PaaS. I am trying to learn about this technology stack. But I am really confused even after going through documentations and related materials on the web.
What do I want?
I have a web site, that currently runs on a RHEL system (aws instance), with
nginx as web server. I want to shift this to OpenStack-cloudfoundry
stack because the company's management has decided to do so. They also
want me to evaluate if I can put Docker to use anywhere.
From my understanding, OpenStack (Iaas) will provide me with all stuff related to hardware software needs, and cloudfoundry will help me on the development front.
Now, where does nginx (or any web server) come into the picture? Is it part of Openstack or Is it part of cloudfoundry?
On my aws RHEL system, Do I just install Openstack and Cloudfoundry, and then push my app and not at all bother about what happens beneath? I am really confused.. please help out.
And, Is there anywhere I can utilize Docker, in this setup?
You would generally not deploy OpenStack on top of AWS. OpenStack is similar to AWS in that it provides a service for you to create and destroy virtual machine instances, manage networking between and around your VMs, attach and detach block devices to instances, etc. In other words, both are services for managing "infrastructures", where "infrastructure" here means a virtualized datacenter, which at its core means a bunch of hardware running hypervisors that allow you regard the datacenter as a bunch of virtual machines that can be spun up and down on demand, rather than a bunch of "static" physical machines.
AWS is an Infrastructure-as-a-Service provided by Amazon, so you don't have to install AWS yourself, you can just start using it to provision VM instances within Amazon's datacenters. OpenStack is software you install yourself (or pay a vendor to manage for you) on hardware you own or pay for yourself, and once installed OpenStack provides a similar service/interface to AWS.
With a Platform-as-a-Service, you concern yourself more with your application code, and "just pushing it", and don't have to concern yourself as much with what's happening on the underlying machine. You don't have to worry as much about the underlying OS, making sure you have the right runtime and code dependencies of your application, generally don't have to care about the webserver that's serving your code, etc. And you get many more higher level features, e.g. easy ability to scale vertically or horizontally, dynamic routing, automatic log aggregation, automatic health management, etc.
As far as how nginx fits in, it depends how you're using nginx, and what kind of application you have. Cloud Foundry has few couple ways of dealing with applications.
One is the buildpack model, where you simply push your source code to the platform, and it will automatically detect the appropriate runtime and dependencies for your application. For instance, if your application is a Ruby application, it will automatically detect this, and by default automatically run the application using the WEBrick server. However, you can choose other Ruby webservers such as Phusion, Passenger, etc. [1]
If your application is primarily serving static content, it will use nginx as the webserver. [2]
Another is using Docker. You can deploy applications based on Docker images on Cloud Foundry, in which case you could have a container running nginx and your application inside the container, or not, it depends on whether you still need nginx. Pushing a docker application is as simple as:
cf push trainingwebapp --docker-image training/webapp -c 'python app.py'
Here, this uses the sample Hello World web app from the Docker documentation. [3]
[1] https://docs.cloudfoundry.org/buildpacks/ruby/ruby-prod-server.html
[2] https://docs.cloudfoundry.org/buildpacks/staticfile/index.html
[3] https://docs.docker.com/engine/userguide/containers/usingdocker/
I've had very mixed experiences trying to host on Meteor.com.
I often get "This site is down. Try again later.". Initially I couldn't figure out why, but then I suspected that the problems were caused by me accidentally restoring the "system.users" collection. I tried restoring without that, but the site went down a few days later. Today, it's magically back up again without me doing anything.
"meteor logs" shows nothing. It's a complete black box.
I've investigated other options (Heroku, demeteorizer, meteor bundle, etc), but they are clunky and unreliable too (problems installing fibers, doesn't seem to handle Meteor.call() properly, etc).
I would really like to host in production on Meteor.com, but I feel I can't trust it right now. Free is nice, but I need reliable, production-quality Meteor hosting. When will I be able to buy that from Meteor.com?
Thanks,
Graeme
From the documentation:
We provide this as a free service so you can try Meteor. It is also helpful for quickly putting up internal betas, demos, and so on.
So it means it's intended to try things out, not for production. They offer it for free, I think it would be bad manner to abuse it. And with so many people around trying the thing, don't be surprised if it's overloaded from time to time.
I'm not sure if and when the Meteor team will make this hosting production ready. At this moment, I'm happy they're focusing on making the framework mature.
For other options, Heroku works as a charm. I'm using it for several projects, including production ones, and had no problem. Don't bother with demeteorizer and such. Just create a new app and run these commands (replacing appname with your app name):
heroku git:remote -a appname
heroku config:add ROOT_URL=appname.herokuapp.com
heroku config:set BUILDPACK_URL=https://github.com/oortcloud/heroku-buildpack-meteorite.git
git push -f heroku master
MDG (the Meteor Development Group, the core team) is working on a hosting solution called Galaxy. It will likely tie in to meteor in ways other solutions won't (such as meteor deploy). This will be (AFAIK) a paid service, and as such will likely offer analytics for better insight (my guess). And of course scaling will be taken care of for us.
More on the subject: http://www.meteor.com/blog/2013/10/01/geoff-schmidt-at-devshop-8-getting-meteor-to-10
I want to create a modestly scalable development environment for an in-development web service.
Ideally, there would be an nginx web server with haproxy and a few database servers, websockets, the works.
I'd be going with Amazon cloud services for all of this hosting... but I'd rather not pay for CPU cycles when I'm just developing... much less develop on a remote, cloud environment.
What's the best way to go about modeling a somewhat complex development environment locally that could - hopefully, at the press of a button - sync with a similarly architected Amazon cloud environment?
All I have is my Macbook Pro. I also have a fully built 1Ghz tower computer in the closet I could leverage, if needed, and wouldn't be opposed to buying more. But, ultimately, I'd like to have the ability to sync to production with minimal steps and reconfiguration.
Thanks!
Check out vagrant and virtualbox. That will get you local environments running nicely on your macbook. Syncing to EC2 is going to be tougher. At the system level you'll want to use something like puppet or chef (which are both nicely supported by vagrant). Add to that a solid automated application deployment mechanism and you should be close. Be prepared to put some time into this, it's not likely to be a trivial undertaking.
I'm getting close to finishing a public-facing ASP.Net app and I'm starting to weigh deployment options. I'm an ASP.Net/SQLServer veteran but noob when it comes to Azure. I'm wondering how others have felt about the learning curve to effectively migrate a local dev ASP.Net/SQLServer apps into Azure cloud.
More specifically:
How steep is the learning curve towards understanding administration and programming concepts, and do you think it's worth the investment?
What is Microsoft's support like if I have catastrophic problems from my cloud infrastructure and my live site is down? My expectation is a large price tag for a not-so-urgent SLA.
Will my non-Azure ASP.Net app require significant modification and/or coupling to run in the Azure environment?
Thanks
I answered a similar question a while back, here. Azure has evolved since then:
Azure's AppFabric Cache is currently in CTP (community technology preview) and will go live some time later this year (sorry, I can't quote a date). With a single configuration change, you'll be able to enable the asp.net session state provider without changing any code, and have your session state available to all of your web role instances.
With Azure v1.3 which rolled out in November, you have have the ability to run tasks at startup with elevated privileges (e.g. to run an MSI to install some prerequisite control suite).
For monitoring, you can take advantage of Microsoft System Center, which now supports Azure directly. Alternatively, you can look into 3rd-party options such as AzureWatch.
With Azure's extra-small instance, you can run a site for approx. $44 monthly. You mentioned catastrophic failures and SLA. With Azure, you need a minimum of two instances for SLA to take effect (this is because your virtual machines are located in physically different areas of the data center, in separate fault domains). So you're looking at approx. $90 / month to run a site with 99.95% uptime. Only you can determine whether this is worth it to you. Yes, you can host with a simple hosting provider for significantly less (such as GoDaddy). However, if your site fails there, you have to wait for it to be detected and then installed on a separate box. Also, you share each server with potentially dozens of other tenants, which will impact your site's performance. With Azure, at most 8 tenants will occupy a box, depending on how many cores you configure your virtual machines to use. And it's incredibly simple to scale up or down to handle traffic increases and decreases.
My personal experience is that there isn't much documentation and you have to search through blogs / forums to find answers for more advanced questions. If you have a nicely design app then there shouldn't be much problem with porting - you can google for Azure version of ASP.NET providers, ie. membership.
The biggest disadvantage may be cost: you have to do your maths but for me it turned out that a VPS hosting is much cheaper than Azure.
I would say that unless you get considerable savings on infrastructure don't move to Azure for just the sake of doing it. A hosted server with SQL and IIS will give you less problems and a bit more freedom.
I see an excellent answer by David Makogon already. The following might be helpful for you as well. The last episode of the Connected Show podcast was about migrating Wold Maps to Azure. If you are considering moving to Azure it is certainly worth listening to, as they explain the challenges they faced during the migration.
You could give a look at Moving Applications to the Cloud on the Microsoft Windows Azure Platform in MSDN.
Cheers.