NYCPHP Meetup

[Hans Z]

> > Just handle process priority, memory management, and open some
> > sockets when asked. For the rest... stay out of the way. For god's
> > sake don't try to maintain a "system" java that symlinks to the
> > flavor of the month. Don't provide shared libraries. Don't provide
> > printing services. Don't even install cron.
> >
> > Yes, I would use your distro. I might install cron, but I get to
> > choose which one.
> >
> > Seriously, Hans, maybe your client wanted to use Ubuntu Server
> > because of the GUI, but you should know better than to have a window
> > manager running on a production server. I suppose you'd let the OS
> > automount any USB keys that were stuck into the front ports, too?
> >
> > Easy there Chris, didn't realize Ubuntu was your project...
> >
> > Obviously I can customize my OS how I'd like... and I'm sure Ubuntu
> > would be just as happy to mount a USB stick and scan it for MP3s
> > while giving me Amazon ads... and we can all choose which OS/flavor
> > we use... and I'm simply stating, that Ubuntu will never be my choice.
> >
> > H
>
> Sorry for mangling the history with my mail client.
>
> Chris, Hans, I never made the leap myself, but isn't much of this why you
> two advocate/d the BSDs for AMP development? What's the reason for either
> of you considering Ubuntu/CentOS today?


I've always liked CentOS/RedHat and honestly FreeBSD started getting
strange.  BSD's were always generally a bit behind with certain libraries
and incompatibilities, but after FreeBSD 4 and into 5, etc., things just
seemed to get ever more broken.

And now it's just not offered and there's no compelling reason to request
it.  Amazon's CentOS flavor is pretty well done and minimal, and for
instances I need to install my own, I have a 700mb server image ready to go.

At the end of the day, though, there's really only one reason though: Cloud
killed the BSD star...

As consultants, I understand you have to deal with some legacy client
> infrastructure and may not be able to define the "ideal OS" but what would
> you use if you had it your way?
>

CentOS
Windows Server
Anything else

I have an increasing number of clients using the WISP stack, which actually
works quite nicely.


> And I don't mean to start a religious war, but if you were to set up a
> server only cluster of VMs to serve up your own production PHP apps, what
> would you choose today and why?


Today:  EC2 and Azure (maybe)

Tomorrow: GAE PHP

I've been playing with GAE PHP and it's nice... it's nascent and needs some
maturing, but it's clearly the way forward.  The biggest challenge that I
see for "legacy" apps is the classic PHP extension rot problem, i.e., XYZ
isn't available.  But for newer applications, that aren't quite as
extension promiscuous, it's going to be great.

How much do you really care to influence what choices are made at the OS or
> PHP version level? What are the make/break configurations you absolutely
> must have control over?
>

If it's an existing stack, I'll basically support anything.  If I'm
building from the ground up, it's barebones CentOS, compiled PHP/etc.
I've even documented it: http://www.framewire.org/stacks

I guess I really should run a poll for this, but for others on the list,
> where do you fit into the the following spectrum?
>
> 1. I fully control hardware (virtualize yourself, if needed) and
> build/package install AMP yourself.
> 2. I select an OS image on a cloud IaaS (EC2, etc) and build/package
> install AMP yourself.
>

I'm here...


> 3. I use choose a pre-built AMP stack image on an IaaS.
> 4. I use Zend phpcloud or one of the production PaaSes for it (IBM,
> RightScale, etc), or another PaaS like Azure, Heroku, Cloud Foundry, etc
> 5. I go with a SaaS (WordPress, SugarCRM, Drupal) provider and customize
> that.
>

...and look forward to being here in a few months with GAE PHP.


Cloud computing:  first the network didn't matter; then the server
hardware; now the OS; and soon the application

H
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20130718/6dd27ba7/attachment.html>