Technology Version Updates: Recommendations and Guidance

The Lazsa Platform team continuously ensures that the latest technology versions are available to customers for building applications and data pipelines. Changes in supported and deprecated technology versions are always communicated through release notes. As the newer versions of tools and technologies become available, it is important to understand how the Lazsa Platform handles version updates and deprecation of supported technologies and the impact this might have on existing applications built on the Lazsa Platform.

For information on the tools and technologies supported by the Lazsa Platform, see Tools and Technologies Integrated with Lazsa Platform.

The following table contains various scenarios related to technology version updates, deprecation, and guidance on maintaining applications within the Lazsa ecosystem.

Technology Update Scenario Lazsa Recommendations and Guidance
A newer version of an already supported technology is released.

When a new technology version is available in the Lazsa Platform, applications built on the platform by using an earlier version of that technology will remain functional. The newly introduced version will be available for developing new applications.

Note:

If a customer wishes to upgrade their existing application to the newer version supported by the platform, it is their responsibility to manage this transition externally, following the guidelines provided by the respective technology provider.

The platform will only support the versions it has explicitly claimed at any given time.

Example

Acme Corp initially developed a web application using React 17 on the Lazsa Platform. Later, React 18 was released with new features. Lazsa supports both React 17 and React 18 but does not automatically upgrade applications to a later version. Acme Corp decided to upgrade to React 18 to benefit from the new features. However, they must handle this upgrade themselves, following React’s official guidelines. Lazsa continues to support both versions, but the upgrade process must be managed by the customer.

A technology version is deprecated.

Applications that were already developed by using this technology will remain unaffected and functional as before. However, the deprecated version will no longer be available for developing new applications in the Lazsa Platform.

Example

Acme Corp initially developed a web application using React 18 on the Lazsa Platform. Later, React 19 was released and React 18 reached its End of Life (EOL), meaning it became deprecated and was no longer supported in Lazsa.

This will have the following impact on Acme Corp's existing applications and their new application development in the Lazsa Platform:

  • Impact on existing applications: The application will continue to run smoothly without issues, as it was built before React 18’s EOL. Lazsa supports both versions but leaves the upgrade to React 19 at the customer’s discretion.

  • Impact on new development: React 18 is no longer available for new projects. Only supported versions like React 19 can be used for new web applications.

A new version of a tool is released.

To ensure proper functionality, it is recommended to use the versions specified in the Lazsa documentation. If you intend to use a different version, it is recommended that you thoroughly test it before using it in the platform for production use cases.

Note:

The responsibility of testing and maintaining unsupported tools and technologies lies solely with the customer. Lazsa does not provide any support in this process.

A new Kubernetes version is available.

Applications built on deprecated Kubernetes clusters should continue to function, as cloud providers generally ensure that existing clusters remain operational, even though deprecated versions are no longer available for deploying new clusters. If a customer wishes to upgrade their Kubernetes cluster to a newer version, it is the customer's responsibility to perform the necessary steps within the cloud provider's environment. Additionally, the customer must test the new version thoroughly before upgrading the production clusters where their applications are deployed.

Note:

If a customer wishes to upgrade their existing Kubernetes cluster to a new Kubernetes version, it is their responsibility to manage this upgrade externally, following the guidelines provided by the respective cloud service provider.

As the Kubernetes API evolves, outdated APIs are deprecated and removed in newer versions. To ensure your deployment runs smoothly, update the Helm chart (ingress.yml) and any other relevant files by replacing deprecated APIs with their updated versions.

Example

Acme Corp built a microservices-based application in the Lazsa Platformand deployed it on Kubernetes 1.21 in AWS. Later, AWS released Kubernetes 1.24 and deprecated the 1.21 version. Acme Corp's application will continue running smoothly on the existing 1.21 cluster, but Acme Corp cannot create new clusters with that version. To upgrade to Kubernetes 1.24, they need to thoroughly test the new version and complete the upgrade process through the AWS console as per the AWS guidelines before deploying it to their production environment where their microservices-based application is deployed.

A new Databricks Runtime version is available.

It is advisable to use a Databricks Runtime version listed in the Lazsa documentation. If a customer chooses to use a Runtime version that hasn't been certified by the platform, we recommend thorough testing before deploying it for product use cases. Avoid using a version lower than the supported one.

New versions of SaaS tools are available. The platform integrates SaaS tools, which are frequently updated by providers to add new features or enhancements. The platform team monitors these updates to ensure that they do not disrupt existing functionality and proactively implements support if any functionality is deprecated by the tool.

 

Related Topics Link IconRecommended Topics What's next? Platform Setup