Altair Case Study – ActiveState Python

Altair Case Study - ActivePython

Altair Case Study – ActiveState Python

Executive Summary

The Challenge

  • Leverage Python to build out a set of APIs that make Altair’s software solutions more extensible by customers and enable internal developers to build out new functionality.
  • Eliminate dependency conflicts and have a single standardized Python version that works across an approximate thirty applications.

 

The Solution

The OEM distribution of ActiveState Python OEM, to standardize on a Python version along with ActiveState’s value-added services to manage the incorporation of open source libraries in Altair’s products.

 

The Result

A standardized Python version deployed across all customers custom built with Python data science libraries and non-Python libraries so that Altair can:

  • Gain back time for their build, development and management teams.
  • Decrease support costs through a standard Python version deployed across all customers.
  • Better identify issues, bugs and performance issues through ActiveState’s debug build.

 

Case Study

Altair is a US-based public company founded in 1985. It serves more than 5,000 customers across the Americas, EMEA and Asia Pacific. Altair has more than 2,000 engineers, scientists and creative thinkers in 24 countries. The Altair team provides engineering simulation for a wide range of structures, motions, fluids, thermal management, electromagnetics, system modeling and embedded systems via an integrated suite of software solutions that include:

  • HyperWorks Computer Aided Engineering (CAE) for modeling and visualization
  • SolidThinking for simulations
  • PBS Works (PBS) for workload management/batch processing
  • SmartWorks for IoT and analytics

Altair’s solutions allow their customers to reduce development times and lower costs throughout their entire product lifecycle from concept design to in-service operation. Altair delivers these benefits by enabling customers across industries like automotive, aerospace and others to transform how they do design and decision making.

 

The Challenge

Altair’s suite of applications is primarily built in C++ and packaged for deployment on premise. Because each customer has their own instance, it’s natural for them to want to customize it to their needs. Altair is leveraging Python to build out a set of APIs that make their software solutions not only more extensible by customers, but also enables their internal developers to more quickly build out new functionality.

But there’s a catch. Because of the innovative way that Altair sells their solutions (a units-based subscription licensing model that allows flexible and shared access to all their offerings), customers typically end up using multiple applications. Unfortunately, each application could be utilizing a different version of Python. This can lead to Python dependency conflicts, whereby one application requires v1 of a library but another requires v2 of the same library.

 

The Solution

To eliminate dependency conflicts, Altair is moving toward standardizing on a single version of Python across some thirty of their applications. Standardization will also decrease support costs, since all customers will have the same Python deployed. Altair has chosen ActiveState’s Python as their standard for a number of key reasons:

  • By OEM’ing ActiveState’s Python Altair can provide all their customers with a standard, out-of-the-box solution
  • Sourcing from ActiveState, rather than building, a custom version of Python allows Altair’s developers to focus on their core competency, namely adding features to their products
  • ActiveState’s value-added services manage the incorporation of open source libraries in Altair’s products.

ActiveState’s Python, is currently deployed in a central repository from which all participating applications pull it into their development cycle. The ActiveState custom Python build focuses on Python data science libraries, but also bundles a number of other, non-Python libraries into a custom installer that ensures the build is properly deployed at customer installations. ActiveState also provided a debug build of its ActiveState Python so Altair’s developers can better identify issues, bugs and performance bottlenecks.

The first products to incorporate ActiveState’s Python are expected to ship in the first quarter of 2019.

 

ActiveState Platform for Open Source Language Automation

Going forward, Altair will be able to take advantage of the ActiveState Platform, which allows them to automatically build, certify and resolve their own Python, Perl and Tcl distributions using a simple, wizard-like interface to:

  1. Choose an open source language and version.
  2. Choose the third-party packages/modules to be included from the ecosystem (PyPI, CPAN, etc.).
  3. Select a target platform, and click “Build”

The Platform automatically resolves all dependencies, compiles all packages and produces an installer that users can then push into a central repository, or else let teams pull directly from the ActiveState Platform. The result is quicker builds that can be updated much more frequently since the effort to build and rollback is minimal. This method also promotes innovation (since it’s simple to experiment with newer libraries and rollback, if needed), as well as ensuring vulnerabilities are resolved in a timely manner.

 

The Result

When moving from Python 2.7 to 3.4, Altair estimates it took them almost a year to nail down the build that was eventually rolled out to the organization. That effort represents a huge opportunity cost in terms of development resources that could have been better spent focusing on application features, rather than infrastructure.

Sourcing a Python build from ActiveState gives Altair back a wealth of time and resources across build, dev and management teams, which will pay dividends in the feature/function war they’re waging with competitors in their space.

Download the Case Study (PDF)

Recent Posts

Tech Debt Best Practices: Minimizing Opportunity Cost & Security Risk

Tech debt is an unavoidable consequence of modern application development, leading to security and performance concerns as older open-source codebases become more vulnerable and outdated. Unfortunately, the opportunity cost of an upgrade often means organizations are left to manage growing risk the best they can. But it doesn’t have to be this way.

Read More
Scroll to Top