Con su cuenta de Red Hat puede acceder a su perfil de miembro y sus preferencias, además de a los siguientes servicios teniendo en cuenta su estado de cliente:
¿Aún no se ha registrado? Le ofrecemos varios motivos por los que debería hacerlo:
- Consulte artículos de la base de conocimiento, gestione casos de soporte y suscripciones, descargue actualizaciones y mucho más desde una misma ubicación.
- Consulte los usuarios de la organización, y edite la información, preferencias y permisos de sus cuentas.
- Gestione sus certificaciones de Red Hat, consulte el historial de exámenes y descargue logotipos y documentos relacionados con las certificaciones.
Con su cuenta de Red Hat puede acceder a su perfil de miembro, sus preferencias y otros servicios dependiendo de su estado de cliente.
Por seguridad, si está en un equipo de acceso público y ya ha terminado de utilizar los servicios de Red Hat, cierre sesión.Cerrar sesión
I really dislike the term "legacy apps," especially when it is used by vendors. It feels like they are calling my baby (i.e. my app) with a bad name. I love the quote by Martin Fowler, "All we are doing is writing tomorrow's legacy software today." I am certainly not advocating to stick to your old applications forever. All applications and systems have a life-cycle that goes from build to retire. Somewhere in between lies the stage of renewing the capabilities of the system, often named as modernization, enhancement, or rehab. This is the most important phase from the perspective of extending the life of the application and enhancing the long term value harvested from it.
In IT, each generational transition has called for modernizing and redesigning applications, business processes and IT infrastructure to exploit new technologies' capabilities and efficiencies. App modernization isn't carried out as a fashion statement or status symbol but for hard business reasons. Regardless of the era, the benefits of a periodic app overhaul include better performance, more features, greater usability, and higher reliability.
While the need to modernize is obvious, the path to modernization is unique to each business. And choosing the modernization approach to go with can be difficult because there are several options. The key point is to keep your applications and its direction in alignment with business strategy. Sometimes, your business strategy might dictate that your legacy app requires a web presence; other times it may require just an interface with mobile-based applications. Other strategies may need the integration of new technologies like cloud deployment or API based integration.
Therefore, it is important to engage with business stakeholders and determine the gaps and shortfalls in existing apps. Here are some basic steps:
- Get the business involved, and keep the focus on customers experience (internal or external).
- Determine how users are accessing an application.
- Find out what kind of data users are seeking.
Today the technology shifts include cloud, big data, mobile and social. However, moving to the cloud, whether public or private, provides much greater impact for improving application scalability, deployment flexibility, responsiveness, and efficient use of IT resources. Cloud services also provide greater flexibility and agility in application provisioning, whether for development, testing or production deployment. By using a consistent set of services and APIs, the cloud inserts a portable abstraction layer between applications and infrastructure that allows apps to be easily moved to new locations, cloned for testing or non-disruptively updated. Such ease of app modification, testing, and deployment also enable new processes such as agile development, DevOps, and continuous integration and delivery.
Moving apps to the cloud can happen in several ways: lift and shift, connect and extend, or rearchitect and rewrite.
Lift and Shift
Lifting and shifting modernizes how existing applications are packaged and deployed. By lifting and shifting, existing components are deployed on a modern deployment platform. A familiar example is application virtualization, where the application is packaged with the operating system and run as a virtual machine instead of on dedicated hardware. Lifting and shifting is not intended to modernize the application architecture. Instead, it gets enterprises running on a modern deployment platform with a buffer of time to refactor the application later.
Lifting and shifting can be used to improve application performance by deploying on current and faster hardware. Applications become more flexible with simple deployment processes on modern platforms. Operational costs may be reduced too by retiring one-off servers and centralizing management.
Connect and Extend
Many firms create business value by delivering applications over new channels such as mobile and integrating with partner applications. Extending an application with new layers can help make existing application functionality accessible to new applications and conduits. This can also reduce development time and costs because the functionality does not have to be redeveloped. It is better to use complex and critical functionality where it exists, since it has been thoroughly proven over time.
As a software pattern, extending an application involves creating a new layer of application software that wraps the existing functionality and data with an interface that is accessible to new applications. To avoid introducing excessive complexity, the layer usually has no extra business logic but simply serves as an adapter between the new and the old.
Rearchitect and Rewrite
Rewriting an application is different than creating new applications from scratch; it is the process of creating new functionality to replace and retire existing applications. As part of an overall modernization strategy, rewriting can follow lifting and shifting and augmenting with new layers, and it is the only way to update the application architecture for a fully modern stack.
Rewriting an existing application is usually the least appealing option of the three. It is likely expensive, time-consuming, and may take years for costs to offset. Unless the application delivers new business value, rewriting it is hard to justify to executives with limited budgets.
When rewriting is the only way to go, migrate functionality off old applications gradually; augmenting with new layers can make that possible. It is also a good idea to delay rewriting because some functionality will become obsolete and will not need to be migrated at all. Resist the temptation to simply migrate old behaviors, and instead plan and prioritize as if developing a new application. This will help create applications that are more flexible and accommodating to the changes that will come.
Whatever approach is adopted, you will also need to be partnered with a trusted vendor that offers you products and services you can depend on. Red Hat uses a multiphase, iterative process for application modernization. The main objective is to create a plan and execute it multiple times, where each iteration results in new, incremental value. This reduces the risk associated with ripping and replacing.
To see what Red hat offers for app modernization, visit https://www.redhat.com/en/technologies/jboss-middleware/migrate.