DEVOPSdigest

As organizations have embraced open source, they have become polyglot — using multiple programming languages and technology stacks to accomplish software and hardware related tasks. These polyglot enterprises are using multiple programming languages to develop and support both legacy and modern software applications.

In real life, being a polyglot enables a person to communicate with millions more people than if he or she only spoke their native tongue. In software environments, people introduce new languages not to communicate differently but to achieve specific ends. Some languages are great for one task but not another, so working with multiple programming languages enables developers to use the right tool for the job. In this way, all development is polyglot; it's just the nature of the beast.

The addition of new programming languages can be incidental and incremental, as well. For example, when an enterprise acquires a company, it takes on the company's technology stacks — including its programming languages. And as tech leadership changes within the organization, those leaders often bring new technologies into the fold. Technologies fall in and out of fashion, as well, expanding the number of programming languages and technologies an organization has to maintain over time.

Enterprises are caught between the benefits provided by a polyglot environment and the complexities and challenges these environments bring. Ultimately, if the situation remains unchecked, polyglot will kill your enterprise.

The Dangers of a Polyglot Environment

Complexity abounds in organizations with disparate technologies like polyglot environments, polyglot programming languages along with managing legacy along with up-and-coming technology stacks. Engineering wrestles more and more with retrofitting licenses, security and dependency management for the programming languages they use for multiple software applications. At the same time, management lacks oversight on code compliance and they can't gauge risk.

Enterprises end up with high variability in tooling support and varying degrees of programming language quality. It's hard to become an expert in one language when you're required to work with a dozen. There's a big difference in skill level between a person who speaks French and Italian fluently and a person who can string a few sentences together in eight languages.

These problems multiply exponentially as an enterprise adds more languages, creating a digital Tower of Babel.

However, you don't want to hamstring your developers. You want them to have the freedom to use the best tool for the job, innovate, learn and create elegant solutions. Adding new programming languages builds their skill base and empowers them with the right equipment to fulfill their craft. So, you want to say "yes" to your developers, but as more and more languages are added to the enterprise, they impose a drag on your software development lifecycle (SDLC). At scale, all these languages and tools can kill the enterprise.

Enterprises should closely monitor these three primary issues:

1. Coding vs. Fixing: Updating and fixing tools instead of coding new features: Some enterprises centralize this function in a single team. Others require that each "pizza team" manage their own development tools. In either case, there's an opportunity cost the engineering team and management pay: rather than coding new features, these teams are constantly updating and fixing libraries in their open source tools since they move so quickly.

2. Wasted Development Cycles: Because library versions and code dependencies are constantly being updated, the artifacts associated with the original build of an application may no longer be available when a vulnerability is found. As a result, many development cycles are wasted trying to re-create an environment in which the vulnerability can be fixed.

3. Risk and Application Transparency: Applications are released and then never updated — why fix what's not broken? Teams come together for a project and then disband. As a result, when a critical vulnerability is discovered, the enterprise may not have visibility into which applications are affected, which libraries those applications contain, or even what languages they were built with. This can result in costly "exploration projects" in order to ensure the vulnerability is properly addressed.

Now, multiply these three challenges by each programming language in your organization, and what started out as a molehill suddenly looks like scaling Mount Everest. And just like a mountain climber, you won't survive without the proper equipment/tools.

Thriving in a Polyglot Environment

What's needed is a holistic solution that works for both the enterprise and the individual stakeholders in the SDLC. Enterprises can create this solution using these best practices:

1. Get regular updates to keep code current and bug-free.

2. Enable consistent environments across teams and manage dependencies by standardizing on specific programming language builds across your enterprise.

3. Get smaller build distributions with only the packages you need, based on your specific criteria.

4. Take advantage of commercial open source support to get help with programming language versions and platforms that are near end-of-life and not supported by a community.

5. Monitor code running in production and respond based on risk of flagged components (e.g. CVE components) used in your applications.

6. Create a single source of truth for your package management; this may require the assistance of a knowledgeable technology provider.

7. Set thresholds for when to trigger an update, alarm or other kinds of events based on application dependencies.

By implementing these tactics, developers will be able to put time toward delivering value, not tooling or build engineering grunt work. There will be consistency for code in all environments in the software development life cycle. Even the bottom line will improve with the time savings and decreased cost of resources dedicated solely to maintaining programming languages and package distributions internally.

Following these practices will solve the pain points of engineering teams, management, individual developers and every coder in the SDLC, regardless of their role.