dvrom.eu

Arquitectura, disseny orientat a objecte, posada al punt del cicle de build-test-release, configuració d’eines i entorn, programar…etc…

Aquestes són només algunes de les coses que em porten de volta a l’enginyeria de software el juny, en la meva nova empresa.

Em considero molt afortunat d’haver treballat l’últim any i mig amb alguns experts tècnics i funcionals excepcionals, com a Consultor Tècnic en un líder mundial de software de banca privada, en una de les capitals de banca a Europa.

El poder captar alguna cosa del coneixement dels veterans que porten anys a les trinxeres, m’ha donat un bon enteniment de com funcionen les coses al món de la banca privada i comercial.

He de dir tanmateix, que el pas d’entusiasta del codi i del desenvolupament a evangelista tècnic i funcional d’un producte específic, ha estat una experiència reveladora.

Com a desenvolupador, jo sempre havia vist els consultors amb qui havia treballat amb ull escèptic i dilbertesc: la roba amb estil, els cotxes bonics i els hotels cars ja creava una distància important, fins i tot abans de començar a treballar junts.

Hi ha moltes històries sobre la mística del Consultor que apareix com un Messies per salvar les ànimes del projecte condemnat: ja sigui la xerrameca màgica, els coneixements sagrats específics de producte, o el fet de simplement assenyalar l’obvi, la seva presència és gairebé sempre misteriosa i etèria.

L’aura misteriosa que envolta els consultors tendeix a exagerar els seus resultats: els bons consultors seran recordats com a eficients mags resol-problemes, mentre que d’altres seran recordats com aquest estrany home que ningú no coneixia i que es passejava per allà tot el dia.

Fa algun temps, sent desenvolupador, vaig haver de domar una certa bèstia, i sovint em sentia frustrat quan un dels consultors de la bèstia no era capaç de respondre a algunes de les meves preguntes.

Després d’estar en l’altre costat, ara veig que probablement la virtut més important d’un consultor d’un determinat producte no és el que ell / ella sap, sinó el que ell / ella pot esbrinar: el consultor serà probablement el teu millor enllaç amb els desenvolupadors que es troben darrere del producte, i la clau per al coneixement que busques.

Així que la pròxima vegada que estiguis cara a cara amb un d’aquests misteriosos consultors de producte, recorda controlar la teva frustració si les teves preguntes no són contestades al moment, i sigues pacient perquè la informació sigui recollida pel teu únic vincle amb el nucli del producte…

Un dels primers projectes en el qual vaig treballar ha sigut substituït i està ara allà a on sigui que va el codi mort…

Quan miro enrere ara, aquest CMS tan senzill és un dels projectes amb més èxit en el què he participat fins ara, en termes de longevitat (va estar en producció durant els últims 5 anys) i feedback dels usuaris.

També és probablement la solució més simple en la que he treballat (sense processos de desenvolupament complicats, sense codi intel·ligent, abús de patrons…) i em recorda una cita que vaig llegir en algun lloc que ja no recordo, que deia més o menys:

Jo probablement reformularia aquesta afirmació en:

En el mateix sentit, també diria que:

La meva ràpida exposició en els projectes que van seguir a aquest senzill gestor de continguts al gran món de J2EE, frameworks ORM, patrons de disseny, a l’API Java, frameworks Web i altres candidats per a abús, combinat amb la meva mentalitat prepotent de “Puc amb tot! ” de principiant, va portar cap a algun que un altre codi horrible i a alguns sobredimensionats terribles…

No sol la saviesa, sinó també la ignorància, de vegades pot produir els millors resultats…

Proves d’estrès, proves de càrrega, proves de rendiment, proves de capacitat…totes elles es basen en la mateixa idea:

• Els sistemes de programari són construïts normalment per ser utilitzats, i és probable que, en un moment o un altre, es vulgui saber com reacciona el sistema davant d’una gran carga, i, en cas que els resultats no siguin satisfactoris, es voldrà millorar el rendiment del sistema.

Una primera qüestió que es planteja:

Les proves de càrrega s’han de realitzar en alguna fase específica o s’han de realitzar a causa d’algun requisit específic?

La combinació de Tomcat, Apache i mod_jk pot ser una bona opció per a una solució escalable i robusta per a aplicacions web basades en JSPs / Servlets.

Escalabilitat i tolerància a caigudes de sessió HTTP es poden aconseguir d’una manera senzilla amb un contenidor lleuger de servlets com Tomcat, que ofereix funcionalitats de grup (clúster).

El Balanceig de càrrega s’aconsegueix mitjançant el mòdul mod_jk Apache, que distribueix les peticions HTTP amb un simple mecanisme round robin a través del protocol AJP.

(mod_jk sembla ser el millor i més estès connector Tomcat - Apache)

A fi d’oferir una tolerància a fallades de la sessió HTTP (evitar la pèrdua de la sessió HTTP en cas de caiguda de la instància de Tomcat on es va crear la sessió), la replicació de sessions pot ser utilitzada.

Tomcat pot compartir sessions a través d’una base de dades, un arxiu o en memòria.

L’arquitectura global es podria resumir de la forma següent:

Tomcat utilitza un mecanisme molt simple d’agrupació (clustering):

L’agrupació de membres s’estableix utilitzant pings multicast. Una vegada que un ping multicast és rebut, el membre és agregat a l’agrupació. Quan es produeix la pròxima sol•licitud de replicació, la instància que va enviar la petició utilitzarà la informació de host i port per establir un socket TCP. Les dades de sessió són llavors serialitzades i enviades a través del socket.

És possible establir un primer punt de partida per a aquesta arquitectura de forma ràpida i senzilla, com es mostra a continuació, usant el servidor HTTP Apache 2.2.11, el mòdul mod_jk 1.2.28, Apache Tomcat 6.0.18 i Mac OS X 10.5 .6 (Darwin 9.6.0).

En aquest exemple, un Servidor Apache HTTP aplicarà un balanceig de càrrega entre dues instàncies de Tomcat, a través del mòdul mod_jk.