DEV Community: Ernesto λrroyo

Be immutable my friend!

Ernesto λrroyo — Sat, 01 Feb 2020 18:52:08 +0000

En este artículo explico brevemente el concepto de inmutabilidad y porque deberías usarlo por defecto.

El concepto de inmutabilidad en la programación no es novedoso. El resurgir(*) de la programación funcional le ha dado una nueva vida, pero en otros paradigmas ha existido desde antaño.

No hay más que leer, por ejemplo, uno de los libros referente de la programación como es "Effective Java" (Joshua Bloch) que en su recomendación número 15 menciona el principio de minimizar la mutabilidad de los objetos.

An immutable class is simply a class whose instances cannot be modified. All of the information contained in each instance is fixed for the lifetime of the object, so no changes can ever be observed. The Java platform libraries contain many immutable classes, including String, the boxed primitive classes, and BigInteger and BigDecimal. There are many good reasons for this: Immutable classes are easier to design, implement, and use than mutable classes. They are less prone to error and are more secure. Bloch, Joshua. Effective Java.

(*) la programación bajo el paradigma funcional tiene su origen teórico en los años 30 y el que podría ser el primer lenguaje funcional, LISP, es de 1950.

Beneficios

Un clase inmutable es aquella cuyas instancias no podrán ser modificadas. Con este modelo evitamos errores y nuestras aplicaciones serán más seguras.

En entornos de alta concurrencia evitan errores de acceso compartido y no hace falta disponer de herramientas de protección para modificar objetos (mutex, locks, semáforos,...) porque, bueno, no se puede modificar nada.

Un objeto (mejor dicho, una de sus instancias) sólo puede estar en un estado, el estado en el que fue construido. Si hace falta modificarlo el proceso es crear una copia modificada.

Esto que puede parecer poco natural en realidad es un arma tremendamente poderosa y permite usar un estilo funcional de programación que es mucho más seguro y menos peligroso que la programación que suele utilizarse.

Podemos encontrar más razones para usar siempre objetos inmutables incluso en la misma Oracle:

An object is considered immutable if its state cannot change after it is constructed. Maximum reliance on immutable objects is widely accepted as a sound strategy for creating simple, reliable code.

Immutable objects are particularly useful in concurrent applications. Since they cannot change state, they cannot be corrupted by thread interference or observed in an inconsistent state.

https://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html

Un objeto mutable presenta muchos problemas para entornos de concurrencia.

Estas rodeado de inmutabilidad

Lo cierto es que incluso en lenguajes de OOP se usa profusamente la idea de inmutabilidad. En Java las clases como String, BigInteger, Long, UUID,...

En otros lenguajes más modernos, y vamos a dar el ejemplo con Kotlin, es más fácil trabajar con objetos inmutables e, incluso, las colecciones son inmutables por omisión.

Es decir Kotlin, al contrario que Java, prefiere la inmutabilidad y una lista no es modificable una vez creada; si necesitas que lo sea deberás usar otro tipo:

   val immutableList = listOf("one")
   val changingList = mutableListOf<String>("one")

Aún así en Java es trivial (aunque verboso) definir clases inmutables.

Nota: en Java 14 esto parece que puede cambiar gracias a la incorporación de los record. No me parece mal que Java haya decidido al final adoptar lo que sus primos de la JDK (Groovy, Scala, Kotlin,...) ya tienen desde su nacimiento. </ironic>

¡ah! pero siendo fácil podemos repasar antes una barbaridad.

Un mal ejemplo

El problema: necesitas un objeto que no pueda modificarse.

Solución adecuada: pasar copias del objeto, o crear el objeto como inmutable.
Solución "creativa" 🙀, crear un interfaz que tenga sólo métodos para lectura y pasar el interfaz a los consumidores.

Básicamente, en lugar de usar el lenguaje usas tu imaginación. 🤦🏻

Esta solución creativa implica que usaremos un interfaz -que define comportamiento o un contrato de un servicio- para lo que viene a ser un objeto de dominio o un DTO si lo usamos entre capas.

Es más que rara porque además pasando el interfaz "de setters" perdemos poder serializar el elemento

Una solución de bombero jubilado.

¡mis ojos! ¡mis ojos!

Creamos un objeto Something que será donde estén los datos.

class Something implements SomethingContext {

    @Getter @Setter String somethingId;

}

y cuando queremos usarlo pasamos SomethingContext y sí, lo has adivinado, la barbaridad es que lo pasarás haciendo un downcasting del objeto al interfaz.

public interface SomethingContext {
    String getSomethingId(); // HORROR!
    ... muchos más getters

👉 este modo de ataque y crítica nunca debe ser usado en situaciones reales, es una falta de respeto y no ayuda ni a mejorar a quien lo hizo mal, ni a quien lo utiliza. Es usado aquí como recurso literario, y me permito la licencia porque fui yo quien hizo esta escabechina en un proyecto hace algunos años. 🥳

Varias formas simples y correctas de tener inmutabilidad

En Java

Lombok

Puedes hacerlo a mano, está muy bien explicado en la documentación de la misma Oracle™, pero es que es mucho más sencillo con Lombok.

En lombok la anotación @Value implica que el objeto sólo puede ser leido tras su construcción. Es el hermano mayor de @Data.

@Value
class Something {  
    String somethingId;
}

No podrás más que leer objetos, no puedes alterar su valor.

Immutable

También tenemos la librería Immutable que ayuda en Java a crear objetos inmutables.

El problema de Lombok y de Immutable es que incorporamos librerías para un concepto que creo debería resolver el lenguaje y bueno, en modo estricto por ejemplo en arquitecturas hexagonales he encontrado gente que dice que en el modelo (dominio) debe ser tan puro que no deberíamos introducir ni siquiera estas utilidades.

Así que vamos a un lenguaje que tiene la inmutabilidad en su ADN.

Por ejemplo, por ejemplo,...

Kotlin

Llegamos a la solución más elegante y flexible con Kotlin.

data class Person (val name: String, 
                   val surname: String, 
                   val gender: String)

val earroyoron = Person(name="Ernesto",surname="Arroyo",gender="Male")

En Kotlin este objeto es inmutable. Si necesitamos modificarlo, no podemos. Y esto nos evita muchos problemas.

Además de paso te he mostrado otras cositas chulas del lenguaje como son los parámetros con nombre en el constructor.

Pero algo que no puede cambiar nunca tampoco es muy util así que, ¿que hacemos cuando va cambiando el estado?

En un estilo de programación funcional lo que se hace es una copia modificada, que no altera el original. Esto es muy fácil y nos lo ofrece el mismo lenguaje (y no, ¡ni se te ocurra pensar en el clone de Java!)

En Kotlin para tener una copia basada en el anterior objeto hacemos esto, por ejemplo pongamos que pudiera recuperar como primer apellido el hermoso segundo apellido de mi padre:

data class Person (val name: String, val surname: String, val gender: String)

fun main() {
    val earroyoron = Person(name="Ernesto",surname="Arroyo",gender="Male")
    val egarciadelasheras = earroyoron.copy(surname="Garcia de las Heras")
    println (earroyoron)
    println (egarciadelasheras)
}

Veremos:

Person(name=Ernesto, surname=Arroyo, gender=Male)
Person(name=Ernesto, surname=Garcia de las Heras, gender=Male)

Voy a concluir aquí este pequeño repaso inicial a la inmutabilidad.

Si hay una segunda parte deberíamos entrar a ver como trabajar con Kotlin de forma mucho más potente usando sus sealed class y empezaremos a pensar en modo funcional con los tipos de datos algebraicos o las ópticas,....

Be a boring and lazy developer

Ernesto λrroyo — Wed, 11 Sep 2019 17:27:06 +0000

Disclaimer: sorry for abusing the term as boring is mentioned too many times in this boring article!

Boring code and architectures

We have acronyms as SOLID, INVEST, KISS, DRY,... I made one on myself: BORING.

And what does BORING acronym means? Well, really not an acronym, is just boring. Aburrido. Ennuyeux.

Because I am thinking, no, not thinking,... I solemnly state that boring code and architectures are the most important development principle.

That good code should be mostly boring. Maybe I'll write a manifesto...

How to boring

The key for boring code is using the right abstractions, tools and idioms.

There's no problem in Computer Science that can't be solved by adding another layer of abstraction to it.

Cool or creative code is seldom needed. We should be honest: 99% of our problems are not a new deep learning library or controlling a spaceship; most of us develop a REST API, database access, we filter lists, validate inputs,... in this areas the business problems are the hard and complex thing, but the technologies to apply are not R&D.

Also be lazy

Lazy developers find a way to do things easier and, yes, boring.

Standing on the shoulders of giants

The key point is that creating really boring code and architectures is not easy.

The Law of Leaky Abstractions

The important thing is to master the abstractions, language idioms, tools and architecture principles.

Ah! don't underestimate the abstractions. Because abstractions have leaks as Spolsky explain here

And people don't mastering abstractions are dangerous: they fail, do "cool" things, clever but not clean code and such things.

Overengineer

All engineer will have a dangerous trend to over-engineer
and apply "all the tools I know"...

Well, at the end doing BORING code is not easy!

Overzealous Adopter Syndrome

Bacause of this I have seen tremendous generic abuse, optional misusage,
weird functional interfaces, model entities in libraries or
maven module-abuse, or reimplementing RFCs intead of search
for the proper library...

Finally

Actually, the key is be boring and a bit lazy and at the same
time use just the minimal needed toolset without beeing
a cowboy.

So you have to learn a lot, read a lot of blogs, books, and go to a huge number of conferences and beeing all the they preparing just for...

DOING YOUR CODE AND ARCHITECTURE A BORING THING.

Yes, that is the hard part of an architect/engineer.

A list of boring things

This

Boring architectures as hexagonal.
Boring frameworks: as Spring Boot.
Your language collections and idioms.
Boring tools as lombok, apache, mapstruts,...

Kotlin for better helper methods

Ernesto λrroyo — Thu, 05 Sep 2019 12:25:41 +0000

When implementing helper classes in Kotlin you can, compared to Java, take advantage of a less verbose and more powerful idiomatic style.

Let’s check this easy but verbose Java example; the method body is not important...

package io.earroyoron.helpers;

public class EarroyoronHelper {

/* A private constructor to avoid class instantiation */
 private EarroyoronHelper() {}

/* Just some helper method */
 public static String doSomething
 (final String a, final String b) {
 //.... whatever
   return a + " and then " + b;
 }
}

Too many things just for such a simple thing, isn’t it?

The Kotlin version just shows what a modern language is:

package io.earroyoron.helpers

/* Just some helper method */
 fun andThen (a: String, b: String): String {
 return"$a and then $b"
 }
}

We don’t need things that, actually, does not add value or improve the intention or readiness.

Of course the ; that is useless
The class, as we will not instantiate it. Kotlin adds the function (method) to the package namespace. You can import as:

import io.earroyoron.helpers.andThen

the method could indeed return directly the response as in:

fun andThen (a: String, b: String) = "$a and then $b"

Even better with extensions

A better version uses class extensions:

package io.earroyoron.helpers

fun String.doSomeTransformation (b: String) = "$this and then $b"

So you can call this helper as:

"original string".andThen ("more letters")

infix

or if you add infix to the function ( infix fun ) to improve as a DSL style:

infix fun String.doSomeTransformation (b: String) = "$this and then $b"

val sillyString = "original string" andThen "more letters"

This is the most kotlin idiomatic way; you may use object to instantiate a singleton, or companion class to have an static block in a not-singleton class but both are not the perfect way.

Functional style

As you are not creating the object and the method is just an static one, with only depending on the input parameters to produce the results you are using a functional style. Is a plus.

Utilizar la propiedad revision con maven para mantener coherencia de versiones

Ernesto λrroyo — Mon, 02 Sep 2019 13:19:25 +0000

Como pequeña ampliación a mi anterior artículo la forma correcta de versionar y establecer dependencias voy a indicar una ayuda que tenemos en maven, a partir de la versión 3.5.0

En esta herramienta de construcción podemos indicar una propiedad revision y usarla en el parent y heredarla en todos los módulos hijo de forma que podemos aplicar facilmente el principio de coherencia en el versionado del despliegue.

Esto es en el parent pondríamos:

  <groupId>io.earroyoron</groupId>
  <artifactId>project-parent</artifactId>
  <packaging>pom</packaging>
  <version>${revision}</version>
  <properties>
    <revision>1.3.0</revision>
  </properties>

y en los módulos por debajo indicaremos esa propiedad:

  <parent>
    <groupId>io.earroyoron</groupId>
    <artifactId>project-parent</artifactId>
    <version>${revision}</version>
  </parent>

  <groupId>io.earroyoron</groupId>
  <artifactId>child-module-a</artifactId>
  <version>${revision}</version>

La ventaja principal es, como indico, mantener la coherencia de versiones que sería 1.3.0 en todos los componentes por debajo de ese parent (como debe ser).

Para quien tenga dudas de si esta es la forma correcta, que se mire el código fuente de, por ejemplo, Spring Boot, que utiliza este esquema.

¿Y los BOM?

Mi antiguo compañer y amigo Marcos Martínez @cedillomarcos me recordó que el uso de un BOM también es imprescindible en la gestión de versiones con Maven pero voy a dejar este tema abierto para un próximo artículo.

La forma correcta de versionar y establecer dependencias

Ernesto λrroyo — Sun, 01 Sep 2019 10:35:47 +0000

A la hora de definir la estructura de un proyecto la forma de establecer dependencias y relaciones es un paso crítico. Debes conocer y respetar algunas reglas importantes y, cuando no las cumplas, debes ser consciente de porque has tomado esa decisión y los posibles problemas que enfrentaras.

Montar un proyecto "de cualquier forma" puede llevar a problemas de dependencias cruzadas, extraños flujos de construcción, código repetido por no poder reutilizar o incluso, a que un servicio dependa de cosas de las que no debería provocando errores posteriores muy complicados de resolver.

En este artículo uso las definiciones del libro "Clean Architecture" de
Robert C. Martin".

Tres principios

Mantener coherencia en el versionado del despliegue
Mantener un conjunto común (common-closure)
El principio de la reutilización

Mantener la equivalencia por uso en el despliegue

(Reuse/Release Equivalence Principle)

The granule of reuse is the the granule of release

Como primer principio general debemos decir que "las clases y módulos que van en el mismo despligue deben tener la misma versión y también deben tenerse juntos en la misma versión de la documentación porque eso mantiene la coherencia para el autor y los usuarios".

Debes observar que estoy hablando de un "principio" de forma que no es una ley cerrada, y puede tener sus excepciones pero ten en cuenta que las excepciones al Principio de uso y despliegue se ven rapidamente y "cantan" mucho, así que debes estar preparado para saber explicar tus razones para hacerlo de esa forma.

Si construyes un proyecto maven donde el parent es:

io.earroyoron:parent:1.0.0
|
 \__ io.earroyoron:moduleA:1.3.3
| 
 \__ io.earroyoron:moduleB:1.5.0

pero que incluye dos módulos y que al contruirlo se generan dos artefactos:

io.earroyoron:moduleA:1.3.3
y
io.earroyoron:moduleB:1.5.0

estás incumpliendo este bello principio y montando un hermoso cacao de versionado.

Porque si tienes un cambio en el móduloB tendrás que desplegar una versión nueva del módulo B (quizás 2.0.0 porque era un cambio que rompia compatibilidad) y ¿qué versión tendrás en el módulo parent? ¿mantienes como 1.0.0? no tiene sentido porque moduloB está en un major distinto ¿y 1.x.x? no, el módulo A no está en ese major version

En general, y salvo casos muy, muy, pero muy claros, el parent y sus hijos deben tener la misma version:

io.earroyoron:parent:1.0.0
|
 \__ io.earroyoron:moduleA:<parent-version>
| 
 \__ io.earroyoron:moduleB:<parent-version>

Mantener un conjunto común

(Common Closure Principle)

Gather into components those classes that change for the same reason and the same times. Separate into different components those classes that change at different times for different reasons

Puesto que para la mayoría de las aplicaciones es más importante el mantenimiento y la facilidad de despliegue que la reutilización es mejor tener en un sitio común el código que queremos cambiar.

No es buena idea que un cambio en un módulo X nos obligue a contruir tres librerias que hemos construido de forma aislada cuando ese cambio sólo afecta al módulo X y es provocado por un requisito del módulo X. Lo correcto es que el contenido de ese otro módulo esté junto en el mismo sitio.

Volviendo a nuestro anterior ejemplo, moduleA y moduleB están juntos en el mismo sitio y bajo el mismo parent porque cambian a la vez de versión por la misma razón. Es decir, dado que un cambio en moduleA de la versión 1.3.4 a, digamos, la versión 1.4.0 obliga a que el móduloB también pase a la versión 1.4.0 este segundo principio nos dice que es correcto porque el cambio afecta a ambos módulos y su versión.

Separar para priorizar la reutilización

Don't force users of a component to depend on things they don't need

El tercer principio es contrario a los dos anteriores. Basicamente indica que separes en módulos diferentes las cosas que son diferentes para que los clientes que declaran una determinada dependencia sólo se traigan lo que realmente requieren.

O dicho de otro modo, no tener que importar un enorme librería de 7 terabytes si sólo necesito una función muy concreta de esa librería.

Es un principio contrario a los anteriores porque nos está empujando a romper y separar en muchas piezas nuestros componentes para tener un grano muy fino a la hora de declarar las dependencias.

En el ejemplo, si otro módulo necesita importar moduleA pero sólo necesita una mínima parte de él quizas la estructura debería separar en otro módulo esa pequeña parte para facilitar la reutilización:

io.earroyoron:parent:1.0.0
|
 \__ io.earroyoron:module-min-A1:<parent-version>
|
 \__ io.earroyoron:module-A2:<parent-version>
| 
 \__ io.earroyoron:moduleB:<parent-version>

El problema es que llevado al extremo este principio genera más problemas en los despliegues que los beneficios que trae por reutilización.

Tensiones

Los 3 principios o reglas establecen un modelo de lucha y tensión.

Si nos enfocamos a separar en muchos componentes pequeños (el 3er principio) agrupados en un versionado común de despliegue (1) vamos estar sacando versiones innecesarias de librerias que no lo necesitan ante el más mínimo y superfluo cambio en alguno de sus elementos:

Demasiado enfoque en reutilizar:

io.earroyoron:parent:1.0.0
|
 \__ io.earroyoron:module-A:<parent-version>
|
 \__ io.earroyoron:module-B1:<parent-version>
|
 \__ io.earroyoron:module-B2:<parent-version>
|
 \__ io.earroyoron:module-C1:<parent-version>
|
 \__ io.earroyoron:module-C2:<parent-version>
|
 \__ io.earroyoron:module-D:<parent-version>
|
 \__ io.earroyoron:module-E1:<parent-version>
| 
 \__ io.earroyoron:module-E2:<parent-version>

Si obviamos el principio de mantener el versionado coherente en el despliegue y sólo nos enfocamos en los otros dos principios (2,3)d nuestras releases tendrán versiones "de su padre y de su madre" y haremos muy complicado el modelo de dependencias.

io.earroyoron:parent:1.0.0
|
 \__ io.earroyoron:module-A:1.2.3
|
 \__ io.earroyoron:module-B1:2.5.3
|
 \__ io.earroyoron:module-B2:2.5.3
|
 \__ io.earroyoron:module-C1:2.0.0
|
 \__ io.earroyoron:module-C2:2.0.0
|
 \__ io.earroyoron:module-D:1.1.1
|
 \__ io.earroyoron:module-E1:1.1.1
| 
 \__ io.earroyoron:module-E2:1.1.1

Finalmente, si sólo nos centramos en mantener un versionado coherente (1) y agrupar las cosas (2) vamos a tener más complicado o imposible la reutilización por terceros de nuestros componentes.

io.earroyoron:parent:1.0.0
|
 \__ io.earroyoron:module-A:<parent-version>
|
 \__ io.earroyoron:module-B:<parent-version>

La mayoría de los casos deben primar los principios de versionado común y agrupar por responsabilidades comunes (1 y 2) y dejar la reutización para más adelante ya que suele ser un anti-patrón de optimización prematura que lleva a muchos problemas.

El Teorema CAP: porqué los bancos usan mainframes.

Ernesto λrroyo — Mon, 21 Jan 2019 19:36:10 +0000

Una unidad central (en inglés mainframe ) es una computadora grande, potente y costosa, usada principalmente por una gran compañía para el procesamiento de una gran cantidad de datos, como por ejemplo, para el procesamiento de transacciones bancarias. Wikipedia

Why Mainframes Are Still Part of IBM’s Backbone | Data Center Knowledge

Antes de empezar hay que deshacer un mito: los mainframes ya no son dinasaurios con tecnologías obsoletas, cintas dando vueltas y tarjetas perforadas. Eso es falso. Los sistemas mainframes modernos también ejecutan bajo Linux, y soportan sistemas relacionales como Oracle y lenguajes modernos.

Lo que diferencia un mainframe es el hardware: son enormes bestias de procesamiento y unos monstruos en su capacidad de entrada/salida. Y no son baratos ni flexibles.

Puede que algunos se pregunten por qué los bancos no cambian estos sistemas por componentes mucho más baratos, lo que viene a ser un sistema de computación distribuida donde está claro que podemos escalar de forma mucho más económica e incluso podemos ser elásticos y reducir potencia si no necesitamos tanto hierro en determinado momento.

A mi, tras empezar a conocer un poco mejor el tema de arquitecturas distribuidas me ha venido una razón muy clara, pero no he encontrado este mismo razonamiento en otro sitio; cuando te venden las ventajas de estos sistemas te hablan del TCO, del ahorro,… no te hablan de esto.

La Conjetura de Brewer

En 2000 Eric Brewer enunció una Conjetura que sostenía que cuando lo que tienes es un sistema distribuido es imposible garantizar de forma simultanea la consistencia de la información, la disponibilidad del sistema completo y el particionado (esto es, la tolerancia a seguir operando en caso de fallo de algún nodo).

En un sistema distribuido, por definición, tenemos partición ya que es el concepto mismo de sistema distribuido.

Por tanto debe elegirse si quieres tener consistencia de información (todos los nodos ven la misma información en el mismo orden en cualquier momento) o quieres asegurar disponibilidad del sistema (algún nodo puede tener información distinta y ya los pondremos de acuerdo, esto es consistencia eventual, pero el sistema siempre responde).

El Teorema CAP

La Conjetura de Brewer pasó a ser un teorema demostrado matemáticamente en 2002 (Nancy Lynch and Seth Gilbert, “Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services”).

Sí, hay una demostración matemática. Osea que siempre que estés usando un sistema de computación distribuida, o elijes consistencia, o elijes disponibilidad.

En un sitio web como Amazon probablemente prefieran disponibilidad: si un producto no tiene stock porque el nodo tenía información no actualizada en ese momento, ya lo solucionarán, pero nada de una pantalla de indisponibilidad. Aquí queremos vender mucho.

Quizás un sistema de información de otro tipo prefiere consistencia. Si no estamos seguros de tener información correcta esperamos a que los nodos se puedan encontrar en el mismo estado, y puedo permitirme esa espera en que la información esté consistente.

Entonces ¿qué pasa con los bancos?

Pues ocurre que los bancos no pueden renunciar a la consistencia ni a la disponibilidad. No podemos anotar operaciones más que en un orden y en un sólo sitio debe tenerse la información. La operación debe garantizar la consistencia fuerte (strong consistency: All accesses are seen by all parallel processes in the same order — sequentially)

Tampoco podemos dejar de dar servicio 24x7 porque un nodo se haya caído o tenga un tiempo de espera por el que, el resto, deba dejar de atender hasta encontrar un estado consistente (en sistemas distribuidos se puede garantizar la consistencia fuerte si esperamos a que los nodos se trasladen un ACK de haberse puesto en la misma versión de la información, pero nosotros no podemos esperar)

Osea que esto, según el teorema CAP es imposible,… en sistemas distribuidos.

Los sistemas distribuidos son complicados.

La única solución es no tener sistemas distribuidos.

En una empresa normal diríamos que tenemos una base de datos centralizando la información, lo de toda la vida, pero es que en un banco no hablamos de un sistema normal, es que estamos hablando de un sistema de gestión de información de enorme capacidad de procesamiento y entrada/salida. Esto es lo que ofrece un sistema mainframe, los big-iron: una locura de procesamiento y una disponibilidad casi completa en un nodo centralizado que asegura consistencia fuerte (strong consistency).

El nodo debe ser capaz de soportar un enorme número de transacciones, enorme (sí, esas compras navideñas o del Black Friday, todas anotándose en el mainframe) y debe tener una disponibilidad absoluta (ni caerse, ni perder datos).

Por eso las arquitecturas de los mainframes escalan de forma vertical, con sistemas de procesamiento de E/S que nada tienen que ver con los ordenadores normales (las tarjetas de E/S tienen CPUs dedicadas).