I am wondering if it is feasible to deploy wordpress as a series of lambda functions on AWS API gateway. Any pointers on the feasibility/gotchas would be greatly appreciated!
Thanks in advance,
PKK
You'll have a lot of things to consider with persistence and even before that, Lambda doesn't support PHP. I'd probably look at Microsoft Azure Functions instead that do support PHP and do have persistent storage.
While other languages (such as Go, Rust, Swift etc.) can be "wrapped" to run in AWS Lambda with relative ease, compiling PHP targeting the same platform and running it is a bit different (and certainly more painstaking). Think about all the various PHP modules you'd need for starters. Moreover, I can't imagine performance will be as good as something like a Go binary.
If you can do something clever with the Phalcon framework and come up with an easy build and deploy process, then maayyyybee.
Though, you'd probably need to really overhaul something like WordPress which was not designed for this at all. It still uses some pretty old conventions due to the age of the project and while that is all well and good for your typical PHP server, it's a different ball game in the sense of this "portable" PHP installation.
Keep in mind that PHP sessions are relied upon as well and so you're going to need to move those elsewhere due to the lack of persistence with AWS Lambda. You can probably find some sort of plugin for WordPress that works with Redis?? I have to imagine something like that has been built by now... But there will be many complications.
I would seriously consider using Azure Functions to begin with OR using Docker and forgoing the pricing model that cloud functions offers. You can still find some pretty cheap and scalable hosting out there.
What I've done previously was use AWS ECS (Docker) with EFS (network storage) for persistence and RDS for the database. While this doesn't carry the same pricing model as Lambda, it is still cost efficient. You can set up your ECS Service to autoscale up and down. So that way you're running the bare minimum until you need more.
I've written a more in depth article about it here: https://serifandsemaphore.io/how-to-host-wordpress-like-a-boss-b5993fcfbd8e#.n6fbnf8ii ... but it's basically just the idea of running WordPress in Docker and using EFS to offload the persistent storage issues. You can swap many of the pieces of the puzzle out if you like. Use a database hosted in some other Docker service or Compose or where ever. That part need not be RDS for example. Even your storage could be handled in a different way, though EFS worked pretty well! The only major thing to note about EFS is the write speed. Most WordPress sites are read heavy though. Your mileage will vary depending on your needs.
Is it possible? Yes, anything is possible with enough time and effort. Is it worth it? That is a question best to ask yourself.
PHP can be run on Lambda as per the documentation located here: https://aws.amazon.com/blogs/compute/scripting-languages-for-aws-lambda-running-php-ruby-and-go/ .
The bigger initial problem as stated in other comments is a persistent file system. S3 for media storage is doable via Wordpress plugin (again from the comments) but any other persistent storage for the request / script execution is the initial biggest hurdle. Tackle one problem at a time till you get to the end!
Related
As I heard that there are many things need to be considered before Deploying a Meteor App, However, it's still quite vague. Anyone please give me some opinions about this issue. Thanks
This is probably the wrong forum for this type of question, since it's highly opinionated and not really in the Q&A format, but I'll give you some of my personal opinions.
Where am I hosting my app?
This has a lot to do with what your app is (Web-based app, Android-only), how many users you plan to have, if this is a public app or something private, how much you have to spend, and many other factors. Options include:
Host it yourself - Could be on a VPS (Virtual Private Server, like Digital Ocean and others), some cloud offering (AWS or similar), or a bare-metal server you have hosted somewhere (like in your closet).
Pay for dedicated hosting - Several out there that offer many different features, like Galaxy or Modulus, etc.
If you host it yourself, then you have to maintain the hosting solution, I.E you need to support it all on your own. This may mean provisioning/installing the OS, installing and configuring the server apps (MongoDB, Node.js, web servers, etc), and maintaining everything over time. The benefits, however, are potentially cheaper hosting costs (although this could be debated) and custom setups/architectures. If you are creating an app that should remain private (I.E. not a public app) you may want to consider this option so you can host it internal to the company and not make it public-facing. There are some tools out there that can ease the process of setting up the server, for instance MUP/MUPX.
For dedicated Meteor hosting, the benefit is that someone else does the installation, configuration, and maintenance of the core apps, and all you have to do is push the button to move your code in. These options can be more pricey as they are covering the IT costs of supporting the environment, but they usually come with the benefit that a) You don't have to install all that stuff yourself, b) you don't have to be an expert at all the "plumbing", c) You don't have to hire a staff of people to support your infrastructure, d) These hosting services usually know how to optimize things properly to get better performance for your app.
Do I deploy manually or do I use some tool?
This depends highly on the answer to #1, as your hosting decision may come with it's own set of tools used to deploy (ex. Galaxy), or you may need to shop around for the best tool for you. For manual deploys, I'd suggest looking at MUP/MUPX, which can automate the deployment of your app, even configuring the web server, DB server, and setting up everything as Docker images. Or, if you want to have more control, maybe take a look at something like Grunt or Gulp, which are more build-scripting solutions (similar to ANT/Maven/Gradle are for Java).
Do I expect a fast growth, or a slow trickle?
Again, this has a lot to do with where you plan to host. Lots of cloud services make it easy to grow/shrink your cluster of servers based on load, but this takes a LOT of configuration past just installing an OS. VPS and bare-metal solutions will be the hardest to expand. Dedicated hosting will depend on the provider.
You need to serious need to think about how you might handle a fast-growth situation, even if you don't think your app will take off. The internet is riddled with apps that failed because they didn't think they would be as successful as they were. It only takes one mention on something like Reddit, Y Combinator, or Product Hunt for your app to get a sudden and unexpected rush of traffic that takes down the server(s). If you know your growth will be controlled in some way, like if you have a private app with a pre-set number of users, then you might not need to worry about it.
Do I need to monitor my app?
The answer to this is always "Yes", but to what extent? Do you need to provide 24x7 uptime? Would an outage cost you lots of money, make you loose your biggest client, etc? Can the users live without service for a little while if it goes down, or would I loose face and customers? Depending on how serious you need to be, you should consider some sort of monitoring of your infrastructure and app. Again, there are LOTS of options here, and your decision might be swayed quite a bit by the answer to the first question.
I am sure there are other questions, but these are the biggest I could come up with.
I currently manage Web App on a LAMP stack hosted with GreenGeeks. As it has scaled up, I have started learning MeteorJS on my local machine and am thinking about redeveloping the app in Meteor to support more concurrent connections. My questions are:
Can Meteor simply be hosted in a Simple Amazon S3 Bucket with no need for a stack of any kind? Is this smart? When something seems this simple, I get nervous.
Is Meteor as portable as it feels? Migrating a LAMP app from one server to another can be a real pain. This "feels" like it's as simple as zipping up the whole thing and simply dragging it anywhere. Again, feels too simple = nervous.
Is meteor the right choice if I am looking to maximize concurrent connections and reduce the number of times I need to go to the server for information? My app loads about 2 MB of data per user and I'd love a situation where this can be loaded once and the user has it available to interact with without going to the server (unless it changes).
Ok answers to your questions:
Well actually You can deploy your meteor app into an Amazon EC2 instance, the process is pretty easy, take a look to This video
Meteor is incredible portable, actually it was made with nodejs, therefore it inherits its features
You are in the right way, you know meteor is reactive, it acts in real time, also uses mongoDB, which is incredible faster than a regular SQL database, so in general meteor's performance is amazing, in fact, there are lots of packages that improve even more the performance of your app like this one and many others
I am fairly new to dealing with high traffic websites and I'm looking for a setup that will be able to scale well into the future.
My site currently uses one main script to pull data and store it into a database. The rest of the website is mostly presentation of this data from the database.
I have been looking at the possibility of using Amazon Web Services (EC2) or Google Compute Engine for running the main script. Then transferring that data to a more typical web hosting service. One thing I am not sure that I need to worry about is load balancing, I've seen that using NGINX for the load balancing can help improve the performance.
My goal is to have the site up 99.99% of the time and execute the script as fast as possible. It would be optimally nice to have a great support in case something goes wrong too.
Any ideas, comments, or suggestions are welcome. I'm am trying to learn how to handle this as I have a couple other websites that are currently growing and may need such a setup in the near future.
Thanks!
Google Compute Engine is still in its very early stages. For that reason alone, I would recommend using EC2. With EC2, you have all of the features you need. The ELB can seamlessly load balance between any amount of servers, which would help with the 99.99% uptime.
Using CloudFormation, you can define templates for scaling to run that script in a clustered environment.
Hope this helps.
Just find yourself a good host with a decent SLA, running a relational database within the cloud is asking for problems when you do get high database loads.
Don't be fooled, the cloud is a really nice solution for some problem.. but NOT ALL!
Same goes for NoSQL, and the combination of cloud and NoSQL.
Do your own research and don't be hoaxed by the marketing machines and the people not doing their homework.
Loadbalancing is nice but big change your database is the first bottleneck you run into.
Don't optimize thing before you need to!
If you are asking me, find yourself a decent dedicated (non-virtual) server with a decent SLA and backup plan.
Calculate howmuch 99.9% uptime actually is and realize that there is no problem in reaching that aslong as you have a decent SLA and proper backups.
You can always go from iron to the cloud,.. the other way around is a different story.
I’m using EE for the first time. I design/develop on two machines, so I use private github repos for all my client work. I’d like to run this EE project on SQLite locally while I’m developing and designing, and then switch it to MySQL once I’m ready to deploy to the staging environment for client review. That way, I can track DB changes easily between machines, as there is a lot of content on this particular site, and exporting/importing DB tables every time I switch machines (three or more times a day) is getting old.
I realize I could use the client’s MySQL DB remotely, but would rather keep everything local, if at all possible. So, how can I run EE with SQLite?
This question (or something similar) was made almost three years ago here. The accepted answer hints at possible support in EE v2.0+ (via CodeIgniter’s then-new database abstraction), but I can’t find any recent information (official or otherwise) on how to make it happen.
I short: no. Active Record is not universally-used throughout EE, and especially not in third party add-ons. In fact, the documentation for the Database class does not mention Active Record at all.
I'd suggest just installing MySQL locally.
I don't think you'll have much luck with non-MySQL DBs — MySQL statements are hard-coded into EE, despite the EE 2.0 promises of a fully-fledged CI app with various DB connectors.
I think your best results might be to find a centralized host for your dev DB. EE is especially painful to work with on multiple machines because of the DB — the whole thing is really built with "one server, one developer" as the primary use case.
You can simplify it a bit by keeping your templates saved as files, and rigging your settings to be server-agnostic. I also keep little scripts around to quickly dump/import the DB when I have to, which makes moving the site around in a git repo a little easier. A few details here: http://www.viget.com/inspire/expressionengine-on-multiple-machines/
I have got a Bizspark account from Microsoft and they are providing a basic Azure account. I have been told that it can run PHP, however I would like to use a more tested solution like WAMP. On top of that, I want to place a quite heavy WordPress / BuddyPress installation (that I hope will bring a lot of trafic :)
Has anyone done something similar to this? If so, what is your experience / pitfalls etc.?
Thanks
Stelios
Yes, you can do this. At the end of the day you are just using Windows Server, so anything that installs there will install in the cloud as well. I have done this myself for hosting WordPress in Windows Azure.
However, there are some pitfalls here. Mostly the pitfalls are around the M (MySQL). To setup MySQL in Windows Azure is not really that hard, but you have several considerations on how to make sure it is always available. You can:
Setup a single instance of MySQL in
a role and store the db on local
disk (this is a bad idea).
Setup a single instance of MySQL in
a role and store the db on a drive
(blob backed storage)
Setup 2 instances of MySQL to each
point to a shared drive
(hot-failover). Only one drives will
be able to mount. Now, you have reliability and failover, but a single instance at a time working for you.
Setup 1 writer of MySQL on a drive,
and multiple readers on a snapshot
of a drive. Put in some logic via
connection strings to make sure only
writes goto a single one and reads
to the others. Snapshot every X
mins to update readers.
Setup multiple instances of MySQL
and use native replication features
(each storing to local disk) and
rely on that if you lose an
instance.
There are probably more permutations, but the gist of the problem is how you scale out MySQL to be available and reliable. In Windows Azure, you don't get to rely on the fact that the local disk will always be around or that you will always have the same instance. In fact, you can guarantee that your instances will be down for some period of time each month and eventually, given enough time, you will lose the local disk.
Overall, with multiple instances however, you can guarantee they won't be down simultaneously (to the service SLA level at least). So, you need to make sure MySQL works with multiple instances (or live with single instance downtime) and that your data is backed by blob storage to guarantee it is persisted.
Or you can scrap all that crap and just use SQL Azure, which solves all those problems. So, it become WASP. SQL Azure can also be more economical as well for smaller DBs.
Or you can scrap all that crap and just use SQL Azure, which solves all those problems. So, it become WASP. SQL Azure can also be more economical as well for smaller DBs.
Ditto.
Installing MySQL on an Azure role is not a good idea for plenty of reasons, most notably (lack of) scalability and reliability. (That's just for deploying on Azure, MYSQL itself is great)
To set it up remotely reliably you're going to need a dedicated instance which will run you at least $40 a month, going with SQL Azure is $10/Gb, or free if you get an introductory offer or Bizspark.
If you're just looking to play around with a single instance app, I'd suggest you rather use SQLite or some other in memory db, it'll be a lot less painful.