Coding computer

Desarrollo In-house vs. Outsourcing

A la hora de desarrollar el software que tu empresa necesita, ¿es mejor hacerlo internamente o bien confiar este trabajo a una empresa externa? No es una cuestión con una respuesta sencilla.

Deloitte’s Global Outsourcing Survey

Para empezar a debatir sobre este tema nos ha parecido muy interesante consultar los resultados obtenidos en la Deloitte’s 2016 Global Outsourcing Survey (en verano de 2018 publicarán su nueva versión, estaremos atentos para actualizaros esta entrada o crear una nueva).

Algunos puntos especialmente destacables:

  • El 78% de los encuestados está satisfecho con su relación de outsourcing.
  • El 72% de las tareas relacionadas con TI ya se está subcontratando. Es el área con mayor ratio de outsourcing dentro de las compañías.
  • Los principales motivos para subcontratar: reducción de costes, enfocarse en el negocio en sí y en alcanzar los objetivos de la empresa, resolver problemas temporales de capacidad.
  • Los principales problemas: proveedores poco proactivos o que no innovan suficientemente.
  • En su comparativa con los datos anteriores de 2014: las compañías encuentran menos problemas con los proveedores y la subcontratación crece en todas las áreas.

Outsourcing y Cloud Computing

Nos ha llamado también la atención que en esta encuesta se haya preguntado sobre cómo está afectando Cloud Computing (aquí nuestra última entrada sobre este tema) sobre las relaciones de subcontratación. El 61% considera que están disminuyendo los costes asociados a las entregas, el 45% que acelera los cambios, el 30% las implementaciones y el 21% que potencia la innovación.

Ventajas e inconvenientes

Cada una de las dos opciones presenta sus propias ventajas e inconvenientes.

Tener a tu propio departamento de desarrollo te asegura disponer de un equipo con un mayor conocimiento sobre el negocio, alineado con los objetivos finales de la empresa, entrenado justo para lo que se necesita. Problemas, quizás el principal sea el de conseguir contratar a los perfiles necesarios y todo lo que este proceso implica: costes del anuncio, dificultades para localizar al perfil requerido (donde además consumiremos muchísimo tiempo propio) y finalmente formarlo. Otro problema bastante importante: ¿cómo reaccionamos correctamente a los cambios de carga de trabajo?

Subcontratar los desarrollos a priori acaba abaratando costes, obviamente te permite enfocarte más en tu negocio y reaccionar mucho mejor a los subidas y bajadas de trabajo (ganas en flexibilidad). Inconvenientes: la pérdida del control directo, problemas en la comunicación con el proveedor (especialmente si hay una distancia considerable entre ambos, física o culturalmente por ejemplo), resultados inesperados si los requerimientos no están suficientemente cerrados, problemas con la priorización del proveedor (si dispone de muchos clientes de tu perfil).

Conclusiones

Como adelantábamos no es una pregunta con una conclusión clara.

Entendemos que la decisión dependerá en gran medida de la visión y estrategia de la propia empresa. Deberán sopesarse los pros y contras de cada opción. La clave si subcontratamos: acertar con los proveedores seleccionados.

¿Cloud va a ayudar a mejorar y aumentar los servicios de outsourcing? Estaremos atentos.

 

AWS Summit Madrid

El pasado 17 de mayo acudimos al AWS Summit 2018 Madrid donde pudimos disfrutar de la Keynote impartida por Werner Vogels (CTO de Amazon.com), Miguel Alava (Director de AWS EMEA) o Chema Alonso (CDO de Telefónica) entre otros, además de multitud de sesiones adicionales sobre cómo iniciarse en AWS, tecnología serverless o inteligencia artificial por ejemplo.

Tras una jornada más que atractiva, salimos de allí con algunas sensaciones interesantes.

Cloud está de moda

Cloud está pegando fuerte y parece que ha llegado para quedarse (al menos para los próximos años). Aparentemente las compañías más importantes del mundo, y las españolas cada vez más, están migrando ya sus desarrollos y productos a Cloud y, las que todavía no lo han hecho, o han iniciado el camino o deberían al menos planteárselo en breve.

Según la Cloud Comparison Guide (actualizada en 2018), AWS y Azure siguen a la cabeza en Cloud, dejando a mucha distancia a Google y todavía más al resto de compañías. De este estudio nos fijamos en otro detalle interesante: Cloud Computing aparece como la segunda tendencia tecnológica más importante para los los próximos 3 años, sólo por detrás de Big Data, pero por delante del Internet of Things, la inteligencia artificial, la realidad virtual o la robótica por ejemplo.

Tecnología serverless

De entre todos los servicios que ofrece Cloud, los relacionados con tecnología serverless están experimentando un auge total. 3 de las 5 sesiones que se impartieron en el pabellón principal del Summit (con varios cientos de oyentes en cada una de ellas) trataron sobre temas relacionados con esta tecnología.

Serverless ocupó incluso los últimos minutos de la conferencia de Werner Vogels, en los que enfatizó sobre sus bondades (mejora en la productividad de los programadores, eliminación de la gestión de infraestructura, foco en la lógica de negocio…) e incluso declaró que es el futuro de la programación. Todavía no disponemos de imágenes oficiales sobre el Summit de Madrid, pero sí sobre el de Londres (impartido una semana antes) y es interesante ver estos minutos finales  con su opinión sobre la evolución natural que deberían seguir los desarrollos desde Server (Virtual Machines), a Containers para llegar finalmente a Serverless.

Serverless application architectures on AWS
Serverless application architectures on AWS

Bases de datos

Nos parecieron interesantes también los servicios que ofrece AWS relacionados con bases de datos. En especial su nuevo producto Amazon Aurora que se ha convertido en el servicio AWS que más ha crecido en menor tiempo (en toda su historia). Parece que ofrecen también un servicio (AWS Database Migration Service) para migrar tus antiguas bases de datos a cualquiera de los servicios de datos que ofrece Amazon. Un asistente migra automáticamente todo lo posible y sugiere soluciones guiadas para aquellos pasos que no se consiguen completar 100% automáticamente (básicamente los relacionados con PL/SQL). Habrá que probarlo…

¿Conclusiones?

Que cloud está en auge e irá todavía a más. Y, definitivamente, volvimos con la motivación de seguir trabajando e investigando sobre esta tecnología.

Edición 25/06/2018

Vemos que AWS ya ha publicado en su canal de Youtube los vídeos oficiales sobre el Summit. Aquí el Keynote. Hay otros vídeos interesantes del evento en su canal. Por ejemplo Mejores prácticas y patrones de arquitectura en Serverless o Primeros pasos en AWS.

imagen patrones

Patrones de diseño

A veces, en nuestro día a día, nos enfrentamos a problemas que ya han sido resueltos por otros desarrolladores, por este motivo hoy vamos a hablar un poco sobre los patrones de diseño ya que estos nos ayudarán a solucionar problemas comunes de la mejor forma posible. ¡Vamos a ello!

¿Qué son los patrones de diseño?

Un patrón de diseño es una solución general y reutilizable para problemas típicos y recurrentes en el desarrollo de software. Éstos, dado un contexto similar, nos aportan una solución ya probada y documentada.

El concepto de patrón de diseño se empezó a utilizar a finales de los 70 por el arquitecto Christopher Alexander, aún así, no fue hasta principios de los 90 cuando los patrones de diseño se popularizaron gracias al libro Design Patterns escrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que se recogían 23 patrones de diseño comunes.

Ahora que sabemos un poco qué son los patrones de diseño y de dónde salen vamos a lo que nos interesa, ¿por qué deberíamos utilizarlos?

¿Por qué son útiles los patrones de diseño?

Los patrones de diseño nos ayudan a desarrollar aplicaciones más robustas y mantenibles. Esto es debido a que establece un lenguaje común entre el equipo de desarrollo, los patrones de diseño están ampliamente documentados y testados y ayudarán a todo el equipo a comprender lo que has implementado, cómo y por qué. Además los patrones son reutilizables ya que se amoldan a distintos problemas (con un contexto similar).

Debido a estos motivos, los patrones nos ahorrarán tiempo al tener el código bien estructurado permitiendo a cualquier desarrollador, incluso a los nuevos desarrolladores, realizar cambios sobre nuestra implementación sin tener que romperse la cabeza en el proceso.

Como hemos dicho anteriormente, utilizar patrones también nos asegurará la validez de nuestro código (si hemos utilizado el patrón adecuado para el problema) ya que los patrones de diseño son estructuras probadas por millones de desarrolladores durante muchos años.

Tipos de patrones de diseño

En la actualidad existen muchos patrones de diseño, por este motivo suelen agruparse según su propósito: patrones creacionales, patrones estructurales y patrones de comportamiento. Vamos a ver un poco en detalle para que se utilizan cada uno de estos tipos y algunos ejemplos de cada uno (vamos a explicar algunos de ellos brevemente).

Patrones creacionales

Los patrones creacionales sirven para solucionar problemas derivados de la creación de nuevos objetos. Estos patrones nos ayudan a encapsular y abstraer dicha creación. Los patrones creacionales más conocidos son los siguientes:

  • Abstract Factory
  • Factory Method
  • Builder
  • Singleton: Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia. Solo puede instanciarse la clase a un único objeto.
  • Prototype: Crea una nueva instancia clonando un objeto ya existente.
  • Lazy initialization: Instancia el objeto solo cuando vamos a utilizarlo.

Patrones estructurales

Son patrones que nos ayudan a modelar nuestra aplicación especificando la forma en la que unas clases se relacionan con otras. Algunos de los patrones estructurales son los siguientes:

  • Adapter o Wrapper: Permite a dos clases con diferentes interfaces comunicarse entre ellas utilizando un objeto intermedio.
  • Bridge: Desacopla una abstracción de su implementación.
  • Composite
  • Decorator: Permite añadir funcionalidad extra a un objeto (de forma dinámica o estática).
  • Facade: Una facade (o fachada) es un objeto que crea una interfaz simplificada para tratar con otra parte del código más compleja, de tal forma que simplifica y aísla su uso. Por ejemplo podríamos utilizar una facade para acceder a la funcionalidad de un sistema externo.
  • Flyweight
  • Proxy
  • Módulo: Agrupa varios elementos relacionados en una entidad única.

Patrones de comportamiento

Para terminar tenemos los patrones de comportamiento, estos se encargan de gestionar los algoritmos encapsulados por las clases y las relaciones y responsabilidades entre objetos. Tenemos los siguiente patrones:

  • Chain of responsibility: Establece la línea de mensajes a seguir para realizar la tarea indicada.
  • Command: Son objetos que encapsulan una acción, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
  • Interpreter
  • Iterator: Nos permite recorrer un conjunto de forma secuencial sin necesidad de conocer su implementación.
  • Mediator: Objeto encargado de coordinar la comunicación entre objetos de distintas clases.
  • Memento: Este patrón permite volver a estados anteriores del sistema.
  • Observer: Define una relación uno a muchos entre objetos y, cuando este es modificado, notifica a todos los objetos que dependen de él para realizar una acción determinada.
  • State: Permite la modificación de su comportamiento en función de un estado interno.
  • Strategy: Dispone de varias soluciones para un problema y decide cual de ellas es mejor en tiempo de ejecución.
  • Template Method: Define el esqueleto de un algoritmo, permitiendo a las subclases definir cómo implementan algunas partes.
  • Visitor

Conclusión

Como veis existen muchos patrones (y faltan bastantes en esta lista) que nos dan solución a una serie de problemas comunes, aunque es complicado conocerlos y entenderlos todos, es útil conocer su existencia y revisarlos cuando nos enfrentamos a algún tipo de problema para ver si algún patrón de diseño existente se amolda a nuestro problema. Como podéis imaginar, la máxima dificultad radica en identificar cuándo debemos utilizar uno de ellos, algo que la práctica nos ayudará a conseguir.

Aún así vale la pena esforzarse en utilizarlos ya que las ventajas al hacerlo son muchas como ya hemos explicado anteriormente. Eso si, cuidado al utilizar patrones de forma indiscriminada, utilizar patrones donde no toca puede ser igual de malo (o incluso peor) que la falta de ellos.