The application transformation to the AWS public cloud for RFH

Royal FloraHolland’s query

There were several noticeable issues at Royal FloraHolland:

• The company was about to invest upfront in an on-premises data centre, plus management, which led to a reconsideration of the benefits of a cloud transformation;
• One section of Royal FloraHolland was in the process of setting up a new digital landscape in the AWS cloud;
• As a large investment was needed to update the applications’ software, questions were raised as to whether it would be better to implement this in the cloud.

In addition, there were a number of objectives that could be achieved by means of cloud transformation:

• Implementing pay-per-use: Royal FloraHolland’s business operations have a certain ebb and flow. For example, the company needs to respond to a significantly higher demand for its products on Valentine’s Day or Mother’s Day than on a day in January, for example. At that time, the company’s infrastructure was sized to accommodate the peaks, leaving it oversized on the quieter days;
• Accelerating time-to-market: Most infrastructure deployment and application generation activities were manual and could therefore be performed faster;
• Increasing quality: There were many ‘P1s’;
• Reducing complexity: There was a lot of shared infrastructure, which resulted in applications interfering with each other during incidents and updates. There were also many applications that were no longer in use, or which could be discarded.

The solution for Royal FloraHolland

Our application-focused approach puts the solution architects centre-stage. They achieved the following in their specific domain:

1. Taking stock of the current situation;
2. Designing the future situation according to the agreed frameworks, using cloud capabilities as much as possible, keeping costs at an acceptable level, and bearing future management in mind;
3. Guiding the teams by involving them in the cloud: Creating cloud scripts, a CI/CD pipeline, a customized code, a migration approach, a plan for deployment to production, and a ‘zero risk’ deployment to production.

In parallel, we expanded the AWS landing zone based on the requirements of the designed workloads, keeping just ahead of demand. We did this by setting up an enabler team who focused on creating reusable building blocks, and by organizing a daily stand-up meeting to briefly discuss the obstacles faced by the teams.

The result for Royal FloraHolland

While a project is being wrapped up, I always look at the quantitative and qualitative results. The quantitative results show that we:

• Have deployed over 125 applications and provided the underlying infrastructure. In many cases, we first archived the data in AWS;
• Have migrated more than 100 applications to AWS. That may not sound like much, but remember that this involved over 450 application components being brought to N-1 and adapted for the cloud, creating AWS scripts and a CI/CD pipeline for each application, and deploying the applications (sometimes phased) to production with zero risk. Of course, every outage is one too many, but it does make me very proud that we caused only one outage during that period;
• Furthermore, it became apparent that a number of applications – most of them logistics – couldn’t be moved to the cloud due to latency issues. Thankfully, there were far fewer of these cases than expected, meaning we could bring them to N-1 but in a new, on-premises environment. Surprisingly, a fairly large number of software vendors weren’t quite ready for the cloud and were therefore unable to guarantee that their software would be able to run on the cloud. As a matter of necessity, we also implemented these vendors’ products – a total of 13 applications and software packages – in the new, on-premises environment.

Quality

• All hardware and software products have been brought to N-1, so that they will be supported by the vendors for years to come;
• A number of obsolete technologies, including Powerbuilder, CA Gen, and Progress, have been phased out;
• All source code has been centrally consolidated;
• A CI/CD process has been set up for all applications, based on the same template, eliminating the need to log into the machines to perform management. It also means that new versions can easily be deployed to production;
• Logging, monitoring, backup, and archiving are set up uniformly, simplifying management activities. These are all implemented in reusable enabler building blocks made for generic management and other processes;
• In terms of security, we applied strict DTAP (Development, Testing, Acceptance, Production) stage separation, encrypted AWS resources, and restricted access to the machines to the bare minimum;
• Many AWS resources are disabled when not required, such as test environments in the evening and on weekends;
• And last but not least: the team members have made a huge leap forward and are now ready for the future.

Looking back at the objectives, this means that the desired pay-per-use has been implemented, the targeted time-to-market accelerated, the overall quality increased, and the infrastructure lock-in resolved. The landscape has also become more secure, more agile, and faster. It’s safe to say that this was a successful project!