PHP Fog to be discontinued on December 21st(docs.appfog.com) |
PHP Fog to be discontinued on December 21st(docs.appfog.com) |
But actually, I'm glad to hear it. Over the past 2 weeks (since we upgraded matchist to a PHP Fog dedicated server), their support team has basically dropped off the face of the earth.
Their support live chat disappeared. Their phone number goes to voicemail. And there's no way to get a hold of them other than their ticketing system (which they respond to every few days if you're lucky).
I loved PHP Fog when I first heard of it and started using it 6 months ago. But honestly, I'm not sure we're going to switch to AppFog since it's the same team. Not sure I want that level (lack) of service.
Was there a particular ticket I can review for you to see what happened? I want to make sure we don't drop the ball here.
Dear Fogger,
It is with a heavy heart that I let you know that the PHP Fog service will be discontinued in December in favor of AppFog, which is PHP Fog 2.0. I am incredibly sorry for any inconvenience this may cause you.
Creating PHP Fog has been an amazing experience for us and it could not have happened without you––thank you for your support. With your help, we’ve built an amazing PaaS for PHP developers. And along the way, we’ve applied what we’ve learned to creating our new product, AppFog.
AppFog is the future of our business, and we very strongly believe it is also the future of PaaS. So, in order to focus our team and efforts on continuing to build a better solution for developers, we will be shutting down the PHP Fog platform this coming January and focusing solely on AppFog.
We have considered this change very, very carefully because we understand that this could present challenges for some of our users. But in the end, we are confident that moving to AppFog will give you additional flexibility, additional languages, additional infrastructures, and the ability to deploy your apps to private cloud infrastructure as well as leverage the strengths of the OpenStack and Cloud Foundry ecosystems.
To help in the migration, we will do be doing everything we can to help this be as easy and painless as possible: 2GB of RAM in our Free Plan We will be releasing a series of blog posts that walk you through the migration to AppFog. We will also be publishing documentation of the migration path as well as solutions for some of the edge-case differences between the platforms. To start with, we have created a migration FAQ that should help you begin the migration process.
I am committed to making AppFog a product that will make you look back at PHP Fog and think, “I’m really happy I switched.”
https://gist.github.com/4067487
The subject "Urgent News about PHP Fog" rubbed me the wrong way. I think "PHP Fog is Shutting Down" would have been better.
PHP Fog had its share of problems, but AppFog doesn't support Git.
Seems pretty stupid to drop support of git in favor of their own product.
Should have been warned whem some time ago a 15year old hacked their system and controlled all their servers.
I am so sorry for the inconvenience, we are working on some tools to make the process easier, but for now here is a tutorial:
http://blog.phpfog.com/2012/11/12/migrating-your-php-apps-fr...
* It assumes you have the directory locally. Can't it be downloaded from phpfog?
* It doesn't say anything about copying environment variables.
* It doesn't talk about making sure you have at least as much system resources. It should say how to find how much memory you had with phpfog to make sure you have enough with appfog.
* It doesn't cover data migration.
* Even without covering data migration, it could at least have covered migrating the database configuration, but it doesn't.
* It leaves with an appfog domain name. It should say how to switch them.
* Too much of the post is devoted to going through AppFog's features.
* It has some cheesy marketing for AppFog like "af-plus-php-equals-win" and "Lots more functionality where that came from".
I don't think I could bring myself to call it a migration tutorial.
You have my cc on file, a semi-happy customer and now you want me to do all this work? YOU should be doing all the work for the migration - think of it as a way to maintain revenue!!!!
It might sting now, but those that used PHPFog might like AppFog more.
Once they do something like, for example, cloning an app in Singapore and re-deploying it in Ireland in less than a minute, they'll see the value in what we've built.
But regarding the business transition over at App Fog, you know what's really strange: Why does the 'dead simple' migration process start with creating a new account? Isn't it the same company? At the very least, if I were in charge of AppFog I wouldn't make everyone sign up again. Just saying.
Signing up for AppFog
First things first: score yourself a free AppFog account at console.appfog.com. It’s the same thing we’ve all done a million times: e-mail, password, and then e-mail verification.
There are more options if all you need is WordPress. ZippyKid and page.ly both seem to be high quality and economical.
AppFog is absolutely thriving right now and will be around for quite some time, we assure you.
I would encourage App Fog to offer a "fully managed" migration option, even if it's for a token fee.
PHPFog was my goto place for self-hosting Wordpress blogs, is AppFog as simple?
https://github.com/mhoofman/wordpress-heroku
I've used it for a few projects and it works reasonably well.
Is it true that appfog's filesystem is volatile? Does this mean that it could be wiped without a system fault or a user shutting down the system? If so, there doesn't seem to be a clear migration path to appfog for PHP users that are using the writable directory support. If not, it should probably be documented that writes will only go to the one instance and that if you're using multiple app server instances you need to set something up.
But the problem is that AWS pricing itself is not completely transparent. It's based on usage, which means that the bill at the end of the month can end up being an unpleasant surprise, as it has been for lots and lots of AWS users over the years. Who can know in advance what their usage figures will be?
RAM-based pricing means that the bill at the end of the month literally cannot be a surprise. We have four available plans, and monthly bills map directly and seamlessly onto those plans.
We run on AWS (among others) but WE pay AWS, not our customers, because we think that part of the mission of PaaS is to shield customers from the many disparate pricing models on different IaaS providers. Want to run on Rackspace via AppFog? Same price. Want to run on HP? Same price. Azure? Same price.
PaaS needs to abstract hardware away completely, even monetarily. Paying IaaS providers directly is not the way to do that.