By Dean Maier, Synthesis Cloud Project Lead
Whether you are already underway on your cloud migration journey and modernising your applications or are just looking to run an existing service in the cloud, this guide will assist you with some of the checklist items you should consider.
Microsoft has two primary frameworks or SDK’s that are used for service development and these are namely .NET framework and .NET core. You can read more information here.
Legacy
The .NET framework version 4.8 is Microsoft’s last version of the .NET framework. Due to the dependency on the .NET runtime which is only supported by Microsoft Windows operating systems and the fact that it is no longer under active development it would be fair to consider any .NET framework solutions as legacy.
Given the advent of the .NET core platform and the direction by Microsoft making .NET 5 “the only .NET”, you should consider an upgrade rather hastily as more and more solutions are requiring cross-platform capabilities and features enabled by the newer framework.
This guide can assist you in your migration efforts. Get more information here. You can also leverage the AWS porting assistant which can help you analyse your solution, your dependencies and port your application for you.
General considerations
When making the choice to deploy your application or service to the cloud the one thing that becomes apparent, or at least I hope, is that the term stateless becomes truly relevant.
Stateless (as per Wikipedia) refers to no session information retained by the receiver, usually a server. This means that the information you store in memory or on disk cannot be relied on and should not be relied on.
You should account for any dependencies you have and find alternatives on where to store and access state information such as your data caching, application configuration and any files you may need to interact with.
Hosting
Although it is simple enough to host your application “as-is” on a Microsoft Windows Server in the cloud it does not really serve any benefit apart from simply running in a different location. In fact, it may prove troublesome when you start looking at scaling and resiliency.
AWS for example provides you with the ability to launch an EC2 instance with a wide range of supplied AMI’s (Amazon Machine Image) and you can create your own too. They provide you access to a selection of operating systems which are optimized for start-up speed and security and even have specific versions of software pre-configured.
You could consider hosting your application in some of the following ways:
- Virtual machine using the dotnet runtime
- Managed service
- Container hosting service
Logging
One of the immediate things that will need to change is how you go about logging in your service. This refers particularly to where the logs are stored. As mentioned in the hosting considerations you could simply store them on a virtual machine but if that instance disappears – so do your logs.
AWS, for example, provides you with a managed service called CloudWatch, which can store logs in log groups and specify retention periods. Additionally, you can utilise Insights to execute queries against your log files.
Cloud providers will supply you with an SDK that will have an integration with your existing logger, for example, Log4Net or Serilog, and can easily adapt to include the cloud providers logging service.
A guide to integrating your logging with AWS can be found here.
Configuration
Provided you are already making use of Microsoft’s .NET core platform, you should be making use of a configuration file in the form of json, like “appsettings.json” or similar that you’ve configured in your application’s “startup.cs” file.
When you run applications on the cloud it is considered best practice to have your configuration injected into the applications environment variables. This can be enabled by specifying “AddEnvironmentVariables” to your application’s configuration builder.
Regardless of your hosting choice, this pattern would still be relevant.
You may also have to consider secure values that are stored in configuration and making use of a secret manager provided by your cloud provider. AWS provides AWS Secrets Manager and an example of implementation can be read about here. This does however come at an additional cost so for more general-purpose configuration storage you can consider the AWS SSM parameter store which you can find an example implementation of here.
External dependencies
Here’s where things start getting a bit interesting. Naturally, services like databases and queues, start coming to mind and they are not exempt from changing when you migrate your application.
If you are making use of a database, you may need to consider that migration path too. Most cloud providers have a managed service for databases such as AWS with their RDS service. Luckily, they have migrated thousands of these instances already and have made the migration path simple enough, so you will just need to change your connection strings.
Should you have any other dependencies you may have to consider what managed services you can leverage from your cloud provider and how to change about your integration. These could include things like managed queues, notification services, caching, and file storage solutions.
These will most likely offer integration in the form of an SDK so provided your integration is not too specialised, it should be simple to switch over.
Licensing
This may be more of a bespoke topic not relevant to your solution however if you do make use of licensing within your software you may need to consider how to go about storing licensing information.
Some licenses additionally require some type of compliance and AWS, for example, has a managed solution for you to store and monitor licensing information and usage.
More information can be found here.
Monitoring
If you were used to watching Windows Task Manager or Performance Monitor – these will most likely not be available for your hosted solution.
Instead, consider what metrics are provided by your cloud provider. In AWS, for example, there are metrics for all managed services and similarly, alerting, which can be configured to notify relevant members for things like high resource usage or unusual error counts.
High availability and scaling
One of the most compelling reasons in my opinion to migrate your solution to the cloud is to take advantage of the availability, resilience and scaling opportunities provided to you by utilising the cloud to host your applications.
In terms of availability, making use of a managed service means your infrastructure is managed and your cloud provider will make sure it is available as per their availability SLA which is usually 99% and higher.
In terms of resilience, automated failovers can save you headaches down the line and can limit the impact of a single point of failure. Provided your application is stateless you should not have any issues resuming from another location.
Then in terms of scaling, most managed services have a template to define what types of scaling your application can make use of. Typically, these work on several metrics and you will have the freedom to either notify someone that scaling should take place or have the service do it for you automatically. Scaling up can help ease the contention on a service or set of services whereas it can also save you money by scaling down services when there has been an observed period of limited usage.
Have a look here at how AWS provides auto-scaling functionality to a number of services.
Conclusion
While this may not be an exhaustive list of considerations you’ll have to make to migrate your application or service to the cloud – these are certainly some of the biggest ones which in some instances can take some time and may require you to make changes to your architecture.
Due to cloud providers having migrated thousands of workloads already, the platform and tooling have matured extensively, and it is becoming so much easier to make the move.
Synthesis, as an AWS advanced partner, has helped countless customers on their cloud migration journeys and has also built a whole range of cloud-native solutions. This allows us the unique position to be able to accelerate customers in realising great value by adopting cloud.
Contact us to find out more or to see some of our customer success stories.
