This is a series of blogs that will go through the vendor support lifecycles for the main technologies that we use and what options and approaches for upgrade paths there are available.
In our last blog on this subject, we covered Microsoft’s .net technology, which forms the basis of the majority of development projects we work on. Microsoft’s technologies aren’t the only tools we use, but they do make up a considerable portion of our services and so let’s cover the other Microsoft tech that we use.
Xamarin
The Xamarin cross-platform app technology uses a lot of .net technologies, however, it does not directly run on either the .net Framework, or .net Core. Xamarin has its own runtime and the support provided by Microsoft for Xamarin technology is linked to the version of Visual Studio that that particular Xamarin release was included in. Visual Studio follows the mainstream and extended support lifecycles as described above.
Note though, that for Xamarin in particular, there are likely changes in the future. A new .net technology called MAUI (Multiplatform App User Interface) is being built that brings the advances made in Xamarin available as part of .net, targeting the .net 6 release. While this is still in development, it is likely that once MAUI is generally available there won’t be many enhancements made to Xamarin. So, Xamarin itself has long-term support, but like the .net Framework, all new innovations may only be available in MAUI and that would be the technology to migrate Xamarin apps to. I wouldn’t use this as an excuse to not start new app development in Xamarin, but just to be aware of what the future may hold for the technology.
SQL Server
Microsoft’s support for SQL Server follows their mainstream and extended support models, as covered above. For versions before SQL 2017, this was also based on the service packs released for those versions: once a new service pack was released for a particular version of SQL Server, to continue receiving support from Microsoft, you’d need to be running on that service pack, and the remaining time within the mainstream or extended support windows would continue on with that service packed version.
From SQL Server version 2017 onwards, Service Packs are no longer produced and so the version’s original release date is used for the support windows. Cumulative updates are released during that time to fix issues, but support is based on the version of SQL, not the service pack.
All of this means that we do need to review the version of SQL Server that your application uses and ensure we have a plan in place to stay on a supported version.
Cloud Services/Azure/Power BI
Microsoft’s cloud services mostly fall into two groups: those that are automatically updated, and those that are versioned in some way. This applies to both the services themselves and the APIs that are used to interact with those services. An example of a versioned service would be Azure SQL Database, and an example of a versioned API would be the Azure Storage APIs.
These services fall under Microsoft’s ‘Modern Lifecycle Policy’, which has the wonderfully vague criteria for services remaining in support:
- Customers must stay current as per the servicing and system requirements published for the product or service.
- Customers must be licensed to use the product or service.
- Microsoft must currently offer support for the product or service.
A key point here is that under this policy Microsoft will provide a minimum of 30 days’ notification of support of a service ending. This means that when using Azure services, you must be aware of the services you are using and keeping them up to date. For some services this will happen automatically, but for the versioned services, there will be a point by which some effort is required to migrate to a newer version of that service, and this should be factored in to your plans for a system.
That pretty much rounds up the extent of the Microsoft technologies that we use at Software Solved. Of course, if we went into all the services that make up Azure, we’d be here for a long time, but the principles covered above are a good summary of the guiding factors you need to be aware of.
Next time, we’ll cover some non-Microsoft technologies, so various web technologies and databases from other vendors.
