etiquetas: mentiras, falacias, milongas, trolas
» noticia original (www.youtube.com)
La caterva político-periodística ya ha cumplido su función de demonizar el ciclo Diesel, precisamente donde la industria europea tenía una ventaja competitiva (cada vez estoy más convencido de que trabajan para el enemigo).
Como hemos comentado en otras entradas, de nada sirven los hechos cuando la sociedad ha asimilado una percepción. Por supuesto, no voy a cambiar nada desde este humilde espacio. Sólo presento los datos de contaminación recabados por el ADAC en una prueba en tráfico real a título informativo, como mera curiosidad para charlar entre cuates.
Sin mucho rebuscar (si queréis indagar entre los resultados, ahí tenéis el buscador del EcoTest) os presento los resultados de dos vehículos de la misma categoría, animados por sendos motores en su día muy polémicos, homologados ambos según la Euro 6d.
El gasolina, un Peugeot 308 130CV.
CO2: 170 g/km
HC: 8 mg/km
CO: 1269 mg/km
NOx: 19 mg/km
Partículas (masa): 0,3 mg/km
Partículas (número): 0,9758*10¹¹/km
+
El de gasóleo, un VW Golf TDI 115CV.
CO2: 149 g/km
HC: 6 mg/km
CO: 7 mg/km
NOx: 10 mg/km
Partículas (masa): 0,3 mg/km
Partículas (número): 0,02665*10¹¹/km
+
Como veis, no soy nada rebuscado; son dos de los coches más vendidos dentro de ese segmento, con motores de gasolina y gasóleo muy populares y profusamente montados en nuestro parque.
Brevísimamente.
El CO2 no es un contaminante (es un gas prácticamente inerte) pero es el principal agente de efecto invernadero. Para un mismo combustible, es directamente proporcional al consumo. Un litro de gasóleo emite algo más que un litro de gasolina pues tiene cadenas de carbono más largas.
HC: Hidrocarburos que salen por el tubo de escape sin quemar. Ahí hay de todo, algunos de ellos (los cíclicos, como el benzopireno), cancerígenos.
CO: Se combina en los pulmones con la hemoglobina, limitando el transporte de oxígeno por ésta. Por lo tanto, afecciones respiratorias y cardíacas. Al trabajar con dosado estequiométrico, los gasolina siempre salen mal retratados en esta prueba. El ciclo Diesel trabaja con dosados muy pobres, con exceso de oxígeno, así que la oxidación es completa (sólo se forma CO2, apenas CO).
NOx: Irritante de las mucosas, provoca en exposiciones crónicas enfermedades pulmonares. Es el contaminante típico de los diésel, ya que se forman a las mayores presiones y temperaturas que hay en la cámara de combustión de este ciclo. Es el compuesto que se tomó, usado como único indicador, para demonizar al Diesel. Pero con las inyecciones de urea en los SCR, y diversas técnicas para bajar la temperatura de la cámara de combustión (EGR y jugando con los pulsos de inyección), vemos que está controlado.
Y las partículas o PM son los productos de la combustión, un cóctel de sustancias que conforman lo que habitualmente conocemos como hollín. Un mayor número de ellas, para una misma masa, implica que su diámetro medio es menor y, por lo tanto, son más peligrosas (más capaces de atravesar la pared alveolar y entrar en el torrente sanguíneo). Éste es el principal riesgo para la salud derivado de las emisiones contaminantes de un motor de combustión. Los gasolina siempre tenían ventaja en este apartado, pero la adopción casi unánime de inyección directa en los gasolina (Toyota en su 1.8 es la principal excepción), produciendo mezclas estratificadas que no siempre se queman en su totalidad, ha cambiado el panorama.
Dicho esto, a la vista de los resultados, se puede afirmar que, en este caso, el motor de gasolina contamina más en todos y cada uno de los apartados. Buscando otros motores bien pudiera ser el resultado contrario. Sencillamente, la cuestión es más compleja de lo que pretende la reata periodística.
En cuanto a los consumos en esa prueba de tráfico real, se puede decir que quien tuvo, retuvo.
Gasolina: 6,6 / 5,6 / 8,0 l/100km
Gasóleo: 4,9 / 4,2 / 5,6 l/100km
Respectivamente en ciudad, carretera y autopista.
+
¡Ah!
Me doy cuenta que esta comparativa no estaría completa si no incluimos a un coche con etiqueta Eco. Pues no me voy muy lejos y escojo el 308 híbrido, también con homologación Euro 6d:
CO2: 142 g/km
HC: 16 mg/km
CO: 249 mg/km
NOx: 130 mg/km
Partículas (masa): 1,5 mg/km
Partículas (número): 2,43084*10¹¹/km
Pues sí, el híbrido es aún peor, mucho peor que su hermano convencional. Y no es porque un motor de ciclo Atkinson (una modificación del Otto con un cierre de la válvula de admisión muy retrasado para reducir el trabajo de bombeo) contamine necesariamente más, como nos demuestra de nuevo Toyota (recordad, inyección indirecta, en el colector de admisión). Sencillamente, no hay ciclos buenos ni malos, sino implementaciones más o menos logradas de estos.
¿Sorprendidos por los resultados? Los que seguís este espacio desde hace tiempo, supongo que no.
De esta forma, podemos desmentir categóricamente que el buen Rudolf Diesel sea el hijo de Satán, como se pretende en los medios.
+
+
+
+
+
+
+
+
+
Título original: Le siècle des génocides. Violences, massacres et processus génocidaires de l’Arménie au Rwanda.
© Armand Colin, 2024
© de la traducción: Florencia Peyrou Tubert y Hugo García Hernández, 2006
Editorial: Alianza Editorial.
Un grupo es destruido intencionalmente, en parte o en su totalidad, en nombre de criterios nacionales, étnicos, raciales o religiosos.
El siglo que acaba de terminar quedará entre nosotros como el del horror. Empezó con la aniquilación de la población armenia y terminó con el exterminio de los tutsis de Ruanda y la «limpieza étnica» en la ex Yugoslavia.
El mundo ha sido testigo de las grandes masacres de la era estaliniana, de la inmensa tragedia de la Shoa, y de la desaparición de una parte de la población camboyana.. La palabra genocidio, creada en 1944 por el jurista Raphael Lemkin, intenta designar un tipo de crimen masivo por el que un grupo es destruido intencionadamente, de forma total o parcial, en nombre de criterios nacionales, étnicos, raciales o religiosos.
Bernard Bruneteau analiza en detalle los grandes momentos genocidas del siglo XX. Y analiza, también, su principal agente de incubación: el potencial de violencia acumulativa presente en ciertas experiencias políticas, militares e ideológicas del siglo XX, como las masacres de las conquistas coloniales, las teorías de la lucha por la vida que las justificaron o la «guerra total» de 1914, que inauguraron el encuentro de los pueblos europeos con la muerte en masa.
Bernard Bruneteau es profesor de Historia Contemporánea en la Universidad Pierre Mendès France-Grenoble II y especialista en temas de totalitarismo.
Tiempo estimado de lectura: 32 minutos.
Objetivos de este libro:
Ideas principales:
Algunas de las cosillas que aprendí leyendo este libro que no tienen porque ser ni ciertas ni falsas ni todo lo contrario:
¿Has leído este libro? ¿Algún libro parecido? ¿Tienes alguna cosa que decir sobre lo que expone este libro? ¿Recomiendas algún libro relacionado a este? Estaré encantado de leer lo que piensas sobre este libro en los comentarios.
Algunos enlaces relacionados:
Algunos libros relacionados:
raul
Si te has preguntado la razón por la que sueñas con alguien todos los días, no te angusties y trata de comprender lo que tu mente intenta decirte. Sucede que el mundo de los sueños está rodeado de un misticismo único. Para algunos, estos escenarios imaginarios son simples escapes de la mente; para otros, esconden tras de sí un mensaje subconsciente.
Entonces, lejos de interpretaciones místicas, ver a la misma persona protagonizar tus sueños una y otra vez suele estar relacionado con emociones pendientes y recuerdos que tu cerebro reactiva mientras duermes.
En la infinidad de escenarios que nuestra mente visita cada noche, es común que aparezcan las personas más allegadas y significativas. Por lo que no es de extrañar que ciertos rostros se repitan en nuestros sueños, como los de nuestros padres, hermanos, amigos, pareja o compañeros del trabajo.
Según los expertos, soñar tiene un papel activo en la forma en que procesamos y guardamos los recuerdos emocionales recientes y pasados. Mientras dormimos, el cerebro no descansa del todo: sigue procesando lo que paso en el día, los sentimientos intensos, problemas personales y otras experiencias relevantes.
Esto significa que cuando una misma persona aparece noche tras noche en tus sueños, no es por una señal misteriosa, sino por un reflejo de lo que tu mente considera importante. Por ejemplo, puede que tengas conflictos emocionales sin resolver, quizás esa persona es parte importante de tu vida o es alguien que ocupa mucho espacio en tus pensamientos.
Podría interesarte: Descubre cómo interpretar tus sueños
No hay un motivo específico por el que tu mente insista en soñar con una persona todos los días. Aunque es fácil pensar que existe una conexión especial, en los sueños es común que aparezcan rostros y situaciones que representan aspectos de la vida y emociones en curso. Esto no le quita lo misterioso al asunto, todo lo contrario. Refleja la idea de que los sueños son espejos de nuestro mundo interior.
Tal vez esa persona aparece en tus sueños porque quedó un asunto pendiente entre ustedes y hay sentimientos no resueltos que tu subconsciente trata de entender. En otros casos, si alguien hace parte importante de tu vida, es natural que aparezca en tus sueños, ya que el cerebro recurre a quien despiertan más emociones en ti.
Soñar con alguien muy seguido cuando atraviesas un periodo tenso, también se interpreta como una forma en la que tu mente busca canalizar el estrés. Puede que no se trate tanto de la persona en sí, sino de lo que simboliza para ti: seguridad en momentos tristes, nostalgia por lo que ya no está, conflictos internos o el apoyo que en el fondo necesitas.
En muchos otros casos, la razón por la que sueñas con alguien todos los días es porque te despierta atracción, admiración, curiosidad o deseo. No porque te haga brujería o algo por el estilo.
Que una persona aparezca seguido en tus sueños no siempre es motivo de preocupación, pero, en ocasiones, puede tener un efecto negativo en la vida diaria. Por ejemplo, si su presencia te genera angustia y ansiedad al despertar, quizás tu mente está enviando un mensaje de que hay un problema emocional por atender en la realidad.
A veces, la razón por la que sueñas con alguien todos los días está relacionada con emociones no resueltas: culpas, miedos, tensiones, anhelos y conflictos internos que aún no encuentras cómo gestionar. En consecuencia, si soñar mucho con alguien empieza a afectar tu descanso o intensifica sentimientos negativos, lo mejor es buscar ayuda profesional.
Y si sueles soñar con una persona que ya no hace parte de tu vida, como una expareja o alguien que murió, no dudes en acudir a un especialista en salud mental para sanar lo que haya que sanar y recuperar tu bienestar emocional. Tal como decía el psiquiatra Carl Jung, “quien mira hacia afuera, sueña; quien mira hacia adentro, despierta”.
La entrada Esto es lo que puede estar ocurriendo si sueñas con alguien todos los días se publicó primero en La Mente es Maravillosa.

Written by: Boris Dali, Database Engineer @ Google (LinkedIn)
First off, the disclaimer: this blog series is neither a Google official documentation, nor it is an authoritative source. For the former, docs on AlloyDB Omni in particular, please see here and for the latter, please feel free to reach out to the AlloyDB product team. Google Cloud official blogs are posted here. Medium hosts Google Cloud Community here. This is neither. The opinions I express here in this blog post series are my own and may not represent or agree with Google’s official position on the subject.
So what is it then? Well, if you think of this blog series as the one engineer’s pseudo random ramblings on a particular topic (“running databases in containers on K8s” that is), you won’t be far off 🙂.
In part 1 of this blog series I tried to get the lay of the land, define the objective that I eventually hope to achieve (which in essence is to justify the complexity of running databases on K8s) and the plan on how I intend to get there. The first step in this plan is to define my on-prem customer expectations from a cloud provider for hosting my data, which obviously should be superior to what I had on-prem for years.
These considerations surrounding a potential move to a cloud may seem like an unnecessary detour from the original question I started with, but as a database professional, I never took cloud for granted. To me it was a huge mental shift, a leap that I always had to justify (to myself first, before talking to customers), no matter if it happened a decade ago or today. Maybe it’s just me, but in my mind it’s never been a given that a cloud³ is better than my co-lo with my carefully crafted, custom monitored, tailor made infra that fits my databases like a glove. Mission critical databases are a tad different from the stateless 12-factor apps! Can cloud provider’s DBaaS systems really be flexible enough to mimic what I’ve designed and perfected on-prem over the years and at a reasonable price point? I’d love to see how! And so I always had to do a mental sanity check to ensure that I indeed offer customers the best solution that serves their interests.
Interestingly, some customers came to us already convinced and determined to let go and embrace the cloud and DBaaS along with it (because they either have done the homework on their own, already went through this mental exercise with other cloud providers or perhaps their board of directors told them that a cloud is the way to go), but personally, I always appreciated those who questioned how exactly Cloud SQL or AlloyDB Cloud would help their particular business sell more shorts and shoes, process their purchase orders quicker, run auctions smoother, etc., etc. In my experience, these discussions often revealed critical, often implied and “obvious” business specifics that pushed the boundaries and led to new ideas and innovation in our DBaaS offerings.
And so reviewing the pros and cons of a cloud migration from a database perspective (irrespective of whether it’s contemplated via a lift & shift, minor changes, significant redesign or a complete “modernization”) and building a frame of reference is helpful to not only make an informed decision as to whether or not a cloud, and in particular, the cloud provider’s DBaaS, is right for my business, but the same frame of reference can then be used to look for alternatives. In other words, to me cloud/DBaaS justifications is a reasonable starting point to paint the full picture and begin building the bridge of logical reasoning for extending it beyond a cloud to running databases in containers (and throwing K8s into the mix for good measure 🙂). Even if running databases in containers takes me back to on-prem, completing the full circle.
³ Somebody shared with me this nice picture (a cover for a book actually) recently: “Dad, what are the clouds made of”?
So let’s get on with it, please bear with me. Why would I even consider abandoning the convenience of my all too familiar on-prem environment with all my beloved Perl scripts that I’m comfortable with and entertain the possibility of moving my data to a cloud?
On the surface the move to a cloud doesn’t seem to even require much pondering. For one thing, there’s a growing belief in the recent years –particularly among the data streaming proponents– that the “data democratization has largely failed to live up to its promise” (source), and that the data growth far outpaces our ability to process it, which ultimately leads to “data anarchy” ⁵.
Well, if the amount of data we accumulate is really set to grow exponentially, reaching an estimated 200 ZB of data worldwide by the end of 2025, probably more as we explore the new frontiers of technology like AI, IoT, etc… where would you store it and how would you manage all that data? Is your on-prem storage, compute and network infrastructure ready to handle this data explosion? Well, if it isn’t, not to worry, a cloud is elastic and unlimited in capacity, right? I mean your co-lo may be resource constrained, but the cloud provider’s data centers are surely not. Isn’t it the natural place then to migrate your existing business to and prepare for the upcoming skyrocket growth of the new data influx?
That’s indeed a no-brainer argument. Or is it? Maybe, except, personally, I always liked folks that perhaps accept that as a general statement, but then questioned as to what these massive amounts of data mean for their particular business. As in, would they all of a sudden start selling 1000 shoes an hour across all their stores worldwide as opposed to the current 100? Would it be 10k perhaps? Or would that mean that the number of metrics that they need to track to help them sell more shoes would need to quadruple? Or what exactly?
This argument may indeed work for some businesses, particularly those that depend on the number of hits on the net (with Gen AI those would likely multiply like mushrooms), but unless you, as a cloud provider, can convince me, the customer, that the number of shoes that my stores will be selling next month after the cutover to your cloud would increase in a way even remotely resembling this hypothetical exponential data accumulation growth you pitched to me in that argument… I’d need a lot more convincing that your cloud is the right place for hosting my business.
OK, but how should this convincing process work? What would be my business’s expectations from a cloud provider?
⁵ I’m pretty sure I had it as a quote from somewhere, but this piece was written ~six years ago and I can’t find now the exact source to attribute it to. I believe that the sentiment still holds true though, so I leave it here, but if you, dear reader, know the source, please leave a comment and I’d be happy to add the right attribution.
And yes, I’m not oblivious to the fact that it’s easy to see the convenience of keeping my photos and other “static” files hosted in a cloud (by “static”, I don’t mean immutable, just perhaps less concurrent than a database, less transactional and without a relational schema on top). Unless you’ve been hiding under a rock or living in a cave or on a remote planet somewhere at the end of the Galaxy for the last few decades, you probably own a cell phone or two (did you notice that we don’t even call them “smart” anymore?) and likely more than just a single laptop or a desktop computer. Having the ability to work on all of these devices seamlessly and continuously, to pick up a document that you started at your desk in the office, review it on the phone “on the go” and add corrections on a laptop at home is a norm today. No, we no longer call this way of seamlessly transferring the work from one device to another smart or even productive. Today, this is just the “norm”.
Especially if you don’t actually live in a solitary cave (a shared, common one is OK) and happen to have a need to collaborate with others. You know, colleagues, partners, managers who hopefully provide helpful suggestions to improve and refine your document. Having a doc stored in a common place that is shared with all relevant people and that is accessible from all of your devices just makes sense. No need to copy it, sync, worry about working on the outdated copy that lost all the recent revisions, etc, etc. So much so that if you want to keep up with this fast changing world, this becomes just the baseline that we don’t even think to question anymore. It’s the norm.
All of this is to say that sure, when it comes to “static” docs, photos and the like, particularly those that benefit from a collaborative work, a cloud and in particular a cloud storage, perhaps makes more sense than your corporate file server unless you can make it globally available, don’t care about its uptime and can offer the same zillion 9s of durability and availability (e.g. Google Cloud object storage known as GCS offers 11 9s of annual durability and 4 9s of availability).
So yes, docs and photos stored on a cloud are nice, but I always stumbled at extending the same thinking to “dynamic” data, you know the one that comes in transactions, has to obey the ACID properties and has low tolerance for a latency beyond a few milliseconds and requires high throughput too for batch jobs, backups and the like. This has always been an extra leap for me to use the same justification/thinking as we do for files. Because data stored in databases is not the same as data stored on a file system… or could it be?
Yes, speaking of “static” vs. “dynamic” files… Have you ever wondered if a file system can perhaps evolve into offering at least some of the database functionality? I did. In fact, when I started studying a cloud, I was curious to see if a cloud innovation could perhaps move the needle in that direction for lower end databases by offering the likes a SQL*Lite on steroids, but as a fully featured database server, not just a library. That would be something, wouldn’t it?
Sure, databases feature high level abstractions compared to OS files and in particular offer a SQL interface for accessing and manipulating data. But if ksql could add a SQL engine on top of the streaming Kafka pipelines, can’t SQL be added on top of files? And ultimately that data in a database is stored in files on a file system anyway, is it not? If so, for simpler, lower end database functionality, is the fully featured database level abstraction really necessary or was it just the programmatic connivence that was originally used to rush-deliver a relational database product on a deadline⁶ ? Especially if the relationship between a table presented by a database via SQL and the corresponding OS file is 1:1, which indeed can be the case in some database engines (for instance in MySQL with InnoDB and the file-per-tablespace feature enabled).
That table per file arrangement solves some of the space fragmentation issues where you drop a table and it simply leads to a deletion of a corresponding file. For DDL statements, it also makes the fine-grained locking problem of different parts of a file mostly irrelevant, because there’s just a single table stored in it. Nice, no? But what about DML? Extend the same idea and store every row now in a separate file? Well, for one thing, file systems don’t scale that great when they need to traverse inodes for millions of files to find the right one. The much larger problem however is Jim Gray and ACID.
Indeed, many file systems claim to be transaction-aware (implemented either via the simpler journaling or the more sophisticated copy-on-write semantics), but the level of atomicity in file system is different compared to databases because that atomicity of changes in a transaction only apply to metadata in these file systems to keep their integrity, not the actual data. And so yes, the atomicity and consistency of making data changes across multiple tables as part of the same tx is hard for file systems and so is a roll back to a previous consistent data state. This also applies to concurrency with the fine grained granularity of the row level locking for different rows hosted within the same table.
And yes, CoW file systems like ZFS and Brtfs certainly showed some promise in borrowing some of the database smarts and offering transactional integrity (again, only at the metadata level) and basic checksumming, but they are not wide spread, don’t feature a higher level concept of a schema (i.e. constructs like tables, rows, referential integrity, RBAC), don’t offer SQL interface and come with problems on their own (e.g. ZFS’s high memory requirements, fragmentation due to CoW, vdevs configuration and management complexity, etc.) I was excited to learn about Google’s Colossus with its metadata stored in a NoSQL database (Google Bigtable) and which implements CoW very differently because it happens to be a highly durable distributed file system unlike ZFS that is designed for a single machine/storage array, but the feature gap is still too wide for modern file systems to replace a database.
⁶ Everybody knows the fundamental theorem of software engineering stating that “any problem can be solved by introducing an extra layer of indirection”.
OK, so since cloud didn’t (yet?) offer a major breakthrough in a file system space that can act like a database and, as they say, data has gravity⁷, so what innovation does a cloud offer to make me take the plunge? Is there some serious innovation in the space of the storage formats and/or protocols perhaps because the cloud providers do have full control of the underlying infrastructure and storage in particular?
Indeed, while the concept of object storage predates the Cloud, it’s probably safe to say that the launch of S3 by AWS in 2006 popularized this concept and made it part of the mainstream tech stack that any cloud provider relies on today (for Google Cloud this is the famous GCS service, which offers its own API, but is also S3 compatible).
That’s great, but is there any major innovation beyond that? From the relational database perspective the object storage is useful for a few peripheral tasks like backups, data influx, migrations and a few other use cases, but it’s the block storage that remains the way to actually hold the data… and in contrast to S3, it ain’t cheap.
What I expected (hoped?) to see from the cloud providers is some major innovation beyond just an S3 compatible object storage offered via HTTP interface. The block devices offer protocols like IDE, SCSI, NVMe, SAS, etc. that have been around forever and so are the ways to share these block devices over the network via NFS, iSCSI (for file and block respectively) and the like. Did cloud perhaps offer innovation in the transport protocols like something better/newer than RDMA and RoCE? And yes, there are also JDBC, ODBC, ADO.NET and sometimes (unfortunately) ORM on top, but these are just the client-side data access protocols. Cloud does famously boast compute and storage disaggregation, but it’s a broader cloud innovation, not specific to database computing (although obviously databases do take advantage of it too). One exciting innovation in this space was introduced by Google AlloyDB Cloud and AWS Aurora in making the WAL (the redo, for Oracle folks) the primary persistence layer (aka Log-as-a-Service), which in the case of AlloyDB is synchronously written to Colossus and processed by LPS (Log Processing Service).
That’s innovation that in my opinion indeed advanced database computing, but there isn’t much beyond that in terms of storage formats and protocols that I’m aware of (if you are, dear reader, please drop me a comment).
So to summarize some of the major, ground breaking cloud innovations for database computing are… somewhat limited⁸: surely not a complete list, but yes, there’s compute/storage disaggregation, there’s Colossus with some sophisticated database smarts, there’s AlloyDB and Aurora (kudos to AWS folks BTW for pioneering this concept among many others!), but no new storage format and no file system offering database processing capabilities and perhaps most importantly… what I really wanted to see from the cloud providers is an offer of a paradigm shift that in my mind would represent a radical departure from the on-prem thinking of database management.
What I mean by that flashy statement is that I expected the cloud providers to ask their prospective customers a simple question: how do you bend a spoon with your mind? (hint: in case you lived on a different planet for a while, watch Matrix). That is, don’t talk to me about databases. There’s no database. You can’t bend a spoon with your mind, everybody knows that… unless, there’s no spoon. So talk to me about apps and data instead. Leave databases to your favorite cloud provider to take care of. Database-less (or serverless if you prefer), zero-ops, zero-management, zero-warm up time, autoscaled (in compute and storage) with near-zero latency ramp up time once the first query is submitted, PAYG, Data as a Service rather than DBaaS.
Unless my business actually revolves around offering professional database services, to me a database is an overhead. A tax that I have to pay to host my data. Data is what I care about because it holds my business’s secret sauce, my competitive advantage. But on-prem I’m forced to talk to storage admins and to system admins and to network folks… and oh, yes, to the DBAs too (unless there’s a home grown self-service DBaaS, but we’ll talk about it later).
You want to help my business with your fancy cloud? Sure, then don’t talk to me about databases. I don’t need to know about backups, running out of disk space problems, physical corruptions or even just starting/stopping a database. I don’t need to know anything about a database at all other than how to connect to it! Instead of operating with the notions of a database latency, throughput, bandwidth, backup retention, RTO/RPO, etc., talk to me in terms of shoes and shirts that my business sells and how your cloud can help me sell more of them or sell them cheaper (by perhaps streamlining my supply chain or finding new markets or replenishing my inventory in some smart way). Talk to me in a way that my business folks can understand, not my IT department.
Surely as a general purpose public cloud provider you can’t tailor your services to every industry and every shop, but that’s where your customer engineers, your architects, your TAMs, your FSRs, your network of service integrators, etc. should step in, convert that mambo-jumbo tech jargon to the business terms and talk to me about my data, not a database “shell” that is only there to host it.
Now, that’s different. This is like Google Cloud Run or Lambda, but for the most persistent thing there is — my data. Some cloud vendors tout database automation or a complete autonomous database “to automate routine DBA tasks, to reduce DBA human error and to reduce the operational costs”. That’s not what I’m after. I don’t want a database to be my concern period. There’s no spoon. Not better automated, not fully automated, not autonomous. I’d like to outsource the concept of that database “shell” (that hosts my data) altogether. There’s just data that my apps need whenever they need it. Don’t talk to me about anything else.
My thinking here is similar to what I already alluded to earlier: the on-prem enterprise databases are tailor-made. It can’t be any other way. Data is a lifeline of any enterprise application. To stay competitive, data needs to be carefully cradled into a perfectly designed database, with the perfect set of servers suitable for hosting it, perfect storage and perfect network. If my on-prem infra isn’t perfectly suited for hosting my database, I’ve got the wrong IT department.
To be sure, the logical modeling, the schema design and the business logic translated into the app/database code is absolutely critical, there’s no doubt about that. But once all set and done, well, it’s difficult to break the mold. What can be changed less painfully is the physical layout and so the operations teams iterate over it to ensure that the server/storage/network fit that database like a glove.
This is why every database in every company is a unicorn. Very few are of the garden variety (at least not those that were worth my consulting time). Everything is tailor made, even though millions run on the same database engine, be it Oracle or Postgres or anything else. This is also why database consultants had an unbounded amount of work for decades, to fine tune performance, security, and availability of these uniquely crafted databases.
This is the on-prem world. Then comes the cloud.
Public clouds and the fully managed DBaaS systems like AlloyDB Cloud, and Cloud SQL or Aurora and RDS are mostly a “one size fits all” affair. Please don’t get me wrong, as a customer, I can totally change a compute shape or a storage size or the networking setup or check off some of the database option/extension boxes. However I still claim that this is not the same as my fully custom built setup on-prem. Why?
Well, your cloud provider’s DBaaS systems are jammed packed with features. For instance, Google’s AlloyDB Cloud offers best in class security and compliance features ranging from the basic encryption at rest and in flight to CMEK (backed by KMS/HSM), AXT (access transparency), perimeter security, Sec4, DRZ (data residency), R5, data exfiltration controls, AXV (access sovereignty), FIPS, FedRAMP, IL4/5 compliance, ITAR, CJIS, BYOID, etc. All these features are incredibly important for enterprise adoption and exactly what Gartner looks for. If your business is DOD, DHS or any of the other three letter government agencies, I don’t see how you can get your data to be accredited on a cloud provider’s DBaaS service that doesn’t offer all of these security, privacy, sovereignty and compliance guarantees.
But.. are all these features needed for all (other) customers? Does my business need it to sell more shoes and shirts? If not, why are you asking me to pay for it? Even if it’s a freebie that I opt in/out by checking the boxes (is there really such a thing as a free lunch?), doesn’t it make your (cloud provider’s) operations, patching, upgrade, compatibility, testing, etc. a lot more complex? As in, doesn’t it explode your CI pipeline to test the changes against all of these possible customer combinations? And you are telling me that I’m not the one to foot that bill? Can you guarantee, for instance, that a failed and totally-unrelated-to-me CMEK database patch won’t affect my database service in any way, shape or form?
Here’s another way to look at it: everybody’s shopping habits are different. Personally when I’m in the market for a Ford, Jeep or Toyota RAV4 with the turbocharged engine, I don’t particularly care about the once in a lifetime, ending tomorrow, dream-come-true promotion for a Cadillac or a Rolls-Royce. These are just not the cars that I’m looking for, not for the initial value — no matter how much below the MSRP/sticker price I can get it for — nor for the maintenance and the upkeep. It’s just not the right car for me, high up here in the Colorado mountains at ~6–10k feet above the sea level where I live because I just need a reliable car for the icy mountain roads and low oxygen environments.
The point? A single SKU, one size fits all, generic, monolith database service may not be the right fit for everyone. Sure, I can customize and refuse some options, but the choices are limited and what guarantees do I get that a problem with one of the myriad of the options that I didn’t even pick, won’t affect my service? Reminds me of Liberty Mutual’ famous slogan: “only pay for what you need”. Does your cloud adhere to it too?
At this point it may also be interesting to point out that not all customers that already took the plunge and jumped on the public cloud bandwagon for one reason or another, hurry up to give up managing their Postgres database on EC2 or GCE on their own and over joyfully sign up for RDS, Aurora, AlloyDB, Cloud SQL or other managed database services. Here’s just one such example, but there are plenty of other similar experiences. Interesting, isn’t it? On the surface this looked completely counterintuitive to me, especially if you read a comparative analysis similar to this one. Indeed, one would think that if you already got to the promised land of a cloud somehow (read: major planning, major migration, major testing, probably an outage or two and more than a few other hiccups along the way), you’d want to take advantage of the cloud automation and offload the mundane tasks of taking backups and applying patches, no? Well, evidently that’s not true for everyone. Is it because of the markup price on managing your backups and patching or is it because one loses the “root” access and full control or because some flags and database options are not offered in the managed DBaaS or because of the perception of the “bloated” DBaaS with features not needed for my business or forced maintenances with limited flexibility/control or sub optimal performance compared to DIY on EC2 or …?
All those can be contributing factors (and there are a few similar ones too), but I have a different theory. In my opinion, there’s just no killer feature in the cloud provider’s DBaaS offerings, just the incremental quality of life improvements (like automated backups and patching). If you, as a cloud provider, can’t match my custom tailored and perfected over the years unique combination of server/storage/network/database setup and what you offer me instead is a generic, may be best in class, but not exactly highly customizable a-la-carte set of the database services, and on top of it jam pack it with features I don’t need… I may sit this one out.
There’s something that you can do for me however. As a cloud provider, you can uplevel the conversion. You can solve my problems at a different level.
How? Instead of talking about databases, talk to me about what matters to my business: data. But not just data as a theoretical, cloudy concept. My data doesn’t live in a vacuum. It’s consumed by the apps that allow me to sell the shoes and shirts to generate revenue. So talk to me about how fast and responsive my selling app is going to be if I migrate to your cloud, about its availability and the cost of running that app. You, as a cloud provider, should be able to figure out all he gory details regarding the data hosting to support my app behind the scenes on your own. Why should I care?
Indeed, as a business owner I’m happy to talk to you and to tell you everything about my shoes selling app’s requirements, that is my app’s QPS, latency, availability and anything else. That’s my business, I know it well and I would very much appreciate it if you talk to me in my business terms. Then you are free to translate it to SLOs, to RTO/RPO and to any other database requirements for you to host my data. Does a database to host my data need a sync HA solution across zones and a few read replicas and an ultra fast cache and an async DR in a different region? That’s up to you to worry about! Just make sure that my app, which sells my shoes and shirts, has three and a half 9s of availability overall, irrespective of your choices and your underlying infrastructure components (which obviously include a database). And, obviously, optimize for cost savings too and prove to me that my OpEx monthly bill won’t swing widely, eating half of my revenue.
This is a shift in mentality compared to the on-prem where CTOs are forced to talk about and define their requirements in terms of infrastructure, not in terms of the business objectives that they are to report to their board of directors.
Hosting and operating a database becomes somebody else’s concern entirely. I’m not offloading backups. I’m offloading the database (management) as a whole. What I’m left with is just data and the apps that consume it.
On the flip side, you, as a cloud provider, get to make all the underlying infra decisions for me. For compute, feel free to go with Skylake, Cascade Lake, Kaby Lake or perhaps Ryzen Threadripper and no, there’s no need to expose the PMC counters to me. And if behind the scenes you want to host my data on Exadata or on a distributed or a sharded database, make that database management autonomous or AI-driven or whatever… be my guest. I don’t need to know that. Heck, I don’t even need to know what database “shell” you decide to host my data in, be it AlloyDB Cloud, Cloud SQL Postgres, Spanner with Postgres compatibility, AlloyDB Omni running in GKE containers (for better bin packing, faster startup time, etc., etc.)… or any other database. All of these are your, as a cloud provider, choices to make. To me as a customer they become less than an implementation detail. All I need to know is an endpoint for data access.
This is a very different approach to what me and my CTO have to currently deal with in hosting my data on-prem.
To summarize: let me focus on what differentiates my business. There’s no spoon. Database is a “shell”, an implementation detail. Your, as a cloud provider, detail. Let’s talk about my app and my data instead. Talk to me about higher level data services that help me make better use of my data, not about your database lifecycle management that I shouldn’t care about.
If a database is a tax (on my/customer data) then that makes a DBA kinda like a tax collector. Well, I don’t know about your DBAs, but mine want to be more like Robin Hood (well, perhaps minus the part of permanently living in the woods… modern conveniences are hard to give up) and less like a sheriff of Nottingham. I want that for them too. I want to turn my DBAs into engineers that work with your cloud’s data services and help me get more value, more insights from my data. My data is unique, so help me make sense of it to sell more shoes (more on this later).
My “no database” cloud expectation (pet peeve?) that I presented here is the first on my wishlist, but I have more than a few others for cloud providers to offer, to make it easier for me to leave the on-prem world behind. And yes, I’m fully aware that I went on a bit of a tangent here (well, perhaps more than a bit), but I do hope to get to the answers of the original questions that I started this blog series with 🙂.
This post however already got long enough. If you made it all the way to here (thank you!) and if any of my ramblings resonate with you, please give me a shout, which would motivate me to write part 3 (OK, it’s an exaggeration, these blogs were already written six years ago, but I still had to make more than a few passes over these first two posts before publishing to bring it up to snuff, so I expect the same would need to be done for the other ones too).
Until then! See part 3 <link…>
⁷ I believe the term data gravity was coined by Dave McCrory in his famous database.com (now offline?) announcement by Salesforce.
⁸ This is clearly tongue-in-cheek as it’s totally not my intention to not show appreciation for all the hard work and dedication that the engineers at cloud providers invested into delivering us the cloud, productizing it, making it fully appropriate for hosting the most stringent, the most demanding and the most secure applications… basically into making cloud the mainstream. And yes, there are clear improvements to OSS products like adding a columnar engine to stock Postgres as part of the Google AlloyDB product. And yet, despite my exaggeration, I think my main point stands: my wishlist is more than a few items long and AFAIK the items on it are not yet available… or was I too deep in a rabbit hole to notice?
The Omni Database Engineering team at Google is the one that makes the magic presented in this blog series happen. I was the first, founding engineer, helped build the team, became a TL and later UberTL, so I believe I have a good perspective of why and how we approached the Operators and evolved them over time. Today, AlloyDB Omni K8s Operator is the production grade database management solution used by major banks, retailers and other customers and the eng team deserves all the credit.
I’d also like to thank Marc Fielding, Martin Nash, Aalok Muley, Hemanth Siddulugari, Sumaithri Mukkamalla, Gleb Otochkin, Justin Benton and Sridhar Ranganathan for reviewing these blog posts, correcting my broken English and my broken thoughts. All the remaining mistakes and inaccuracies are obviously still mine.
Databases on K8s — Really? (part 2) was originally published in Google Cloud - Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
..."En este sentido, sorprende constatar que en su comunicado no se realiza en ningún momento una petición expresa al Gobierno de Netanyahu instando a que pare la masacre y la barbarie que está sufriendo el pueblo de Palestina. Una realidad que debería interpelar a actuar con la misma contundencia que en el año 2022 ante la invasión de Rusia a Ucrania..."
etiquetas: uci, vuelta ciclista a españa, posición política
» noticia original (as.com)
Funcionarios europeos que participan en la organización del Festival de Eurovisión han comunicado "extraoficialmente" a los representantes israelíes que deben retirarse "temporalmente" del concurso o actuar bajo una bandera neutral, mientras se extiende la indignación por la participación de Israel antes de la votación de diciembre en Ginebra sobre si se permitirá al colonizador participar en el concurso del próximo año.
etiquetas: eurovisión, israel, sin bandera, dimita
» noticia original (www.thecanary.co)
Este vídeo de The Serial Port es un buen resumen de la historia del IRC, algo que originalmente existió fuera de la Web, inspirado en la red académica Bitnet en 1981. Allí se experimentó con los primeros sistemas de chat para personas conectadas a un mismo servidor; la idea se ampliaría a varios servidores formando una red. Por aquella época ya existía el CompuServe CB Simulator, un servicio de pago más cerrado
etiquetas: irc, chat
» noticia original (www.microsiervos.com)
Ha sido el presidente de EE.UU. quien ha ofrecido los detalles de este ataque en el que han muerto tres personas. El presidente estadounidense, Donald Trump, ha anunciado que Washington ha lanzado un segundo ataque contra un buque de un cártel de la droga venezolano que se dirigía a Estados Unidos. "Esta mañana, bajo mis órdenes, las fuerzas militares de EE.UU. han llevado a cabo un segundo ataque contra cárteles del narcotráfico y narcoterroristas extraordinariamente violentos, identificados positivamente, en el área de responsabilidad del....
etiquetas: ee.uu, ataca otra embarcacion, de venezuela, en aguas internacionales
» noticia original (www.rtve.es)
López señaló que gran parte de la culpa del problema está en los pisos turísticos: "Lo han destrozado todo. Vivienda particular no sale. He estado casi dos años buscando y a mí no me alquilaban."
etiquetas: crisis, alquiler, vivienda
» noticia original (www.elespanol.com)
València será la primera ciudad española que reciba a un equipo israelí en la Euroliga que arranca el 30 de septiembre.El club ya se ha puesto en contacto con Delegación de Gobierno y Euroliga para tomar medidas.
etiquetas: valencia, hapoel tel aviv, roig arena
» noticia original (www.levante-emv.com)
En un rincón de una antigua fábrica, ubicada en el sur de Massachusetts y construida a finales del siglo XIX, 15 personas trabajan en máquinas de coser, fabricando productos especializados de alta calidad para neonatología, destinados a hospitales. Son los únicos empleados que quedan de lo que antaño fue una gran empresa manufacturera, la mayor parte de la cual cerró en 1990, cuando la familia Teixeira reinventó su negocio como una empresa de almacenamiento y distribución.
etiquetas: aranceles de trump, perdidas en empresarios, eeuu
» noticia original (www.bbc.com)
Un barco arrastrero de Bueu se ha convertido por méritos propios en protagonista de las redes sociales tras haber sido grabado persiguiendo de manera notablemente arriesgada a la embarcación Walrus, de la ONG para la conservación de la fauna marina Sea Shepherd. Sucedió el pasado viernes, a unas 20 millas de las Islas Cíes, según ha explicado Thomas Le Coz, uno de los cinco tripulantes que iban a bordo del Walrus. Querían comprobar si en las redes del arrastrero aparecían delfines, como ya sucedió el pasado marzo. «Al arrastrero no le gustó...
etiquetas: persecución, intimidación, arrastrero, walrus, sea shepherd, delfines
» noticia original (www.vigoe.es)
El ayuntamiento de Girona ha colgado un retrato del rey Felipe VI en la sala de plenos hecho con un mosaico de fotografías del 1-O. "Acatamos pasando al ataque", ha subrayado el alcalde, Lluc Salellas, en referencia a la sentencia que obligaba a poner la imagen del monarca a raíz del contencioso interpuesto por Vox. Salellas ha asegurado que, a pesar de la "imposición" que les ha venido por parte de "la extrema derecha y la justicia española", han optado por esta fórmula imaginativa para reivindicar el referéndum de 2017.
etiquetas: ayuntamiento, girona, retrato, rey, sentencia, 1-o
» noticia original (www.segre.com)
Pello Bilbao (Gernika, 35 años) es ciclista profesional del conjunto Bahrain. Ausente este año de la Vuelta, ha seguido con intensidad todas las protestas propalestinas que se han producido en la ronda española. "[...]no entiendo la hipocresía de la UCI cuando con el Gazprom ruso tomaron una decisión distinta. No entiendo la diferencia." [...] "En el pelotón hay muchos compañeros que piensan igual. Yo diría que es la mayoría, pero nadie lo dice tan claro como yo, así que lo más sencillo es no pronunciarse y evitar situaciones incómodas."
etiquetas: la vuelta, israel, ciclismo, genocidio, bilbao
» noticia original (www.eldia.es)