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?
