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.
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.
Re-platforming of .NET application to SAP Cloud Platform comprised following objectives:
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.
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.
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.
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.
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.
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.
Originally published on February 4, 2018 by Vishwas Madhuvarshi on
Cloud Foundry environment within SAP Cloud Platform: FAQ
Porting to .NET Core from .NET Framework
A Brief Look at the .NET Portability Analyzer
The Twelve-Factor App