Lessons learned in porting a .NET legacy application to SAP Cloud Foundry

In the age of self-driving cars, DNA editing tools and re-usable space crafts, a change in the traditional software development model was inevitable. Evolution of Cloud Foundry (CF) - an open source, multi-cloud application platform as a service (PaaS) - could be that change.

In the age of self-driving cars, DNA editing tools and re-usable space crafts, a change in the traditional software development model was inevitable.

SAP

Cloud Foundry services offers a lean, elastic, always-available, and self-healing development environment for the enterprise. Given these benefits, many organizations from Insurance (Allstate), telecommunication (Verizon, West Corp, T-Mobile), Clothing and accessories (Gap), engineering and electronics (Bosch) and governments (Australian Government, US Air Force) have switched to CF while many organizations are in the process of evaluating CF as their development platform.

For one such organization, we recently completed a short, 8-week proof of technology (PoT) project to port a custom .NET legacy application to CF on SAP Cloud platform. The core goal of the PoT was to showcase that the porting of the legacy .NET application to SAP CF was possible.

This post is an attempt to document the process followed, components involved, challenges encountered and the identified solutions to those challenges.

Objective

Re-platforming of .NET application to SAP Cloud Platform comprised following objectives:

Assessment of re-platform needs for legacy .NET application
While some re-platform needs were known, the objective was to figure out the unknowns
Converting existing .NET legacy application to .NET Core format supported by SAP CF
Making backend data available to re-platformed application in CF
Porting updated .NET application to SAP CF
Connecting re-platformed .NET application to backend data services

Components involved

Cloud Foundry on SAP Cloud Platform

CF is an open source, industry standard Platforms as a Service (PaaS) technology for developing and deploying cloud applications in both private and public cloud environments. It is designed to run on a variety of Infrastructure as a Service (IaaS) , such as Amazon Web Services OpenStack, Google Cloud Platform and Microsoft Azure. It enables developers to use different programming languages, runtimes and data/backing services.

CF is an open source, industry standard Platforms as a Service (PaaS) technology for developing and deploying cloud applications in both private and public cloud environments.

cloud

SAP is a founding, Platinum level member of the Cloud Foundry Foundation, which oversees the development of Cloud Foundry Software and ecosystem. SAP offers another cloud platform, Neo that runs Java, HTML5 and HANA XS applications.

SAP Cloud

Every CF installation comes with a standard set of language runtimes known as system buildpacks. However, SAP CF offers an additional buildpack, sap_java_buildpack.

Buildpack

During our project, CF .NET core buildpack was on version 1.0.32 which included .NET Core 2.0 – the latest one at that time. This was good news as the .NET 2.0 supports a bigger number of APIs as compared to previous versions.

Legacy .NET Application

Our legacy .NET application was built using .NET Framework 4.5.2 and was not ready for porting to SAP CF right away. In addition, the codebase also included Angular JS, D3.JS and Breeze JS.

The application was not 12-factor compliant at many levels. It was not micro-services based and relied on sticky sessions. Also, the data access was done using direct DB calls.

Process

Microsoft proposes following 5-point plan (See relevant link in the resources section) for porting an existing .NET application to .NET Core. I've elaborated each of these 5 points to document the process we followed.

Identify and account for your third-party dependencies.
We worked with the client for an initial list of all known third-party dependencies and later our talented developers extended that list by going through the codebase.
Retarget all projects you wish to port to target .NET Framework 4.6.2.
The purpose of this step was to ensure that API alternatives for .NET Framework-specific targets could be used in the cases where .NET Core didn't support a particular API.

The reference document that listed this process was written in June 2016 when .NET Core 2.0 was not available. Since .NET core 2.0 supports a much bigger number of APIs, we could have skipped this step but since it was not much time consuming, we did it nevertheless.
Use the API Portability Analyzer tool to analyze your assemblies and develop a plan to port based on its results.
As suggested, we ran the ‘API portability analyzer tool’ and the output was very helpful. Based on the tool’s output, our Dev team made changes to the code before moving on to the next step, port your test code.
Port your tests code
This is where our development team spent the most time. Over a period of 6+ weeks, they went through a rigorous trial and error process to iron out the code inconsistencies, to recompile the code, to re-write the data access routines and test it all, iteratively.
Execute your plan for porting!
Once the code testing was complete, our development team pushed the re-compiled app to CF in SAP cloud platform. Given the shortage of time, we could not leverage XSUAA service offered by SAP CF for application-level security.

Since our application was getting its data from a sandbox instance, it was not deemed a security concern. However, it is highly recommended that some kind of application level security be built into the application code.

Challenges and Resolutions

SAP Cloud Connector only supports HTTP protocol for SAP CF while HTTP, RFC, and TCP protocols are supported for Neo platform. Other protocols like ODBC are not yet supported for either CF or Neo platforms. (JDBC or ODBC proxy to access the HANA DB is supported for Neo but not for other DBs). Given that SAP is promoting Cloud connector as the de-facto integration layer for SAP Cloud Platform, it is imperative that the support for more and more protocols is added.
Lack of strategy for DevOps and CI/CD integration service options in SAP CF compared to PCF and IBM BlueMix (e.g. Concourse for PCF, IBM Bluemix DevOps Services). There is no clear recommendation of a CI/CD tool or strategy in SAP documentation yet. Since we were working on a small PoC, we did not leverage any CI/CD tool. However, with some effort, it is possible to use one of the well-known CI/CD tools like Concourse, Jenkins, Travis CI or GoCD.
At present, Enterprise support for buildpacks extends to Java buildpack only – all other buildpacks are not fully backed by SAP. We understand that Python and Node JS buildpacks are about to be supported soon but the enterprise support for buildpacks needs to go beyond these three. However, it is to be understood that all the buildpacks are supported by the talented CF community and we did not encounter any problems with the .NET buildpack.
Lack of documentation for buildpacks beyond Java - nearly all the example applications and code snippets in SAP websites (including open.sap.com) refer to Java buildpack. It is hard to find any example applications or code snippets for buildpacks like .NET Core. This may go back to the enterprise support. In absence of the SAP documentation, our Dev team utilized a number of other resources available on various websites, blogs, and forums.

Recommendations

To port a legacy .NET application to CF, it is recommended to follow the 12-Factor methodology. Most of the following recommendations apply to any legacy application porting however, some are specific to. NET. The context will clarify the difference.

Given the short timeframe for our proof-of-technology project, a complete re-writing of the legacy application was out of scope. However, we made the necessary code changes to port the application to SAP Cloud Foundry platform. For a full-blown porting project, converting the legacy applications to 12-Factor app is highly recommended.

SAP