From WCF on-premise to Azure App Service. Part I

Summary

During the last few months, I have been working on migrating a Windows Communication Foundation Service to Azure App Service, this post series summarizes a few learning lessons and references for the case of moving legacy .Net 4 WCF Services to the cloud with Azure App Services.

Background

Windows Communication Foundation (WCF) Service

A WCF Service is an important part of the .Net Framework 4 ecosystem, creating a clear separation between what the program does (Contract), how it does it (Binding), and where it is located (Address) allows all kinds of combinations, from security, channels, protocols, containers of the service (IIS, Console App, Windows Service).

A very interesting offer from Microsoft and the .Net Platform, WCF is also one of the most complex tools (and difficult to set up correctly) ever created. I used to say to our developers and customers:

a WCF Service is 15 minutes of coding, and 45 minutes of setup.

One common case for WCF Services is HTTPS endpoints that expose XML (SOAP) or JSON (REST) responses. (note: you can have REST returning XML but is very uncommon and SOAP returning JSON would be just a JSON fragment inside a SOAP envelope but that's another horror story for another day. )

When a WCF Service has an HTTPS endpoint is almost always hosted on Internet Information Service (IIS) (with Window Activation Service WAS).

And anything hosted on (Internet Information Service) IIS is a good candidate to move to Azure App Service.

Azure App Services

Azure App Services is a serverless offer to run web apps on the Azure Cloud, from .Net to Node.js, PHP, Phyton, or Java.

From our standpoint Today, Azure App Service is basically IIS on the Cloud without worrying about the underlying Windows OS and infrastructure.

The Migration

WCF ABC

The Windows Communication Foundation (WCF) ABC (Address — Binding — Contract) would just work on the Azure App Service offer if you have a clear understanding of the 3 elements.

Address

Azure App Services will provide an address to your service in the form of

yourservicename.azurewebsites.net, and then you can use a custom domain to make the service yourservice.yourdomain.com. No big deal here.

Bindings

Don’t you love bindings? they describe the pipe. How are you connecting to your service, what protocol, for how long, what restrictions, what security, what behaviors, and of course what endpoints will be available.

So many options that would be impossible to go over each one of the scenarios, but having this in mind would help: Azure takes care of the certificate on their domain, and you can add your custom domain and custom certificate to the Azure App Service.

Now you can have HTTP with secure transport in 2 minutes, your Azure Function App (aka WCF Service) is now encrypted from the consumer to the server. (is that enough? probably not, but is better than having any middleman listing to any service petition and response)

Sample of HttpBinding with SSL (HTTPS) on Azure App Service.

 
                                receiveTimeout="00:10:00" sendTimeout="00:01:00" 
                             allowCookies="false" bypassProxyOnLocal="false" 
                             hostNameComparisonMode="StrongWildcard" 
                             maxBufferPoolSize="524288" 
                             maxReceivedMessageSize="65536" 
                             textEncoding="utf-8" 
                             useDefaultWebProxy="true" messageEncoding="Text">
     
   
 

Contracts

Everything should work just fine on your contracts (code).

Just remember that you don’t have an underlying storage (hard drive) (you have one, but that's for another day).

If your service does calculations and calls databases to return objects or connect to other services, well, you should be able to move your code easily.

All your regular goodies from WCF are allowed and needed. (Service contract decorations, Operation Contract Decorations, Fault Contracts, and Message Names)

App Settings.

Your app settings are still on the web.config File, but also shows on the settings/configuration/application settings menu of the App Service on Azure.

To access them from your code, prefer the configuration Manager for, ie:

var logLevel = ConfigurationManager.AppSettings["log_level"].ToString();

Files

you should never need to check or modify a file on the Azure App Service, but who am I to judge? I am been there myself. You can use the Kudu tool on Development Tools/Advances Tools menu of the App Service on Azure.

Conclusion

Having a clear understanding of your WCF Service ABC (Address, Binding, and Contracts) will help to move your legacy .Net 4 services to Azure App Service.

Check if you have custom bindings or custom behaviors, and confirm that you are not expecting to use resources from the host like storage (hard drive)

Prefer the Configuration Manager to have access to your AppSettings.

Deploy using Visual Studio or Automated Pipelines and run automated deployments instead of modifying files manually on the Azure App Service.

If you found this post helpful in migrating a Windows Communication Foundation Service to Azure App Service, clap. You know the drill.

Do you want to get my latest posts and insights? follow me here on Medium, or Linkedin (https://www.linkedin.com/in/juancarlospelaez/)

This post has been written by a Human.

Originally published on Medium in 3Metas.