A blueprint for open source language automation: How enterprises and developers can benefit
Open source languages continue to gain popularity. As they do, the organisations using them confront challenges related to their deployment, management and updates. Developers need to keep these languages free from vulnerabilities and threats, at the same time as they are coding new software. And that software must integrate with legacy and polyglot tech stacks. This has all become a drain on productivity that’s untenable in today’s fast-moving, fast-iterating tech world.
To decrease the costs and risks of managing open source languages, enterprises need to implement a systematic and automated workflow: Open Source Language Automation. The four phases to Open Source Language Automation are described below, tenets by which organisations and their developers can fully benefit from the full potential of open source languages.
An enterprise should first define its open source language policies, which will need to be programmatically enforced to ensure policy compliance across the entire organisation. To do this, companies must define what type of code usage is acceptable at each stage of the software development process and how it can be used by stakeholders in the company. Companies must also set organisation-wide open source language policies, version controls and triggers. The key activities that underpin this tenet (the first phase to Open Source Language Automation) include form usage, package controls, license and security criteria, and culminate in documenting the respective policies.
How open source languages, versions and packages that can be used, changed and updated across the organisation comprises form usage. Form usage also includes defining trusted sources and usage restrictions based on environment or application. Package controls should detail the recording of vetted packages by languages, detailing the test suite required for acceptable builds and recording the acceptable modifications and sources for packages.
This phase also includes deciding on license use by open source language (e.g. Python versus Java) and environment (e.g. development and testing versus production), as well as the defining of threat levels and any events that will be triggered. The final activity in this first phase is to document your corporate open source language policies. Make sure to include roles and privileges, expiration of information archives, and who has access to “secrets” – the keys, certificates and passwords required to securely access shared resources.
Next, centralise open source language dependencies. Track languages and packages across your DevOps cycle to assess open source usage and ultimately produce a single source of truth for open source languages. You should also gain visibility into the respective language build information such as packages, versions, security and licenses, and where they are deployed. The primary activities to centralise dependencies are auditing usage, defining terminology and listing package criteria, and documentingyour audit results.
Enterprises need to audit the use of open source languages from initial build/test, to deployment, to production monitoring and subsequent updating. By understanding usage, you can determine what improvements should be made. And set naming conventions for open source components, set how each stage in the software development process will be termed organisation-wide, and trigger-events to move from one stage to another.
You’ll then need to decide how open source code, including packages, is vetted and approved so it can be added to the company’s open source language repository. Approvals will need to consider environment, stage and use.
This phase ends with recording the results of your audit inclusive of a comprehensive open source language inventory. The inventory will list the runtime information of your open source languages, such as package name and version, security vulnerabilities, and license information.
This phase sets the lifecycle stages of open source languages as: build, certify and resolve. Companies will receive the immediate benefits of reducing vulnerabilities and increasing application quality by automatically creating builds with a systematic, repeatable build process organisation-wide.
You’ll also need to set the build consumption pace in order to achieve a continuous build, certify and resolve language lifecycle. To do this, decide how, when and who can update open source language builds. Correspondingly, determine the triggers that force a build update such as time, severity of vulnerability or major vs. minor language release. You’ll then define how open source language builds are certified, and the workflow for vetting and pushing open source language builds to production. Include certification levels per environment (for instance, development vs. production), application or customer use case.
Lastly, you’ll need to set the build resolution process. Implement an organisation-wide process for how open source language builds are resolved for dependencies, licenses and security. And to assess your open source language lifecycle health and optimisation, define a minimum set of organisation-wide parameters. The parameters should track your open source language consumption, certification and resolution results (frequency, successes, failures) and map against corporate policy.
Deploy and manage artifacts
Deploying and managing open source language artifacts is the final phase in implementing Open Source Language Automation. This requires automatic updates to test, stage and production servers. It also requires that updatesfeedopen source code data to inform corporate policies for the ongoing consideration of security and performance updates.
You will need to set the mechanism by which you deploy code and how open source language build deployment is enabled – who accesses the builds, who distributes and who pushes to production. You will also report on runtime performance through the monitoring of open source language builds, and implement alerts and notifications based on the open source language policies set in Phase 2.
From here, make sure to realise continuous resolution and updates of open source language builds according to corporate policies and what’s been reported – that is, as updates and vulnerabilities occur. Automatically update test, stage and production servers with the latest open source language builds. In addition, you will need to run continuous build-certify-resolve cycles to improve corporate open source language automation policies. Use code-specific knowledge to improve management, trust and performance of applications.
A successful polyglot roadmap
Many capabilities and opportunities arise through the use of open source languages, but they have their challenges as well. The challenges need to be addressed at scale, across the breadth and depth of open source language use. This is where automation comes into play, and its success requires planning and deployment – with stakeholder involvement. With all these pieces in place, your use of open source languages can flow forward with reduced expense and risk.
Interested in hearing industry leaders discuss subjects like this and sharing their use-cases? Attend the co-located IoT Tech Expo, Blockchain Expo, AI & Big Data Expo and Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam and explore the future of enterprise technology.
- » As Windows 7 and Windows Server 2008 move to end of life - how to immortalise enterprise IT in the cloud
- » Apple notes continued enterprise presence as Salesforce partnership goes up a gear
- » What’s new on Forrester’s Zero Trust security landscape in 2019: From theory to integration
- » Scope AR acquires studio WakingApp as enterprise augmented reality ramps up
- » 10 charts that will change your perspective of AI in security