pol·y·glot
ˈpälēˌɡlät/
adjective
1. knowing or using several languages.
Polyglot has an expansive and complex meaning in software development; the term can be used to describe software programming as well as software environments. In this post I’ll tackle polyglot software environments.
Polyglot environments are those where you find a variety of technology stacks which can include disparate programming languages. These programming languages are used in developing and supporting both legacy and modern software applications.
Enterprises know they have polyglot environments but most often they don’t realize who uses what programming language and where all those programming languages reside. And most importantly, enterprises don’t know the extent of dependencies between legacy programs and the applications powered by new programming languages.
How You End up With Polyglot Environments
Polyglot environments grow over time through a combination of using the best tools or new tools, changes in technology, and changes in tech leadership.
Specifically, polyglot environments evolve within the enterprise because:
- Coders will sneak new technology into projects if they deem it’s the best solution for the requirements.
- Management also encourages coders to use the ‘right tools’ for the job. This results in building many programming languages in an environment.
- Technology stacks are added to an enterprise through the acquisition of products and companies.
- Effectively all development is polyglot, writing large applications usually necessitates multiple programming languages.
- Changes in tech leadership often bring new technologies into an organization, and general purpose programming languages in particular tend to be fairly interchangeable and subject to the competencies of the individual espousing them.
- Technologies come in and out of favour so the number of programming languages and technologies an organization has to maintain grows over time.
- Management can’t take on the burden of policing teams to adhere to a small set of programming languages and tools.
What Happens When You End up With Polyglot Environments
We see enterprises struggle between the advantages provided by a polyglot environment and the complexities and problems of handling polyglot environments.
Enterprises benefit from polyglot environments because when the best tools / ‘right tools’ are used then better products are made and products are shipped faster. Plus, in a competitive marketplace for technical talent, enabling coders (developers, QA, DevOps, SysAdmin, etc.) to choose the tools they want to use is a necessary requirement to attract talent.
However, the impetus to select the best tools / ‘right tools’ also results in more tools. And with more tools comes more variety, and this results in complex challenges for the enterprise.
Here are what enterprises end up struggling with in the pursuit of best tools/’right tools’ and supporting coder freedom:
- High variability in tooling support with varying degrees of programming language quality;
- Difficulty in building a core competency in a particular programming language when knowledge is spread across many programming languages;
- Inability to centralize support and challenging maintenance requirements.
So how do you handle polyglot environments and still benefit from them?
Fix your broken open source programming languages.
Polyglot environments include a significant contingent of programming languages. And virtually all programming languages are now open source. If enterprises fixed the problems created by open source languages they’d gain a quick win when managing polyglot environments.
Suggested Best Practices
I suggest some best practices to help enterprises fix their broken open source programming languages. These suggestions have been built over 20+ years of helping enterprises deploy open source programming languages.
- Get smaller build distributions with only the packages you need, based on your specific criteria;
- Monitor code running in production and respond based on risk of flagged components (eg CVE components) used in your applications;
- Standardize on specific programming language builds across your company: Enable consistent environments across teams & Manage dependencies.
- Eliminate developer time wasted on build engineering.
- Get regular updates to keep code current and free from bugs.
- Benefit from commercial open source support for programming language versions and platforms that are near end-of-life and not supported by community.
TIP: For optimal results, I’d recommend working with a third-party vendor to advise or implement the best practices. The vendor can polyfill your feature set and provide ongoing support and maintenance. Look for a vendor with domain expertise in each of: package management, languages to be built/configured, dependency management, and deployment to different environments.
However, this list of recommendations, in our opinion, doesn’t cut it. It doesn’t provide a holistic solution to the polyglot environment challenge; a solution that works for both the enterprise as well as the individual stakeholders in the Software Development Lifecycle (SDLC).
What if, you could know all of the dependencies and programming languages of the applications you are running across your enterprise?
And what if you could set thresholds for when to trigger and update, alarm or other kinds of events based on said dependencies?
What if you could build, replicate and distribute a specific programming language distro on-demand and with 1-click?
We believe if enterprises were able to satisfy ‘what ifs’ like the ones above they could benefit from:
- Coders spending time on delivering value, not tooling/build engineering grunt work;
- Consistency for code in all environments in the software development life cycle;
- Time savings and decrease cost of resources dedicated solely to maintaining programming languages and package distributions internally.
More “What Ifs”? We Want to Hear From You
At ActiveState we are tackling these “what ifs” with the ActiveState Platform. My fellow Activators (ActiveState employees) and I are really excited about what we’re working on, but we also need your help. We’re spending a lot of time listening, sharing and creating conversations. But we need to do more.
Want to help shape what our ActiveState Platform looks like in tackling these “what if’s”? Open to sharing the challenges you’re facing with open source programming languages? Or maybe just interested in learning more?
