Ma voiture préférée est toujours ma deuxième voiture après l'université, une 2001 jaune vif Ford Focus ZX3 . La raison est simple: c'était la voiture minimale absolue requise pour mes besoins.
Les manivelles manuelles servaient à la fois à ouvrir les vitres et comme seule méthode de climatisation dans la voiture et la transmission manuelle me permettait d'avoir un contrôle fin sur la façon dont le faible couple du moteur était appliqué aux roues.
vous avez vraiment besoin d'un F-150?
Récemment, j'ai republié un article vers 2015 sur un script que j'utilise presque quotidiennement pour gérer simultanément plusieurs installations AEM . J'ai reçu plusieurs réponses sur différentes plates-formes à l'effet de «c'est 2020, utilisez Docker»
Utiliser Docker pour gérer le développement local d'AEM, c'est comme utiliser un F-150 pour faire les courses. Bien sûr, vous pouvez jeter un nombre infini de sacs à l'arrière de la cabine, mais avez-vous besoin d'un camion léger pour transporter 50 livres d'épicerie?
Nous pouvons appliquer cette même logique à de nombreuses tendances différentes dans l'industrie:
- Vos utilisateurs bénéficient-ils de la mise en œuvre de votre site de marketing en tant que SPA?
- Vos auteurs de contenu aiment-ils publier des pages Web standard via un sans-tête
- La conversion de votre service étroitement intégré en un réseau de microservices facilite-t-elle la compréhension et la gestion?
L'une des expériences les plus mémorables du canard en caoutchouc, alors que mon Focus était affectueusement baptisé, se glissait sur un gel viaduc dans une tempête de neige près du sud du centre-ville de Chicago. Je me suis glissé devant les VUS filés en troisième vitesse, fournissant soigneusement juste assez de gaz pour remonter l'inclinaison sans tourner moi-même. D'après le peu de trafic sur le péage de Gary, j'étais l'une des rares personnes à pouvoir sortir de Chicago ce soir-là.
Toutes les abstractions et fonctionnalités ont coûté, qu'il s'agisse d'une transmission automatique ou d'un hyperviseur. Prendre l'option la plus simple par rapport au mot à la mode plus complexe est généralement le meilleur choix, du moins, jusqu'à ce que vous puissiez prouver que vous avez besoin d'une solution plus complexe.
Quand une mise au point ne suffit pas
Alors que ma Ford Focus était la meilleure voiture pour me transporter en ville, il y avait des lacunes évidentes pour certaines activités. Je pouvais laisser tomber l'embrayage et obtenir 0-35 à la hâte, mais arriver à la vitesse sur route était comme amadouer un adolescent réticent pour se préparer pour l'école. Et bien que le hayon puisse contenir plus que ce à quoi on pourrait raisonnablement s'attendre, déménager, travailler dans le jardin ou transporter plus de deux adultes était une affaire exiguë.
Savoir quand remplacer votre solution aussi simple que possible pour une solution plus complexe nécessite un une évaluation claire des besoins actuels et de ce qu'ils seront dans un avenir proche. Une projection trop éloignée se termine généralement par une surestimation de vos besoins futurs et de la complexité requise. Au lieu de supposer que votre application deviendra le prochain Netflix ou Amazon, pensez plutôt à ce dont elle aura besoin si la croissance double au cours de la prochaine année?
Une fois que vous avez les besoins, équilibrez cela par rapport au coût de la solution plus complexe, encore une fois être réaliste. Est-ce que quelque chose d'aussi complexe que Kubernetes «fonctionne tout simplement» sans aucun soin ni alimentation? Souvent, vous pouvez constater qu'une solution trop simple fonctionnera beaucoup plus longtemps et à moindre coût qu'une solution plus complexe.
Il existe bien sûr des solutions qui, en raison de leur nature, nécessitent de la complexité. Une application bancaire ou un portail client devrait probablement être une application à page unique, tout comme tirer parti d'Adobe I / O ou d'Amazon Lambda pour microservices peut vous permettre d'éviter de créer des serveurs ou d'exécuter du code sans rapport sur AEM, mais vous devrez travailler très dur pour montrer que votre site Web de marketing a besoin d'un déploiement d'OpenShift.
La «bonne» architecture
L'une des choses les plus difficiles à saisir en architecture est de saisir l'importance du contexte pour définir la bonne architecture. En tant qu'êtres humains, nous avons tendance à trouver des similitudes entre les situations et à utiliser des modèles comme raccourci mental.
La partie la plus importante de l'identification de l'architecture correcte consiste à aborder le contexte actuel sans parti pris et à choisir la solution la plus simple qui répond au besoin.
Source link