domingo, julio 31, 2022

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.

domingo, julio 03, 2022

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?