![\"\"](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/88\/2018\/07\/27143101\/prague-1998-featured-1024x672.jpg\")
<\/h3>\n<\/h3>\nMe suelo hacer esta pregunta de vez en cuando. L\u00f3gicamente, la respuesta no es f\u00e1cil, ni lo ser\u00e1. La f\u00f3rmula para hacer todo lo posible y que te salga todo bien no es sencilla. Bueno, a menos que te toque la loter\u00eda o heredes un mill\u00f3n de repente. Pero ese no es mi caso. Nuestro \u00e9xito se atribuye a muchos factores, principalmente tecnol\u00f3gicos. Hoy voy a hablar de una de las claves: una tecnolog\u00eda fundamental que ha ayudado durante muchos a\u00f1os a desarrollar productos avanzados en todas las categor\u00edas que garantizan la m\u00e1xima protecci\u00f3n contra todas las ciberamenazas de malware<\/i> posibles.<\/p>\n
Esta tecnolog\u00eda se llama \u201cPraga\u201d (Prague, en ingl\u00e9s).<\/p>\n
\u00bfY por qu\u00e9? Pues es muy simple, se invent\u00f3 en Praga.<\/p>\n
De vuelta a la primavera de 1998, juntamos a un peque\u00f1o grupo para beber cerveza y comer unos dulces checos<\/s> elaborar una arquitectura para nuestros futuros productos. La reuni\u00f3n de Praga fue todo un \u00e9xito: producimos una nueva tecnolog\u00eda, Unified Component Architecture (UCA), que recoge una amplia variedad de productos de todas las plataformas posibles (sistemas operativos). UCA sigue evolucionando y es la base de casi todos nuestros productos.<\/p>\n
Adem\u00e1s, UCA tambi\u00e9n se ha utilizado en otras empresas que han sufrido problemas en desarrollos y proyectos \u201cmultiling\u00fce\u201d, lo cual sucede muy a menudo, sobre todo en proyectos complejos con muchos equipos involucrados o en empresas emergentes.<\/p>\n
Nuestra \u201creuni\u00f3n en Praga\u201d cumple 20 a\u00f1os, me di cuenta cuando indagu\u00e9 en los archivos y me encontr\u00e9 con \u201cDocumentaci\u00f3n Tecnolog\u00eda Praga\u201d, un documento con fecha del 22 de junio de 1998. Por aquel entonces nos preocup\u00e1bamos por luchar contra unos virus \u201cinnovadores\u201d y resolver problemas puramente t\u00e9cnicos con el motor antivirus. Pero la soluci\u00f3n que encontramos fue mucho m\u00e1s amplia, m\u00e1s potente y m\u00e1s \u00fatil. As\u00ed que Praga acab\u00f3 por determinar en muchos sentidos la base de la tecnolog\u00eda de nuestros productos de los siguientes 10 a\u00f1os.<\/p>\n
Entre la etapa en la que la compa\u00f1\u00eda se encontraba en el segundo piso de una guarder\u00eda en el distrito Strogino de Mosc\u00fa y la etapa en el edificio acristalado de oficinas<\/a>, concedimos la licencia de nuestro motor a un n\u00famero de socios extranjeros. Ya ten\u00edamos una versi\u00f3n exitosa en el mercado llamada Antiviral Toolkit Pro 3.0<\/em>. Sin embargo, el futuro tecnol\u00f3gico no pintaba tan bien.<\/p>\n Nos quedaban dos grandes desaf\u00edos que eran claramente necesarios y prometieron ser muy dif\u00edciles de implementar. El primero fue la habilidad de procesar objetos sospechosos independientemente de c\u00f3mo estuvieran almacenados (un ejemplo t\u00edpico es una \u201cmu\u00f1eca rusa\u201d de objetos incrustados, es decir, un archivo de malware<\/i> ejecutable dentro de un archivo que, a su vez, est\u00e1 dentro de otro). El segundo desaf\u00edo fue crear un motor antivirus que pudiera actualizarse lo m\u00e1s r\u00e1pido posible y que requiriera los m\u00ednimos cambios (a poder ser, cero) entre las diferentes plataformas.<\/p>\n Cabe recordar que los desarrolladores de virus a finales de los 90 eran muy ingeniosos y algunos virus totalmente nuevos requer\u00edan actualizar no solo las bases de datos, sino tambi\u00e9n el motor<\/em>. Los usuarios no ten\u00edan conexi\u00f3n a Internet o era muy lenta, as\u00ed que emitir una actualizaci\u00f3n de un par de megabytes era un serio problema. Dado que Windows 98 acababa de comenzar su andadura, pero no hab\u00eda remplazado todav\u00eda a DOS, cualquier innovaci\u00f3n en detecci\u00f3n deber\u00eda funcionar en ambos<\/em> sistemas operativos.<\/p>\n En general, ten\u00edamos mucho en lo que pensar cuando Alexey De-Monderik, Andrey Kryukov, Andrey Nikishin, Vadim Bogdanov, Larisa Gruzdeva y yo llegamos a Praga para buscar inspiraci\u00f3n y poner en com\u00fan todas nuestras ideas. Alquilamos una sala de conferencias en un hotel y cada d\u00eda de 9 a 5 debat\u00edamos y despu\u00e9s, nos \u00edbamos al restaurante y al sal\u00f3n de billar a probar la cerveza checa y a dejar que las ideas brotaran.<\/p>\n Trabajamos de forma productiva y volvimos a Mosc\u00fa con un concepto. De-Monderik anot\u00f3 todas nuestras ideas y este fue el documento que inspir\u00f3 esta publicaci\u00f3n:<\/p>\n Kryukov y Nikishin siguieron analizando Praga, pero en realidad no se cre\u00f3 hasta que en 1999 Andrey Doukhvalov se uni\u00f3 al equipo. Su experiencia en desarrollo de sistemas ayud\u00f3 a convertir el concepto Praga en algo m\u00e1s que un sistema de plugins<\/i> para un motor antivirus.<\/p>\n De hecho, Praga se convirti\u00f3 en un sistema modular independiente en el que los objetos se creaban y administraban despu\u00e9s de que se lanzara la aplicaci\u00f3n, tras observar la jerarqu\u00eda de objetos y habilitar el kernel<\/i> o n\u00facleo para funciones tales como memoria y gesti\u00f3n de mensajes. Toda la comunicaci\u00f3n con el sistema operativo y la interfaz de usuario se lleva a cabo mediante una capa fina y se ha podido escribir casi la totalidad del n\u00facleo del antivirus siguiendo los \u201cplugins<\/i> de Praga\u201d.<\/p>\n Doukhvalov desarroll\u00f3 la primera versi\u00f3n lista para usar para AVP 4.0. No estaba totalmente escrito al estilo de Praga, pero la fortaleza de su arquitectura ya se hac\u00eda evidente:<\/p>\n El uso de Praga nos situ\u00f3 a la vanguardia de la industria inform\u00e1tica, el enfoque modular para el desarrollo de software<\/i> no estaba tan avanzado por aquel entonces. Despu\u00e9s, registramos 4 patentes por Praga en Estados Unidos: 7386885<\/a>, 7730535<\/a>, 7418710<\/a>, 8234656<\/a>.<\/p>\n Praga tambi\u00e9n se pod\u00eda integrar f\u00e1cilmente con un c\u00f3digo escrito sobre diferentes principios. Por ello se integr\u00f3 inicialmente en la versi\u00f3n 4.0, pero solo para solucionar unos problemas. Fue tan eficiente, que cuando surgieron problemas importantes en el desarrollo de la versi\u00f3n 5.0, Doukhvalov tuvo la idea de generar una nueva versi\u00f3n basada en Praga y ello produjo el revolucionario Kaspersky Anti-Virus version 6, del que ya hemos hablado con detalle<\/a>.<\/p>\n Para desarrollar un \u201cplugin de antivirus\u201d en una estructura para crear todo un producto, algunas estrategias deben generalizarse y reinventarse. Las principales fuerzas impulsoras aqu\u00ed fueron Andrey Doukhvalov y Pavel Mezhuev, de no ser por ellos, Praga no hubiese sido apropiada para estas tareas tan complejas.<\/p>\n L\u00f3gicamente, nada es perfecto en el mundo de desarrollo y Praga cuenta con dos desventajas importantes.<\/p>\n En primer lugar, la depuraci\u00f3n no fue f\u00e1cil. Y, segundo, los desarrolladores tuvieron dificultar para adaptarla. Independientemente de c\u00f3mo se mire, era un sistema completamente nuevo, que impon\u00eda requisitos bastante estrictos sobre el dise\u00f1o del c\u00f3digo. Adem\u00e1s, los m\u00f3dulos inicialmente ten\u00edan que escribirse puramente en C. Este nuevo m\u00e9todo llev\u00f3 su tiempo, pues necesit\u00e1bamos cada vez m\u00e1s desarrolladores porque la compa\u00f1\u00eda estaba creciendo r\u00e1pidamente y nuestros productos se volv\u00edan cada vez m\u00e1s complejos.<\/p>\n De este modo, como sucede en toda la industria inform\u00e1tica, la velocidad se convierte en una prioridad y tenemos que cambiar de forma peri\u00f3dica a una estrategia de objeto m\u00e1s conocida y convencional. Sin embargo, los fragmentos basados en Praga siguen funcionando de forma satisfactoria en nuestros productos.<\/p>\n Por supuesto, en aquel entonces estos inconvenientes en realidad se basaban puramente en los procesos. Podr\u00edan y deber\u00edan resolverse porque los beneficios de implementar Praga fueron considerables y justificaron por completo todos los recursos empleados. Praga resolvi\u00f3 uno de los problemas m\u00e1s dif\u00edciles, costosos e importantes en los \u00faltimos 10 a\u00f1os, como la portabilidad de una tecnolog\u00eda (incluida la portabilidad binaria) a diferentes plataformas.<\/p>\n En vez de crear un nuevo producto desde cero para cada sistema operativo y procesador, utilizamos un motor depurado predefinido. Esta inversi\u00f3n en I + D a largo plazo no solo ha dado sus frutos, sino que mantiene nuestro liderazgo tecnol\u00f3gico hasta d\u00eda de hoy. Unified Component Architecture, sucesor de Praga, se est\u00e1 exprimiendo al m\u00e1ximo y todav\u00eda no hemos encontrado ning\u00fan problema que no pueda resolver. Esta es una prueba m\u00e1s de que una buena arquitectura puede superar d\u00e9cadas de pruebas.<\/p>\n![\"\"](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/88\/2018\/07\/27143325\/doc.gif\")
<\/p>\n\n