1

To rewrite or not to rewrite a software

To rewrite or not rewrite a software ?

Writing a software is a incredible difficult task. When the time has come for the software to know the retirement : should we rewrite it ? or have an progressive approach ?

TL;DR

Here are my thoughts on that subject.

In a previous article, I wrote about how to migrate a legacy software. I have planned, programmed, handled several software progressive migrations using dedicated tools in my career. I have created a small company Byoskill, to handle these subjects.

Since, I have been using some facts to decide between a full rewrite and a progressive migration.

The presentation below has been produced for a customer software some time ago and I will use it as an example.


Why writing a software is difficult ?

Let’s be honest together. Writing a software is incredibly difficult. Your latest framework choice won’t change the thing. Neither the most beautiful functional language.

A good software takes team players, the right environment, some skills and experience, efforts and luck. Capers Jones has written several interesting articles about the success and the failure of Software projects.

Probablity of On-time Software Delivery

Probablity of On-time Software Delivery

These tables illustrate the difficulty to lead to a successful project.

Probability of software project termination in six subindustries

Probability of software project termination in six subindustries

Capers Jones interesting articles here and here.

My first argument to be taken into account in the debate pro or con rewrite is the following :

A legacy software is a software that had enough success to ages. Thereby a convergence of facts allow ed him to born, grow up with new features, get fixed and finally ages.

My second motivation based on Capers Jones observations and a lot of similar experiences I encounted in the business of software migration.

Big software projects aka big rewrite are doomed to fail.

The fluctuating market

The conditions that enables the current software to live have probably changed in the recent years. Basically, our software is fighting against the following tendencies :

    • Complexity is the software is increasing
    • Market is not waiting for releases and its appetite is growing for new features
    • Disruption is everywhere : competitors, startups , pricing war
    • ROI law has changed in favor of the scalability and the  number of users rather than higher license prices
    • Low-qualified workers used for maintaining an existing software  are not a appropriate answer to create state of the art technologies.
    • Creating new software (aka rewrite) requires true software leaders and informed product owners
    • Change management is a tricky and nasty affair

The situation has to be evaluated precisely. Will your customers wait for this brand new version ? How will you managed their expectation for the new features ?

Can all the software be saved ?

This tricky question is probably the real rationale behind the pro/con debate in favor of a rewriting.

Basically you have three choices in front of you :

Software migration choices

Software migration choices

Outsourcing developments

The easiest and safest choice for a manager. To not decide anything 🙂

Basically, transfer your legacy software to a company that will promise cheaper rater and cost. Keep the possibility to switch when the outsourcing company will increase their rates.

Blame them and plan your future new projects while keep the cost indicators low for the current solution.

Sole problem : you do not know when you will be able to launch the new projects. Your budget is most likely melting as your maintenance cost.

The Big Rewrite

 

The Big Lebowski

The Big Lebowski

To enable a big rewrite, you need to basically have the following warranties :

  • You have enough time to build your new software
  • You have the full endorsement of your customers, your users and your stakeholders
  • Your business knowledge is perfect and synchronized with the current market need
  • Your users are not expecting the same software ( features, workflow and yes bugs)
  • And all basic conditions to lead a project (cleancode, software craftmanship)

I believe that a successful rewrite project is basically not a rewrite.I would even recommend to not call it “new version” of the product. Rather a new name, a new UI, a new customer/user journey. Calling it a new version of a product where most of the features are missing is always a bad idea.

Progressive migration and automatic migration

Even if these two approaches are fundamentally different, the progressive migration and the automatic migration shares the same goals.

The goals to achieve could be the following ones :

  • Reduce the time of migration : shorter is the project, higher will be the success probability
  • Keep the most useful features, saves money for the new ones
  • Performs critical technical debt operations
  • Avoid any complications in the change management (political issues, conservative users)

I would recommend these scenarios when you have optimal working conditions. Indeed you will have to handle some highly technical software re-engineering.

  • a great motivated team
  • a supporting management (refers to point 1)
  • a whole set of features
  • difficult constraints (time, political, market)
  • some experimented programmers and architect oriented.
  • a evolutionary technology stack allowing easy interactions with a new stack (no proprietary languages, no 4GL)
  • possibility of functional data layering

This article has been already too long to detail the refactoring steps.  I will encourage you to reed the other articles on my blog like this one for a preview.

I hope you will have learn one thing or two about the decision process about rewriting a software. If you have arguments in favor or against what I have advised it, please let a comment!

All these informations are extracted from my experience with byoskill.com. I am offering cleancode courses and support for automatic software migrations.

1

How to do a legacy software migration : a successful checklist

Legacy Software migration

Here is a small checklist about how to migrate a legacy migration and to ensure its success.

This article is part of my work to explain my knowledge about Software migration in the company Byoskill.

Continue Reading

0

How to make a software developer happy ?

Leave your comfort zone

To be or not to be (happy), that’s the question. In this article, I expose some thoughts about what could make a software developer happy in his work. I wrote this article with several targeted audience in mind : Junior developers, Senior Techleads and H&R resources.

Continue Reading

0

How migrate from JBoss 5 to 7

This article is part of my working notes on the subject of "How to migrate Web applications running on JBoss AS 5 to the version 7".

JBoss Application Server – Wildfly

I will go straight to the details though here is some lines about JBoss Server.

From Wikipedia : JBoss Application Server(Now called Wildfly) is an application server authored by JBoss, now developed by Red Hat. WildFly is written in Java, and implements the Java Platform, Enterprise Edition (Java EE) specification. It runs on multiple platforms.

On 20 November 2014, JBoss Application Server was renamed Wildfly.

The product history according Wikipedia is :

  • 5.1 Release 23 May 2009
  • 7.0[10] Release 12 July 2011
  • 7.1 Release February 2012
  • 10.1.0 Release August 2016[20]

The JBoss AS community project has been renamed to the WildFly community project wildfly.org

According this JBoss 5 to 7 in 11 steps, the benefits are :

Processing time decreased by 25% without any code change. Development speed increased in my opinion (it is really hard to measure it) by 50% and we are much more productive (faster server restarts). Memory footprint lowered from 1GB to 512MB. Finally automatic application redeployment finally works! However there is always a price to pay – the migration took us 4 weeks (2 sprints).

Thanks to the presentation from Roberto Cortez, we have a clear picture of the migration.


JBOSS 5 Architecture

JBOSS 5 Architecture

JBOSS 7 Architecture

JBOSS 7 Architecture

The checklist

Prepare the checklist

When the PAAS or the Web application server have to be upgraded, several regressions may happen. The team has to pay attention to :

  • Server functionalities and integration : Performance, Security, Logging, Monitoring
  • Server configuration
  • Server deployment configuration
  • Application deployment configuration
  • Server API regressions
  • Application regressions
  • Training and risk management

Server functionalities and integration : between the versions, some functionalities and integrations provided by the server may have evolved, be fixed or simply disappeared.

Server configuration : The way the server has been configured, using scripts, GUI, may have changed, forcing the team to change their configuration files and finding the corresponding new way of doing it.

Server deployment configuration : Your deployment model configuration may have to be upgraded : single node, clustered mode, disaster recovery, high availability, reverse-proxying may behave differently in the new versions.

Application deployment configuration : the way to deploy your web applications may have changed in the new versions (GUI mode to script mode…)

Server API Regressions : usually Web Application servers are implementing a specific JEE API version, Servlet API and so on. These API may have changed causing regressions in your applications.

Application regressions : JBoss is including many components extending the JEE with BPM, Persistence, implementation. It is really important to track your dependencies (using Tattletale or mvn dependencies:tree) and interview your team about possible hacks and fixes to overcome the limits of JEE 5. This kind of workaround is difficult to migrate.

Training and risk management : This kind of migration contains its part of risks and changes. Both can create frictions inside your team of between the IT Team and your Dev teams. To ease the migration, don’t forget to dedicate some time to your teams into training to learn the new features of JAS 7. You will also have to adapt your project management to freeze for a while the features until the migration has been done.

Global checklist

This section is providing a checklist to help developers and managers to evaluate the migration risk of their applications.

 Common issues

Here is a list of common issues during the migration of applications with JBOSS AS.

4.2. Debug Migration Issues 4.2.1. Debug and Resolve Migration Issues 4.2.2. Debug and Resolve ClassNotFoundExceptions and NoClassDefFoundErrors 4.2.3. Find the JBoss Module Dependency 4.2.4. Find the JAR in the Previous Install 4.2.5. Debug and Resolve ClassCastExceptions 4.2.6. Debug and Resolve DuplicateServiceExceptions 4.2.7. Debug and Resolve JBoss Seam Debug Page Errors

  • There is a deadlock when using EJB remoting over SSL. This deadlock is present even in EAP 6.2. We’re now at the point when we have quite a patch set of features backported from WildFly to AS 7.

  • JMS : JBoss Messaging server has been deprecated and the compatibility with a JBOSS AS 5 server is really tough to maintain. Some solutions exists as explained below in the article.

 What is changing ?

Here is a summary of the evolutions between the JBoss AS version 5 and the version 6.

 JBOSS AS 6 changes

Here is the compiled list of modifications including the minor version fixes.

  • [Server functionality, Server API, Application regressions] Module based class loading

In JBoss Enterprise Application Platform 5, the class loading architecture was hierarchical. In JBoss Enterprise Application Platform 6, class loading is based on JBoss Modules. This offers true application isolation, hides server implementation classes, and only loads the classes your application needs. Class loading is concurrent for better performance. Applications written for JBoss Enterprise Application Platform 5 must be modified to specify module dependencies and in some cases, repackage archives.

  • [Server functionality, Server deployment configuration] Domain Management : In JBoss Enterprise Application Platform 6, the server can be run as a standalone server or in a managed domain.

  • [Application Deployment] Deployment Configuration : Standalone Servers and Managed Domains : Boss Enterprise Application Platform 5 used profile based deployment configuration. These profiles were located in the EAP_HOME/server/ directory. Applications often contained multiple configuration files for security, database, resource adapter, and other configurations. In JBoss Enterprise Application Platform 6, deployment configuration is done using one file. JBoss Enterprise Application Platform 5 configuration files must be migrated to the new single configuration file.

  • [Server functionality, Application deployment configuration] Ordering of deployments : Application Platform 5 applications that consist of multiple modules deployed as EARs and use legacy JNDI lookups instead of CDI injection or resource-ref entries may require configuration changes.

  • [Server functionality, Application deployment configuration] Directory Structure and Scripts : As previously mentioned, JBoss Enterprise Application Platform 6 no longer uses profile based deployment configuration, so there is no EAP_HOME/server/ directory.

  • [Server application, Application deployment configuration, Application regression JNDI Lookups JBoss Enterprise Application Platform 6 now uses standardized portable JNDI namespaces.

  • [Server functionality, Server configuration, Application configuration, Application code] : Changing logging dependencies

  • [Server API, Application configuration regressions] Resource adapter configuration : In previous versions of the application server, the resource adapter configuration was defined in a file with a suffix of *-ds.xml. In JBoss Enterprise Application Platform 6, a resource adapter is configured in the server configuration file.

  • [Server libraries] Technologies upgrade : JDK 6, JSF 2, Bean Validation (JSR-303), CDI, EJB 3 (1.1.13)

  • Include mod_cluster
  • Servlet API 3.0
  • Update CL to 2.0.8.GA
  • Update Deployers to 2.0.9.GA
  • Update Javassist to 3.11.0.GA
  • Update JBossWS to 3.2.1.GA
  • Update JBossXB to 2.0.2.Beta3
  • Update JGroups to 2.6.13
  • Update Kernel to 2.0.9.GA
  • Update MC-INT to 2.2.0.Alpha2
  • Update MDR to 2.0.2.GA
  • Update to Entity Manager 3.5 and JPA 2
  • Update to JBoss AOP 2.1.6.GA
  • Update VFS to 2.2.0.Alpha1
  • Upgrade apache-beanutils to 1.8.0
  • Upgrade ha-server-cache-jbc to 2.1.0.GA
  • Upgrade JBoss Cache to 3.2.1.GA
  • Upgrade jboss-common-core to 2.2.16.GA
  • Upgrade jboss-ha-server-cache-jbc to 2.0.1.GA
  • Upgrade JBoss JAXR to 2.0.1
  • Upgrade JBoss LogManager to 1.1.0.GA
  • Upgrade JBoss Security 2.0.4.SP2
  • Upgrade JBossXACML to 2.0.4
  • Upgrade JSF to 2.0.0-RC
  • Upgrade to Java Mail 1.4.2
  • Upgrade to JBossXACML 2.0.3.SP2
  • Upgrade XNIO Metadata to 1.0.1.GA
  • New library JBossWS-CXF
  • library update RestEasy
  • JBoss Messaging JMS & MDB replaced by Hornet MQ
  • New RMI Framework : Remote 3
  • VFS Library update

  • [Server functionalities] new server functionalities : Mod_cluster, JBoss Embedded AS

  • [Application deployment] The legacy pooled invoker has been removed. Applications using the pooled invoker should switch to the JBoss Remoting-based unified invoker, which has been the default detached invoker since 4.2.

 JBOSS AS Release 7

Here is the compiled list of modifications including the minor version fixes.

  • [Server functionality, Application regressions] Security improvement

Unlike previous releases, with AS 7.1, remote access requires secure authentication by default. This includes both managment (native, jmx, etc) and various remote application protocols (ejb, jndi, jms, etc); Added SSL support for the Remoting interfaces.

  • [Application configuration deployment] Management API improvements : All configuration attributes are updatable via the CLI. Direct edits to the XML are not necessary.

  • [Server functionality] Various Administration Console Improvements and Management changes

  • [Server API] Remote Connectivity Added support for remote EJB, JNDI and JMX invocation over JBoss Remoting 3, IIOP, Remote JMS. Three modes for accessing remote EE components using JNDI (Client, Traditional Remote, and Delegated).

  • [Server deployment model] Clustering Enhancements : Standalone Servers and Managed Domains : Numerours fixes in HTTP Session Replication, Clustered Web SSO, EJB Stateful Session Bean Replication, EJB load-balancing and failove, JPA XPC propagation

  • [Server functionality] CLI Regressions jboss-admin.sh renamed to jboss-cli.sh, data-source add" "--pool-name" argument seems to have changed to "–name".

  • [Server libraries] Technologies upgrade :

  • EJB 3.1 Full – Adds a number of key features, including remote communication, asynchronous method invocation, timers, message-driven beans, and legacy compatibility with EJB 2.
  • CMP 2 – Provides a legacy persistence manager which predates JPA. This is benefical to legacy applications which make use of EJB 2.x Entity Beans.
  • JAX-WS 2.2 – Allows simplified usage of Web Services in the EE platform.
  • JAX-RPC 1.1 – Offers legacy support for older Java EE Web Services applications.
  • JAX-RS 1.1 – Supports the construction of RESTful Web Services using the Java EE platform.
  • JavaMail 1.4 – Allows Java EE applications to send and receive e-mail
  • JCA 1.6 – Provides a mechanism for third parties to provide support for custom data sources, as well as connection pooling and transaction management for database access.
  • JMS 1.1 – Adds advanced messaging support to EE applications.
  • IIOP – Supports interoperablility with other application servers and non-Java CORBA clients.
  • JSR-88 – Allows for managing deployments to a Java EE server in a portable fashion.
  • Update mod_cluster to 1.2.0.Final
  • IronJacamar 1.0.7.Final
  • Upgrade Infinispan to 5.1.0.CR3
  • Upgrade to JBossTS 4.16.1
  • Upgrade jboss-metadata to 7.0.0.Beta33
  • Upgrade JGroups to 3.0.3.Final
  • Upgrade JBoss Marshalling to 1.3.6.GA
  • Upgrade httpcore to 4.1.4
  • Upgrade to JBossWS 4.0.1.GA and Apache CXF 2.4.6
  • Update to classfilewriter 1.0.1
  • Upgrade to JSF 2.1.7
  • Upgrade PicketLink to 2.0.2.Final
  • Upgrade PicketBox to 4.0.7.Final
  • Upgrade commons-beanutils to 1.8.3
  • Upgrade Google Guava to 11.0.2

  • [Server functionalities] new server functionalities : Mod_cluster, JBoss Embedded AS

  • [Application deployment] The legacy pooled invoker has been removed. Applications using the pooled invoker should switch to the JBoss Remoting-based unified invoker, which has been the default detached invoker since 4.2.

  • [Server functionalities] new server functionalities : Mod_cluster, JBoss Embedded AS

  • [Application deployment] The legacy pooled invoker has been removed. Applications using the pooled invoker should switch to the JBoss Remoting-based unified invoker, which has been the default detached invoker since 4.2.

How to migrate : plan and tasks

  • JDBC configuration
  • Classpath references
  • Global Modules Reference
  • JMS migration :

According link, we thought it would be really hard to connect with JMS server based on JBoss 5. It turned out that you have 2 options and both work fine:

  • Start HornetQ server on your own instance and create a bridge to JBoss 5 instance
  • Uses a JMS Bridge to move the existing messages
  • Use Generic JMS adapter: https://github.com/jms-ra/generic-jms-ra

 Application packaging and configuration

  • Repackaging Dependencies and fix the EAR Layout: link

  • Install and configure the JDBC Driver link

  • Update the Resource Adapter Configuration

  • Configure the datasource for Hibernate and JPA : If your application uses JPA and currently bundles the Hibernate JARs, you may want to use the Hibernate that is included with JBoss Enterprise Application Platform 6.

In WildFly 8, a resource adapter is configured in the server configuration file. If you are running in domain mode, the configuration file is the domain/configuration/domain.xml file. If you are running in standalone mode, you will configure the resource adapter in the standalone/configuration/standalone.xml file.

More details there How to migrate from AS5 or AS6 to Wildfly

  • Migration of the shell scripts, integration test scripts, deployment scripts.

Application code and configuration migration

Here is the list of tasks implying some rewriting inside your application code.

  • Migration JEE 5 to JEE 6

  • Upgrade to JPA 2.0

  • Update your SOAP Implementations using JBossWS-CXF

  • Upgrade Hibernate from 3 to 4

  • Replacing JBOSS Cache by Infinispan Cache

  • Configure JAX-RS / Resteasy changes

  • Fix Hibernate’s sequencer

  • Replace JBOSS AOP Interceptors : JBoss AOP was used by the EJB container. However, in AS 7, the EJB container uses a new mechanism. If your application uses JBoss AOP, you need modify your application code as follows.

  • Migrating JNDI : Migrating JNDI namespaces

  • Update the datasources : link

  • Rewriting of your RMI Code : oss 5 and 7 are totally different and this kind of communication will not work.

  • Using CDI instead of plain old Singletons

 Tooling

Here is a list of useful tools to assist you in your migration.

  • IronJacamar : to update your datasource configuration

  • Tattletale : to find the application dependencies

  • Gilder : An application for migrating the configuration of JBoss AS 5-based servers to JBoss AS 7-based servers.

  • Tools and tooling to migrate to JBOSSS 6 : Link

  • Upgrades to newer versions of WildFly or JBoss EAP may be handled using the JBoss Windup migration tool. JBoss Windup migration tool

 References:

0

How I switched my blog from OVH to Google Container Engine

In this short story, I will relate how I migrate my blog personal website from a classic VM instance to a container using Google Cloud Container Engine and  Kubernetes, Docker, Nginx.

Continue Reading

3

How Docker is disrupting Legacy IT Companies

Thanks to its popularity, Docker has disrupted many companies and blurred the silos between Developers and Operations. In this article, based partially on my own experiences.

Continue Reading

2

The disappointing quest for an Headless CMS in 2017

In 2017, this blog is powered by Hexo.js. However I am looking for a replacement since Hexo.JS is lacking of crucial features.

Continue Reading

1

Codacy : an easy-to use code quality review solution

Codacw tendancy analysis

Some time ago, I organized a talk on “Code Quality and why developers should care about” for my company. In that presentation, I demonstrate some tools, unfamiliar for the audience : young developers and battle-hardened IT developers.

One among these tools has brought to me a lot of questions : Codacy. I will present its features and perform a comparison between Codacy and SonarQube from SonarSource.

Continue Reading