User Tools

Site Tools


a2:2:computacion_en_la_nube

Computación en la nube

En nuestras organizaciones, el volumen de datos crece exponencialmente, siempre a mayor ritmo que los sistemas que utilizamos para tratarlos. Por eso, surgen nuevas estrategias de aproximación a su tratamiento. Estrategias de procesamiento distribuido, bases de datos columnares, aprendizaje automático, etc. son diferentes acercamientos a la búsqueda de respuestas que nuestros organismos requieren.

Dentro de estas estrategias de optimización de recursos, aunque con un éxito moderado en la administración, se está intentando reducir el coste de propiedad (ese “tco” que tantas veces habréis visto), trasladando los sistemas, servicios, bases de datos, etc. a la nube. Posiblemente, el ecosistema de bases de datos y su análisis sea uno de los más difíciles de mover a la nube, al tiempo que uno de los que mayor beneficio puede ofrecer con su traslado.

Existe un debate muy interesante, principalmente en el nivel técnico al que pertenecemos, sobre dichos beneficios e inconvenientes. Entre ellos:

  • Bajo alguno de estos niveles de servicio, parece lógico pensar que nunca más tendremos que preocuparnos de pasar un parche, reiniciar un servidor, conectar el almacenamiento, configurar un cluster en ubicaciones remotas…
  • Cuando diseñamos y configuramos nuestro propio entorno, y estamos dedicados a optimizarlo, estamos en disposición de sacarle el máximo partido para nuestra organización.
  • El personal de sistemas y de seguridad, ¿Debe reconvertirse en un CAU de primer nivel? ¿Qué pasa con el conocimiento de gestión de configuraciones, CPD's, centros de respaldo, firewalls, etc.?
  • Si tenemos -como ocurre en muchas organizaciones-, bases de datos que no pueden ser movidas, o que lo serán en última instancia, ¿No complica nuestra infraestructura llevarse los servicios de análisis -por ejemplo- a la nube?

¿Cuál es vuestra opinión? En vuestros centros habituales, ¿Hay servicios en la nube? ¿Bajo qué modalidad? ¿Qué opinión os merecen? ¿Qué nueva problemática generan? Y si no los hay, ¿Por qué? ¿Qué impedimentos, no solo técnicos, han llevado a que no se muevan servicios a la nube?

¿Self hosting?

“Lambda and serverless is one of the worst forms of proprietary lock-in” (2017) - https://news.ycombinator.com/item?id=19080875

My best-practice advice is to do the math. What is the margin on infrastructure vs. the acquisition and management costs of the engineers necessary to operate the infrastructure.

Serverless doesn't scale very well in the axis of cost. At some point that's going to become an issue. If one has gone “all-in” on vendor lock-in then that vendor is going to spend as much time as possible enjoying those margins while the attempts to re-tool to something else is underway.

Best practice, generally speaking is to engineer for extensibility at some point, fairly early on.

Self hosting doesn't scale

That's just not true. There are plenty of companies that self-host highly scaling infrastructure. Twitter being just one of those companies. They've only recently started thinking about using the cloud, opted for Google, and that's only to run some of their analytics infrastructure.

There is very little reason for a good sysadmin to work for International Widgets Conglomerated when they can work for a cloud provider instead, building larger scale solutions more efficiently for higher pay

That's not true either (speaking from personal experience working for companies of all sizes, from a couple dozen employees on up to and including AWS and Oracle on their cloud platforms). For one thing, sysadmin is far to broad a job role to make such sweeping statements.

A whole bunch of what I do as a systems engineer for cloud platforms is a whole world of difference from general sysadmin work, even ignoring that sysadmin is a very broad definition that covers everything from running exchange servers on-prem, to building private clouds or beyond.

These days I'm not sure I've even got the particular skills to easily drop back in to typical sysadmin work. Cloud platform syseng work requires a much more precise set of skills and competencies.

All that aside, I can point you in the direction of plenty of sysadmins who wouldn't work for major cloud providers for all the money in the world, either for moral or ethical reasons; or they're just not interested in that kind of problem; or even just that they don't want to deal with the frequently toxic burn-out environments that you hear about there.

I'd rather buy an off the shelf service used by the rest of the F500 than roll my own.

No where near as much of the F500 workload is on the cloud as apparently you'd believe. It's a big market that isn't well tapped. Amazon and Azure have been picking up some of the work, but a lot of the F500 don't like the pay-as-you-go financial model. That plays sweet merry havoc with budgeting, for starters. It's one reason why Oracle introduced a pay model with Oracle Cloud Infrastructure that allows CIOs to set fixed IT expenditure budgets. Many of the F500 companies are only really in the last few years starting to talk about actually moving in to the cloud (when OCI launched at Oracle OpenWorld, there was a startling number of CIOs from a number of large and well known companies coming up to the sales team and saying “So.. what is this cloud thing, anyway?”

Successful companies outsource their non core competencies

Yes.. and no. Successful companies outsource their non-core competencies where there is no value having them on-site. That's very different.

Twitter was founded in 2006, the same year AWS was launched, so in the early days Twitter didn't have a choice - the cloud wasn't yet a viable option to run a company. And, if you remember in the early days, Twitter's scalability was absolutely atrocious - the “Fail Whale” was an emblem of Twitter's engineering headaches.

That's because Twitter was:

  1. A monolith
  2. Written in Ruby

They started splitting components up in to specialised made-for-purpose components using Scala atop the JVM, and scaling ceased being a big issue. The problems they ran into couldn't be solved by horizontal scaling. There wasn't any service that AWS offers even today that would have helped with those engineering challenges.

Referencias

a2/2/computacion_en_la_nube.txt · Last modified: 2021/10/07 14:10 by jherrero