Publicando al IBM i sin IBM

 Un comercial de una empresa americana que trabaja con el as400, hoy llamado IBM i, cansado de escuchar afirmaciones de que el equipo ya no se fabrica ni usa, decidió publicar una empresa por vez,  que usa el equipo en Estados Unidos. Una idea que responde a la inactividad de IBM respecto a un equipo que le ha dado mucho dinero en los 35 años que lleva evolucionando, y que no se merece lo que en la práctica parece un ocultamiento de parte de IBM. Si usted busca información de desarrollo sobre el equipo, le costará encontrarla: si pregunta por DB2, será redirigido a DB2 para el system z, si pregunta por utilidades de SQL, o facilidades para procesar JSON, será redirigido primero al system z, y sólo refinando la búsqueda logrará acertar. Todos los enlaces preexistentes a artículos muy valiosos y bien escritos fueron perdidos y no redireccionados hace unos pocos años atrás. Los materiales existen, pero sólo una paciente búsqueda le permitirá llegar a ellos. Lamentable para un equipo que no ha dejado de evolucionar y adquirir funcionalidades de primera línea, cuya velocidad de procesamiento se mantiene muy competitiva, y que mantiene una gran base de clientes, que no recibe educación. En fin, quizá a fuerza de no educar y ocultar, IBM consiga que el equipo no exista. 

Lo que dice Alex Woodie sobre este esfuerzo solitario:

If you are a consumer of mainstream news, it can be hard to find anything about IBM i. The proprietary business platform isn’t marketed by IBM in advertisements and it receives very little coverage in mainstream IT publications. But a salesman for an IBM i business partner has come up with an easy yet compelling way to boost the visibility of the platform.

Earlier this month, Josh Bander, who is an enterprise account executive at Briteskies, shared a recent conversation he had through his LinkedIn page .“Over the weekend, I spoke to a few of my friends in IT, and they all told me #IBMi is dead,” Bander said. “To prove them wrong, I plan to take pictures of items in my house made with IBM i for the next week.”

The first picture featured Bander’s car, a Honda. The Japanese carmaker’s US subsidiary, American Honda Motor Company, has used one or more IBM i servers at its Torrance, California, facility for years.

Day three brought an image of a shoe by Nike. The legendary Oregon company has been an IBM i shop since at least 2003, when Nike acquired Converse, and it was still using IBM i in 2021, according to the list of IBM i shops maintained by All400s.com, which Bander used for his project.

A range hood for a stove made by Broan-NuTone appeared on day four of Bander’s IBM i journey through his home. The Hartford, Wisconsin-based manufacturer, which makes a variety of fans and air quality products, is also a confirmed IBM i ship.

Do you have Kleenex in your house? If so, then you have a product made by an IBM i shop, as the Irving, Texas-based Kimberly-Clark, maker of the Kleenex brand of facial tissues, is another confirmed IBM i user.

What about Taster’s Choice? It may not be everybody’s favorite cup of joe – Starbucks, the coffee goliath from Seattle, Washington, is a longtime IBM i shop – but the iconic coffee brand has IBM i in its veins, since it is owned by Switzerland-based Nestle, which is the largest food company in the world and another IBM midrange system user.

Maybe you have some shipping labels lying around. If they’re made by Avery Dennison, the well-known manufacturer of shipping labels and packaging materials based in Glendale, California, then you’ve found another everyday product made by an IBM i shop.

You don’t have to live the California wine country life to shop at Williams Sonoma. But if you do buy from the popular retailer, you can rest easy knowing that at least some aspect of the San Francisco company’s business is managed by IBM i.

Another iconic American brand, Rubbermaid, is also an IBM i shop. The Atlanta, Georgia company, which is now owned by Newell, was known to have run the IBM i as of 2021.

Bander’s LinkedIn posts of household items made by IBM i shops attracted quite a bit of attention from the IBM i ecosystem, and the hashtag “IBMiEverywhere” began trending. Apparently, IBM i professionals enjoy seeing that well-run and world-famous consumer brands are longtime IBM i users.

So why doesn’t IBM do this, or something similar? We have pestered Big Blue server execs many times over the years about the lack of marketing and advertising support for the platform, and rarely come away with satisfying answers.

To IBM’s credit, it does write and run case studies about IBM i customers. It has a section of its website where it has around 100 case studies of IBM i customers, as well as stories about a few business partners. Honda is on that list, as well as brands like Carhartt and Lamps Plus.

But there are many, many more name-brand companies that rely on IBM i that have never been officially mentioned by IBM as customers. Some of the world’s largest and most profitable companies run at least a small part of their businesses on the IBM i system, and while that in itself is not a reason for other companies to follow suit, it at least shows that world-class companies are continuing to invest in it and that has value.

IBM execs often say they wish they could do more to tout the great companies that rely on IBM i, and there’s no reason not to believe them. The truth is, the companies themselves often are not interested in participating in a formal IBM case study, marketing campaign, or to be featured in actual advertisements – and if they are, they often expect something in return for their cooperation.

That makes rogue efforts like Bander’s all the more fun and entertaining. John Rockwell does his best to keep the All400s list up to date, and while there are companies on the list that are actively moving off the platform or planning to, there are plenty more that are happy customers that aren’t going anywhere.

In the end, sharing unofficial lists of companies that run on IBM i seems to be a good way to boost morale for the IT soldiers in the trenches, who hear a lot of FUD and may be questioning their choice of platform. As it turns out, there are a lot of great companies that continue to rely on the box, which continues to run business software reliability, securely, and efficiently decade after decade.

They may not be shouting their IBM i success from the rooftops. But sometimes actions speak louder than words.

 Visto en IT Jungle, en agosto.

 

 

El IBM i y sus capacidades actuales

 Dice Mike Pavlak: “At the end of the day, professionally I’ve worked in about six different languages. I can write bad code in every one of them,”

El contexto de la afirmación es interesante: el conjunto de recursos que hoy dispone el IBM i (¿o debemos decir IBM Power? ) para interconectarse con toda clase de recursos: PHP, Node, Python, sumados a los viejos conocidos de c. c++. java. Pavlak enfoca y evalúa la conveniencia de cada uno en función de conexiones con arquitecturas web, fundamentalmente, pero ese abanico de posibilidades puede ir más allá sin duda.

Dice Pavlak en particular sobre Node: 

Node.js isn’t as easy to learn for true-blue IBM i types, but it has one advantage over the other two: it uses JavaScript, which as previously noted has been broadly adopted by the wider IT world. However, there’s a caveat to the notion that Node.js developers only need to know JavaScript to be productive.

“A lot of people like Node because there’s a myth that I can use the same language on the presentation layer, JavaScript . . . up on the server,” Pavlak said. “And there’s truth to that. The syntax of the language is the same. What’s different though is the library usage. The libraries you’d use on the client end are not the libraries you would use on the server.”

Choosing Node.js makes sense in certain scenarios, such as when an IBM i shop has hired younger developers with JavaScript skills. Because the syntax is the same, these front-end JavaScript developers may be able to become productive developing back-end Node.js code on the IBM i server in a shorter amount of time than using other languages. “Using Node on the backend starts to make sense in that scenario,”

(...) Node.js does have a significant performance advantage over PHP and Python in on particular category: How quickly the stack starts. The technology, which was created by Google, is widely used by massive Web properties, such as Netflix. When you fire up a Netflix session on your TV, your Roku, or your phone, you’re actually initiating the deployment of a Node.js instance running on AWS.

“Node.js starts so fast, it’s so much easier to scale…horizontally,” Pavlak said. “So AWS instances are basically X86. In that scenario, Node has a decided advantage.”

 

Liam Allan habla sobre Node en IBM i

 Liam Allan, como Scott Klement, han dado un impulso formidable al IBM i (AKA AS/400, iseries), explorando, popularizando y explotando los sucesivos cambios tecnológicos habidos en el equipo desde hace años. El comentario sobre Node lo hace Liam en la entrevista que Charles Guarino le hace en TechChannel. La participación de Liam, reciente, ha implicado cambios radicales en el modo de encarar al IBM i, comenzando por su editor de programas. Debemos decir que el ambiente y las prácticas relacionadas con el IBM i históricamente han sido más vale conservadoras, apropiadas para un set de equipos que solía ser el núcleo del procesamiento de las empresas que lo usaban. Dice Guarino sobre este aspecto: I still think there’s still a lot of newbies—even the most seasoned RPG developers are still newbies—and open-source makes them nervous, perhaps because it’s a whole different paradigm, a whole different vernacular. Everything about it is different, yet obviously there are so many similarities, but the terminology is very different. Klement y quienes lo siguieron, y ahora Allan, han representado una renovación y actualización más que conveniente,  necesaria.

Por mi parte, dándole vueltas a su uso con Plex. Ya Klement ha potenciado su integración con sus propuestas a nivel de integración de lenguajes java y c/c++ a través de ILE.

 Lo dicho sobre Node:

Charlie: (...) So Liam, I do have a lot of things that I want to talk to you about, but when I think of you lately what comes to my mind is Node. I mean I kind of associate you with just Node and how you really are really running with that technology, especially on IBM i, but I think there are a lot of people who don’t quite understand where that fits in, what Node actually is and how it fits on your platform. So what can you say about that in general?

Liam: Absolutely. So I mean, there’s a few points to be made. I guess I’ll start with the fact that you know, it is 80% of my working life is writing typescript and Javascript. So I spend most of my days in it now, which is great. A few years ago, it was more like 50% and each year it’s growing more and more. So I usually focus on how it can integrate with IBM i. So you know having Node.js code, whether it’s typescript or Javascript talking to IBM i via the database—so, calling programs, fetching data, updating data; you know, the minimal standard kind of driver type stuff that you do, crud, things like that. What I especially like about Node on IBM i is that it is made for high input/outputs. It’s great at handling large volumes of data and most people that are using IBM i tend to have tons of data, right? Db2 for i has been around for centuries at this point; it’s older than I am, and I can make that joke. No one else can make that joke but I can make it and you know it’s been around for the longest time. And so people have got all of this data and in my opinion Node.js is just a great way to express that data—you know, via an API. I think it’s fast. It’s got high throughput and yeah, it’s a synchronous in its standard. It’s easy to use, it’s easy to deploy, it’s easy to write code for especially. One of the reasons I like is the fact that I can have something working within 20 minutes. It’s a fantastic piece of technology and it’s been out for a while. I mean it’s been out for like 10 years, 10 years plus at this point. It’s just fun to use. I really enjoy it and I encourage other people to use it too.

El concepto "Legacy" y la zanahoria "microservice"

 Lo que sigue es un artículo "viejísimo", del 25 de abril de este año. Lo copiaré y comentaré si es necesario, porque sigue siendo de rigurosa actualidad, tanto en el universo de IBM i, como en general:

Beware The Hype Of Modern Tech

Many IBM i shops are under the gun to modernize their applications as part of a digital transformation initiative. If the app is more than 10 or 15 years old and doesn’t use the latest technology and techniques, it’s considered a legacy system that must be torn down and rebuilt according to current code. But there are substantial risks associated with these efforts – not the least of which that the modern method is essentially incompatible with the IBM i architecture as it currently exists. IBM i shops should be careful when evaluating these new directions.

Amy Anderson, a modernization consultant working in IBM’s Rochester, Minnesota, lab, says she was joking last year when she said “every executive says they want to do containerized microservices in the cloud.” If Anderson is thinking about a future in comedy, she might want to rethink her plans, because what she says isn’t a joke; it’s the truth.

Many, if not most, tech executives these days are fully behind the drive to run their systems as containerized microservices in the cloud. They have been told by the analyst firms and the mainstream tech press and the cloud giants that the future of business IT is breaking up monolithic applications into lots of different pieces that communicate through microservices, probably REST. All these little apps will live in containers, likely managed by Kubernetes, enabling them to scale up and down seamlessly on the cloud, likely AWS or Microsoft Azure.

The “containerized microservices in the cloud” mantra has been repeated so often, many just accept it as the gospel truth. Of course that is the future of business tech! they say. How else could we possibly run all these applications? It’s accepted as an article of faith that this is the right approach. Whether a company is running homegrown software or a packaged app, they’re adamant that the old ways must be left behind, and to embrace the glorious future that is containerized microservices running in the cloud.

 The reality is that the supposedly glorious future is today is a pipe dream, at least when it comes to IBM i. Let’s start with Kubernetes, the container orchestration system open sourced by Google in 2014, which is a critical component of running in the “cloud native” way. (...)

While Kubernetes solves one problem – eliminating the complexity inherent in deploying and scaling all the different components that go into a given application – it introduces a lot more complexity to the user. Running a Kubernetes cluster is hard. If you’ve talked to anybody who has tried to do it themselves, you’ll quickly find out that it’s extremely difficult. It requires a whole new set of skills that most IT professionals do not have. The cloud giants, of course, have these folks in droves, but they’re practically non-existent everywhere else.

ISVs are eager to adopt Kubernetes as the new de facto operating system for one very good reason: because it helps them run their applications on the cloud. (...) 

For greenfield development, the cloud can make a lot of sense. Customers can get up and running very quickly on a cloud-based business application, and leave all the muss and fuss of managing hardware to the cloud provider. But there are downsides too, such as no ability to customize the application. For the vendors, the fact that customers cannot customize goes hand in hand with their inability to fall behind on releases. (Surely the vendor passes whatever benefit it receives through collective avoidance of technical debt back to you, dear customer.)

The Kubernetes route makes less sense for established products with an established installed base. It takes quite a bit of work to adapt an existing application to run inside a Docker container and have it managed in a Kubernetes pod. It can be done, but it’s a heavy lift. But when it comes to critical transactional systems, it likely becomes more of a full-blown re-implementation than a simple upgrade. There are no free lunches in IT.

When it comes to IBM i, lots of existing customers who are running their ERP systems on-prem are not ready to move their production business applications to the cloud. Notice what happened when Infor stopped rolling out enhancements for the M3 applications for IBM i customers. Infor wanted these folks to adopt M3 running on X86 servers running in AWS cloud. Many of them balked at this forced re-implementation, and now Infor is rolling out a new offering called CM3 that recognizes that customers want to keep their data on prem in their Db2 for i server.

Other ERP vendors have taken a similar approach to the cloud. SAP wants its Business Suite customers to move to S/4 HANA, which is a containerized, microservice-based ERP running in the cloud. The German ERP giant has committed to supporting on-prem Business Suite customers until 2027, and through 2030 with an extended maintenance agreement. After that, the customers must be on S/4 HANA, which at this point doesn’t run on IBM i.

Will the 1,500-plus customers who have benefited from running SAP on IBM i for the past 30 years be willing to give up their entire legacy and begin anew in the S/4 HANA cloud? It sounds like a risky proposition, especially given the fact that much of the functionality that currently exists in Business Suite has yet to be re-constructed din S/4 HANA. Is this an acceptable risk?

Kubernetes is just part of the problem, but it’s a big one, because at this point IBM i doesn’t support Kubernetes. It’s not even clear what Kubernetes running on IBM i would look like, considering all the virtualization features that already exist in the IBM i and Power platform. (What would become of LPARs, subsystems, and iASPs? How would any of that work?) In any event, the executives in charge of IBM i have told IT Jungle there is no demand for Kubernetes among IBM i customers. But that could change.

Particularmente interesante es el comentario acerca de los planes de Jack Henry & Associates:

Jack Henry & Associates officially unleashed its long-term roadmap earlier this year, but it had been working on the plan for years. The company has been a stalwart of the midrange platform for decades, reliably processing transactions for more than a thousand banks and credit unions running on its RPG-based core banking systems. It is also one of the biggest private cloud providers in the Power Systems arena, as it runs the Power machinery powering (pun intended) hundreds of customer applications.

The future roadmap for Jack Henry is (you guessed it) containerized microservices in the cloud. The company explains that it doesn’t make sense to develop and maintain about 100 duplicate business functions across four separate products, and so it will slowly replace those redundant components that today make up its monolithic packages like Silverlake with smaller, bite-sized components that run in the cloud-native fashion on Kubernetes and connect and communicate via microservices.

It’s not a bad plan, if you’ve been listening to the IT analysts and the press for the past five years. Jack Henry is doing exactly what they’ve been espousing as the modern method. But how does it mesh with its current legacy? The reality is that none of Jack Henry’s future software will be able to run on IBM i. Db2 for i is not even one of the long-term options for a database; instead it selected PostgreSQL, SQL Server, and MongoDB (depending on which cloud the customer is running in).

Jack Henry executives acknowledge that there’s not much overlap between its roadmap and the IBM i roadmap at this point in time. But they say that they’re moving slowly and won’t have all of the 100 or so business functions fully converted into containerized microservices for 15 years – and then it will likely take another 15 years to get everybody moved over. So it’s not a pressing issue at the moment.

Maybe Kubernetes will run on IBM i by then? Maybe there will be something new and different that eliminates the technological mismatch? Who knows?

The IBM i system is a known entity, with known strengths and weaknesses. Containerized microservices in the cloud is an unknown entity, and its strengths and weaknesses are still being determined. While containerized microservices running in the cloud may ultimately win out as the superior platform for business IT, that hasn’t been decided yet.

For the past 30 years, the mainstream IT world has leapt from one shiny object to the next, convinced that it will be The Next Big Thing. (TPM, the founder of this publication and its co-editor with me, has a whole different life as a journalist and analyst chasing this, called The Next Platform, not surprisingly.) Over the same period, the IBM i platform has continued more or less on the same path, with the same core architecture, running the same types of applications in the same reliable, secure manner.

The more hype is lavished upon containerized microservices in the cloud, the more it looks like just the latest shiny object, which will inevitably be replaced by the next shiny object. Meanwhile, the IBM i server will just keep ticking.

 Sin duda han habido cambios espectaculares en unos pocos años, los últimos cuatro o cinco, y existen herramientas y recursos disponbiles de gran potencia. Pero para una empresa o institucion en marcha, un cambio tiene que ser pesado con cuidado, evitando el riesgo de caer en el vacío. ¿Un cambio que requiere nuevas metodologías, nuevos lenguajes, nuevas platatformas, nuevas comunicaciones? ¿desarrollos con lo último de lo último, sin contar con la prueba de recursos robustos y experimentados por varios años?