2011-03-11 19 views
9

Estoy buscando comenzar a desarrollar una aplicación web relativamente simple que extraerá datos de varias fuentes y la normalizará. Un usuario también puede ingresar los datos directamente en el sitio. Anticipo golpear la balanza, si tiene éxito. ¿Vale la pena dedicar tiempo ahora para usar tecnologías escalables o distribuidas o simplemente comenzar con una pila LAMP? Marco o no? Cualquier pensamiento, sugerencia o comentario ayudaría.¿Escala ahora o más tarde?

Sin tener en cuenta mi vaga descripción de la idea, me gustaría compartir una vez que vaya más lejos.

Respuesta

6

¿Vale la pena dedicar el tiempo ahora para usar tecnologías escalables o distribuidas o simplemente comenzar con una pila LAMP?

Una pila LAMP es escalable. Apache ofrece muchas, muchas alternativas.

¿Marco o no?

Utilice siempre el marco de mayor potencia que pueda encontrar. Escribe el menor código posible. Obtenga algo en frente de las personas tan pronto como pueda.

Enfóquese en lo importante: Obtenga algo para trabajar.

Si no tiene algo que funcione, la escalabilidad no importa, ¿verdad?

A continuación, lea sobre la optimización. http://c2.com/cgi/wiki?RulesOfOptimization es muy útil.

Regla 1. No.

Regla 2. Todavía no.

Regla 3. Perfil antes de optimizar.

Hasta que tenga una aplicación en funcionamiento, no sabrá qué es lo que específicamente limita su escalabilidad.

No asuma. Medida.

Eso significa construir algo que la gente realmente usa. La escala viene después.

+0

Sí, si se requieren medidas y perfiles, entonces la escala posterior tiene mucho sentido. De lo contrario, ¿con qué medirías? – Rimian

8

Más tarde. No recuerdo quién lo dijo (tal vez fue Jeff Atwood), pero suena a verdad: su primer problema es conseguir que otras personas se preocupen por su trabajo. Preocuparse por la escala cuando lo hacen.

Definitivamente vaya con un marco bien estructurado para su propia cordura. Incluso si no termina en miles de usuarios, querrá agregar características a medida que pase el tiempo. Mantener una base de código en expansión sin una buena estructura rápidamente se vuelve bastante horrible (estado allí, hecho eso, perdió al cliente).

Por cierto, si está tentado de escribir su propio marco, tenga en cuenta que es un lote de trabajo. Mi compañía tiene una en casa de la que estamos bastante orgullosos, pero nos tomó 3-4 años madurar.

+0

una cantidad preocupante de los proyectos que vi failing fracasado porque perdieron un tiempo precioso en la escala, y debido a eso ni siquiera entregaron. –

+0

Sí, esa es la dura realidad –

3

Absolutamente hágalo más tarde. Los dolores de escala es un buen problema, significa que a las personas les gusta su proyecto lo suficiente como para estresar el hardware en el que se está ejecutando.

La última compañía en la que trabajé comenzó bastante pequeña con PHP y las primeras versiones de CakePHP que aparecieron (cuando todavía estaba en beta). Parte del código estaba sucio, la herramienta de administración era un desastre (en cuanto al código), y seguro que se podría haber hecho mejor desde el principio. Pero, ¿sabes qué? Lo sacaron por la puerta antes que sus competidores, y se volvió extremadamente exitoso.

Cuando vine a bordo estaban empezando a golpear a los límites de su capacidad de ampliación potencial actual y que es cuando decidieron comenzar a mirar, técnicas lighttpd almacenamiento en caché, y otras formas de CDN para limpiar el código y hacer las cosas se ejecutan mejor cuando están bajo mucha carga. Ya no trabajo para ellos, pero fue una buena experiencia en el crecimiento de una arquitectura más allá de lo que originalmente se consideraba.

Puedo decirle ahora mismo si han tratado de hacer la escalabilidad y optimizaciones antes de vender contenido y obtener un sitio web en vivo; nunca habrían alcanzado el tamaño que tienen ahora. La compañía es www.beatport.com si le interesa a quién me refiero (para reiterar, no estoy tratando de publicitarlos porque ya no estoy afiliado a ellos, pero es un buen caso). estudiar y es más fácil para las personas entender de lo que estoy hablando cuando ven su sitio web).

Personalmente, después de trabajar con Ruby and Rails (y entender la separación) durante un par de años, y tener experiencia con PHP en Beatport, puedo decir con confianza que no quiero volver a trabajar con código PHP = p

0

Estoy de acuerdo con los encuestados anteriores, lo hago útil, lo hago funcionar y motivar a las personas para usarlo primero. También estoy de acuerdo en que debe elegir los componentes listos para usar (de los cuales hay muchos) en lugar de enrollar los suyos, tanto como sea posible. Al mismo tiempo, asegúrese de elegir los componentes de su infraestructura que sepa que son escalables para que pueda ir allí cuando lo necesite, sin tener que volver a escribir fragmentos importantes de su aplicación.

Como Product Manager para Berkeley DB, he visto casos de condesa de desarrolladores que decidieron "Oh, simplemente escribiremos eso en un archivo plano" o "Puedo escribir mi propia función simple de B-tree" o " La base de datos XYZ es 'suficientemente buena', no tengo que preocuparme por la concurrencia o la escalabilidad hasta más adelante ". El problema con este enfoque es que a) estás reinventando la rueda (y renunciando a lo que otros ya aprendieron por las malas) yb) estás ignorando el hecho de que tendrás que lidiar con la escalabilidad en algún momento e ir con una solución 'lo suficientemente buena'.

Buena suerte en su implementación.

1

Es curioso preguntar "scale now or later?" y etiquetarlo como "ruby on rails". En realidad, Ruby on Rails fue creada por David Heinemeier Hansson, que tiene un capítulo entero en su libro llamado "Escala tarde" :)) http://gettingreal.37signals.com/ch04_Scale_Later.php

Cuestiones relacionadas