Skip to main content

Home/ Arquitectura?/ Group items tagged management

Rss Feed Group items tagged

Pablo Lalloni

Return of the Borg: How Twitter Rebuilt Google's Secret Weapon | Wired Enterprise | Wir... - 0 views

  •  
    Importantísimo de ver... sobre todo para diferenciar bien entre un simple publicador de recursos, estilo openshift, de un verdadero administrador de recursos distribuidos (léase scheduler), como mesos.
Chancha Mazzoni

Create, manage and run clusters of Docker containers using Node.js | decking.io - 0 views

shared by Chancha Mazzoni on 05 Sep 14 - No Cached
  •  
    Decking aims to simplify the creation, organsation and running of clusters of Docker containers in a way which is familiar to developers; by reading information from a decking.json package file on a project by project basis. You can view a showterm recording of decking in action or check out a simple example project.
Pablo Lalloni

An Introduction to Kubernetes | DigitalOcean - 4 views

  •  
    Una buena introducción general a Kubernetes, útil para comprender componentes y responsabilidades.
munyeco

The Twelve-Factor App - 2 views

shared by munyeco on 20 Jul 14 - No Cached
  • The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
  •  
    "Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc). Background The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform. This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and avoiding the cost of software erosion. Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books Patterns of Enterprise Application Architecture and Refactoring. Who should
  •  
    Bueno. Eso. Compartí el que me di cuenta que puso antes Pablo en vez del original por error, pero la idea entre ambos, si la obviedad es tolerable, es idéntica :) Está muy bien estructurado en cuanto que cada factor depende de los demás a la vez que los promueve. Permite un enfoque general que incluye prácticas de arquitectura - y de armado cotidiano de productos - que posibilitan llegar donde yo entiendo - según me voy enterando - que es el lugar a donde llegar. Sin embargo, creo que ni éste departamento en sus sistemas más nuevos cumple todos y cada uno de aquellos factores. Esto, lejos de ser una crítica, es una invitación para que revisemos si es el único método posible - cosa improbabilísima - o el mejor método - también bastante improblable - a seguir. Lo que sí sostengo como un absoluto - quien no lo haría - es que es un método practicable. Mi aporte mínimo es defenderlo como uno bueno.
Pablo Lalloni

densh/scala-offheap - 0 views

  •  
    "Type-safe off-heap memory for Scala."
Pablo Lalloni

robfig/glock - 0 views

  •  
    "Glock is a command-line tool to lock dependencies to specific revisions, using a version control hook to keep those revisions in sync across a team."
Pablo Lalloni

Time for Password Expiration to Die | SANS Security Awareness - 0 views

  •  
    "Per Thorsheim, Microsoft's Dr. Cormac Herley, the UK's NCSC, the Chief Technologist at FTC, I and many others are working hard to kill password expiration. Password expiration is when an organization requires their staff to change their passwords every 60, 90 or XX number of days. Password expiration is also a great example of how security professionals fail by simply repeating old myths or focusing on just mitigating risk, forgetting about the cost or impact of those mitigating controls. Here's is why password expiration must die."
Pablo Lalloni

Crypto-Gram: October 15, 2017 - Schneier on Security - 0 views

  • NIST recently published its four-volume SP800-63-3 Digital Identity Guidelines. Among other things, it makes three important suggestions when it comes to passwords: * Stop it with the annoying password complexity rules. They make passwords harder to remember. They increase errors because artificially complex passwords are harder to type in. And they don't help that much. It's better to allow people to use pass phrases. * Stop it with password expiration. That was an old idea for an old way we used computers. Today, don't make people change their passwords unless there's indication of compromise. * Let people use password managers. This is how we deal with all the passwords we need.
    • Pablo Lalloni
       
      Para tener en cuenta.
« First ‹ Previous 101 - 120 of 120
Showing 20 items per page