Je cherche à commencer à développer une application Web relativement simple qui tirera des données de différentes sources et de le normaliser. Un utilisateur peut également entrer les données directement sur le site. Je prévois de frapper l'échelle, en cas de succès. Cela vaut-il la peine d'être mis à l'époque pour utiliser des technologies évolutives ou distribuées ou simplement commencer par une pile de lampe? Cadre ou pas? Toute pensée, suggestions ou commentaires aiderait.
Ne pas tenir compte de ma vague description de l'idée, j'aimerais partager une fois que je suis plus loin.
5 Réponses :
plus tard. Je ne me souviens pas qui l'a dit (aurait pu être jeff à Jeff Atwood) mais ça sonne la vraie: votre premier problème consiste à obtenir d'autres personnes à se soucier de votre travail. S'inquiéter de l'échelle quand ils le font.
Allez certainement avec un cadre bien structuré pour votre propre santé mentale. Même si cela ne finit pas avec des milliers d'utilisateurs, vous voudrez ajouter des fonctionnalités au fil du temps. Maintenir une base de code en expansion sans une bonne structure devient rapidement horrible (y a été là, fait cela, perdu le client).
BTW, si vous êtes tenté d'écrire votre propre cadre, sachez que c'est un lot du travail. Mon entreprise a une maison en interne, nous sommes très fiers, mais il est pris entre 3 et 4 ans à maturité.
Une quantité dérisamment des projets que j'ai vu échouer a échoué parce qu'ils ont perdu du temps précieux sur la mise à l'échelle et, à cause de cela, ils n'ont même pas livré.
Oui, c'est la rude la réalité
vaut-il la peine d'être mis à l'époque pour utiliser des technologies évolutives ou distribuées ou simplement commencer par une pile de lampe?
Une pile de lampe est évolutive. Apache fournit de nombreuses alternatives.
Cadre ou non?
Utilisez toujours le cadre optimal que vous pouvez trouver. Écrivez aussi peu de code que possible. Obtenez quelque chose devant les gens dès que vous le pouvez.
Concentrez-vous sur ce qui est important: Obtenez quelque chose à travailler.
Si vous n'avez pas quelque chose qui fonctionne, l'évolutivité n'a pas d'importance, n'est-ce pas?
puis lisez sur l'optimisation. http://c2.com/cgi/wiki?rulesOfoptimation est très utile.
règle 1. Ne le faites pas.
règle 2. N'as pas encore.
règle 3. Profil avant d'optimiser.
jusqu'à ce que vous ayez une application de travail, vous ne savez pas quelle spécificité - chose limite votre évolutivité.
Ne supposez pas. Mesure.
Cela signifie construire quelque chose que les gens utilisent réellement. L'échelle vient plus tard.
Oui, si la mesure et le profilage sont nécessaires, la mise à l'échelle plus tard a du sens complet. Sinon, que mesureriez-vous?
Absolument le faire plus tard. Les douleurs à la mise à l'échelle sont un problème La dernière entreprise que j'ai travaillé au démarrage assez petit avec PHP et les toutes premières versions de CakePHP qui sont sorties (quand elle était toujours en version bêta). Une partie du code était sale, l'outil d'administration était un désordre (codant-wise) et sûr qu'il aurait pu être fait mieux dès le début. Mais tu sais quoi? Ils ont eu la porte avant que leurs concurrents ne réussissaient et devenaient extrêmement réussi.
Quand je suis arrivé à bord, ils commençaient à frapper les limites de leur évolutivité potentielle actuelle, et que est quand ils ont décidé de commencer à consulter les techniques de cache de CDN, LightPD et d'autres moyens de nettoyer le code et rendre les choses à courir plus lisse lorsque sous une charge importante. Je ne travaille plus pour eux, mais c'était une bonne expérience dans la croissance d'une architecture au-delà de ce qu'elle était originale à l'origine.
Je peux vous dire maintenant s'ils avaient essayé de faire l'évolutivité et les optimisations avant de vendre du contenu et d'obtenir un site Web en direct - ils n'auraient jamais grandi à la taille qu'ils sont maintenant. La société est www.beatport.com si vous êtes intéressé par qui je parle de savoir qui je parle (à ré-itérer, je n'essaie pas de les faire annoncer car je ne suis plus affilié à eux, mais cela est un bon cas étudier et il est plus facile pour les gens de comprendre ce dont je parle quand ils voient leur site Web).
Personnellement, après avoir travaillé avec Ruby et Rails (et comprendre la séparation!) Depuis quelques années et avoir de l'expérience avec PHP à Beatport - Je peux dire avec confiance que je ne veux plus jamais travailler avec PHP Code = P
Je suis d'accord avec les répondants antérieurs - faites-la utile, faites-le fonctionner et que les gens motivent pour l'utiliser en premier. Je conviens également que vous devriez choisir les composants de l'étagère (dont il y en a beaucoup) plutôt que de rouler le vôtre, autant que possible. Dans le même temps, assurez-vous de choisir des composants pour votre infrastructure que vous savez être évolutifs afin que vous puissiez y aller lorsque vous devez, sans avoir à ré-écrire des morceaux importants de votre application.
comme gestionnaire de produit pour Berkeley DB , j'ai vu des cas de comtesse de développeurs qui ont décidé "Oh, nous Il suffit d'écrire cela dans un fichier plat "ou" Je peux écrire ma propre fonction simple arborese "ou" la base de données XYZ est "assez bonne", je n'ai pas à vous soucier de la concurrence ou de l'évolutivité tant que la plus tard ". Le problème avec cette approche est que A) Vous réinventez la roue (et dans ce que les autres ont appris le dur déjà) et b) vous ignorez le fait que vous devrez faire face à une évolutivité à un moment donné. et aller avec une solution «assez bonne».
bonne chance dans votre mise en œuvre.
drôle de demander "balance maintenant ou plus tard?" et étiquetez-le "rubis sur rails". En fait, Ruby On Rails a été créé par David Heinemeier Hansson, qui a tout un chapitre de son livre étiqueté "Balance plus tard" :)) http://gettingheal.37signals.com/ch04_scale_later.php