Author: Bart Copeland

  • Python’s Popularity Continues: Examining the Top Use Cases

    Python’s Popularity Continues: Examining the Top Use Cases

    Python continues to be one of the most popular coding languages in use. In fact, the TIOBE index of programming language popularity named it the 2018 Language of the Year. Its usage and adoption continue to grow and proliferate into additional use cases.

    Python’s popularity and growth are in part because it’s flexible and easy to use. Python has grown from a scripting solution for sysadmins to web development for programmers to the driving force behind machine learning. We’ve observed this growth since 1999, when we began to build engineering Python distributions. As we’ve seen the use cases grow, we’ve examined the top use cases by customers ActiveState has observed.

    Let’s look at the three most popular Python use cases within the traditional tech space: infotech, software and hardware.

    Infotech: IT modernization

    The IT team of a state legislature is challenged to be able to remotely manage thousands of user desktops. Its 147 representatives, as well as its hundreds of supporting personnel, work on-premises and/or remotely. One of the key tools that empowered the team was Windows Powershell. Unfortunately, Powershell is unsupported and no longer works under newer Microsoft operating systems.

    Rewriting any application that’s a cost center is always difficult to justify. As a result, rewrites are rarely budgeted, planned and resourced appropriately. But the alternative was much costlier in terms of capital and resources: dispatch IT personnel to physically install, update and manage each user’s desktop, on an on-call basis.

    It’s famously easy to get started and develop with Python. While there was no way around a rewrite of the desktop management scripts, the IT team could at least minimize the time and resources required. Python allowed Powershell script rewrites to be done incrementally in IT’s spare time. This translated into a significant lowering of costs, and reduction in the risk of a “big bang” rip and replace project.

    Software: Adding Extensibility to Legacy Applications

    A U.S.-based public company has a 30-plus-year history of providing a suite of electronic design automation (EDA) tools to their more than 5,000 customers worldwide. Its suite of tools historically was built in C++ and is packaged for deployment on-premises.

    Because each customer has their own instance, it’s natural for the customer to want to customize the suite of tools to their needs. The U.S. public company used Python to wrap some of its C++ APIs to expose key functionality, making their software solutions more extensible by customers. Ensuring Python was deployed properly at customer sites required including Python within their existing installer, rather than relying on their customers to install Python correctly.

    The company used an OEM distribution Python that added a standard version of Python within their application and deployed it, so all teams can customize and leverage the EDA tools as required. Plus, by deploying a standardized Python version across all customer sites and developer desktops, the company can decrease support costs and speed time to market by eliminating the need for legal department reviews. Further, using a third-party-standardized Python version eliminates the opportunity cost of managing one’s own Python build and can facilitate the discovery of issues, bugs and performance issues.

    Hardware: Automating Network Administration

    A Silicon Valley-based American technology leader develops, manufactures and sells networking hardware. A key enterprise demographic for the company is network administrators, who often are confronted with managing the vendor’s multiple devices across extended corporate networks.

    The challenge: Network admins aren’t typically developers. Yet, they want to improve their efficiency by being able to programmatically make configuration changes to multiple network devices at once. While sample scripts are easy for any network admin to use and modify, the vendor did not want to be held responsible for creating all the scripts its user base might require.

    Python was the solution because it is simple enough for any technical person to learn and start using effectively. The company chose a version of Python that allows their customers to quickly create sample Python scripts to cover the majority of typical network admin use cases.

    This choice also allows network admins to create Python libraries they can leverage to create their own custom scripts to manipulate the configuration, operational state or event data from network devices. Most importantly, the cost of administering enterprise networks is significantly lowered and network admins are dramatically more efficient with programmatic access to physical networking devices and virtual network resources.

    Looking Outside the Tech Space

    Other examples that round out the top 10 use cases for Python include:

    • Consulting services: Bespoke web development.
    • Insurance: Creating business insights with machine learning.
    • Finance: Data mining to identify cross-sell opportunities.
    • Retail banking: Flexible data transformation and manipulation.
    • Aerospace: Meeting software system deadlines.
    • Business services: API access to financial information.
    • Health Care: Predicting disease prognosis.

    Ongoing Innovation

    Python’s usage continues to grow due to its simplicity and flexibility. Developers clearly want to use it for a variety of reasons that surpass its creator’s original intent. To support this usage, organizations need to ensure their developers can do so securely, by overcoming open source vulnerabilities while still iterating quickly. It seems that use cases for Python are limited only to the imaginations of its growing, enthusiastic user base.

    — Bart Copeland

  • Stop the Domino Effect by Joining Build Engineering and DevOps

    Stop the Domino Effect by Joining Build Engineering and DevOps

    As DevOps has become more common, these teams are tasked with uniting everything from coding to deploying and monitoring applications. Build Engineering forms the foundation for all those processes and is essential for building code. Its tools vary according to the operating system you’re building on and by programming language. DevOps needs to work with Build Engineering, but the two don’t usually connect. And that’s a problem.

    Over the last 10 years, there’s been a shift toward DevOps. Previously there was a discrete division between coding, done by developers and engineers, and deployment, done by Ops. However, it became apparent that for companies to optimize benefits such as productivity, development and operations shouldn’t be so disparate. The result of which is DevOps.

    Along with the shift to DevOps have come several trade-offs—namely trading security for speed, certainty for agility and proprietary code for open source:

    • Speed: Getting to market quickly has become critical to success. Speed now takes greater priority over fixing vulnerabilities, which can always be addressed in the next release (hopefully). And retrofitting for security and vulnerabilities after the fact becomes a big blocker for development and engineering teams. At the end of the day, the risk of lost profits is greater than the risk of potential unknown threats.
    • Agility: Agility trumps certainty in the race to market. For instance, iterative pushes to production do away with fixed, known road maps in favor of implementing whatever this week’s most important feature/functionality is. The trend toward immutability is also important here; it’s generally simpler and quicker to throw away something that’s broken or outdated rather than trying to fix or update it.
    • Open source: Due to the greater innovation, reduced costs and transparency it delivers, open source has won over proprietary code. Rather than focusing on creating proprietary code, developers can quickly iterate on a solution by assembling open source code, accelerating time to market. Plus, the ability to take from what has already been created can free up your dev teams to innovate and build IP for your enterprise efforts.

    For most, the tension between fixing something and knowing if it will break something upstream hasn’t been eliminated. You may be able to quickly update and patch a single solution, but how will this impact you once you push to your CI stream? Even for mature DevOps organizations, there’s a hidden opportunity cost associated with two factors that are overlooked: open source programming languages and Build Engineering.

    Overhead is added to your DevOps teams when you retrofit your open source language of choice with new versions, dependencies, security patches and so on adds. Teams should be focused on the things that matter—creating and delivering the latest release.

    On top of that, Build Engineering takes a hit each time the underlying open source language is retrofitted. You need to rebuild all your developer environments, CI/CD systems and production environments. All of this build engineering work is manual, slows down time to market and eats up valuable engineering resources. Plus, you’re not certain your rebuild and update will provide performance improvements that warrant the update.

    Since DevOps already relies on automation, it makes sense to apply this tool to the retrofitting and building of your open source languages and seamlessly connect to the rest of your DevOps cycle. You could ensure build reproducibility, dependency management and compliance with your corporate security and license criteria. For example:

    • Build impact –  What if you could understand the performance improvements (if any) that could be gained by taking the latest build?
    • System update – Consider the benefits of being able to update all of your impacted systems across dev, test and even production environments with the latest build using a single command.
    • Packaging – If each continuous build could be packaged in multiple ways—any form factor for any operating system—how would it change your workflow?
    • Build validation – Imagine that every continuous build could be vetted against your smoke test, inclusive of compliance with your security and license criteria, so you knew whether it was ready to deploy.
    • Continuous builds  – What if every time a new version of a library or patch for a vulnerability was found, a new build was kicked off and you were notified when it was done? Then you could keep up with your continuous deployments.

    The domino effect is a phenomenon that DevOps must deal with on an all-too-often basis. Dev and Ops came together for greater productivity, but unforeseen dependency issues regularly gum up the works. That’s the reason automation is such a useful tool, one that you can used to stop the domino effect as you automate your build pipeline for open source languages. It’s truly possible today to benefit your business by ensuring build reproducibility, dependency management and compliance with your corporate security and license criteria.

    — Bart Copeland

  • Using Open Source Languages Effectively in the Enterprise

    Using Open Source Languages Effectively in the Enterprise

    Open source languages are part of almost every business these days. In fact, according to Opensource.com, open source will be the driving force behind a great number of technology innovations due to its pervasive use. From development to quality assurance (QA) to DevOps, all kinds of coders have embraced open source languages. In doing so, though, enterprises have given up easier-to-adopt, general-purpose languages in favor of more niche-oriented languages.

    Those who are enthusiastic about open source languages have been contributing to open source language projects and building versions of languages including Perl, JavaScript, Go, Tcl, Ruby and Python. There has been a massive shift in the adoption of open source languages and genesis of new ones in the last 20 years. Even large corporations such as Microsoft, Google and IBM contribute to open source projects that are hosted on GitHub, and Spotify, Dropbox and Reddit are among the big names that use Python.

    This mainstream adoption speaks to the enormous popularity of open source languages. This has brought about the proliferation of new languages co-existing with older languages, which creates more and more challenges for various stakeholders in the software development life cycle (SDLC)—and more tension.

    The tension between these two groups exists because of the gap between their needs. Addressing this tension requires a convergence of the needs of two specific stakeholder groups: coders and the enterprises for which they work. There are ways to fulfill what both coders and enterprises need, create better experiences for coders and make things easier for all stakeholders in the SDLC.

    Enterprises require security, control and compliance. Coders need speed, want to create and crave a frictionless environment. Roadblocks and restrictions need to be removed for coders while ensuring the needs of the enterprise are being met.

    Strength in Uniformity

    What would it look like if you could gain all of the potential benefits of open source languages while still fulfilling coder needs and resolving your enterprise requirements? What if uniform tooling could be provided across open source languages? And what if enterprises could use a single uniform tooling set regardless of open source language? It would solve needs for the coder and the requirements of the enterprise.

    Using uniform tooling, an enterprise’s open source languages can be compiled and installed; dependencies found and installed; and code written, tested and updated complete with security and license compliance needs being addressed. However, tooling currently isn’t uniform across open source languages. And the maturity and best practices of tooling wildly vary. Enterprises create a workaround by creating policies to mitigate for deficiencies in tooling. This workaround is sub-par because it happens too late in the SDLC after threats and issues are introduced into your code.

    Establishing a Single Ecosystem

    The quality that makes open source so useful—its openness—and its lack of controls makes it something of a digital wild west. Fewer restrictions enable faster innovation, but they come at the cost of quality and cohesion for the enterprise. Many of your installed libraries have holes and security threats. Enterprises are faced with time-consuming license reviews to ensure adherence to third-party license rules as well as internal policies restricting certain types of licenses. In addition, license reviews happen at one point in your code’s life cycle versus in an ongoing, automated way. Enterprises are burdened with high administrative overhead and stale information.

    However, there is a different scenario possible. What would it look like for a company to have a uniform and high-standard ecosystem for their package management, with no vendor lock-in, all based on open source? What if a company could be guaranteed the same quality and types of packages for every language they use? What if a company could easily have visibility for what is being used across all of their environments, from concept to development to testing to production? It would be easier for the coder and fulfill the requirements of the enterprise.

    The wild west quality of open source language ecosystems makes them somewhat unreliable; updates and deletions can occur. And there are different package management solutions with differing degrees of sophistication, complexities and required expertise to use. Today an enterprise can easily end up with multiple package management solutions and have different packages of the same open source programming language. There is no single or consistent source of truth. 

    Working with a technology provider is an effective way to mitigate your open source language risks and solve your coder need for speed. A provider can offer more than just support, inlcuding:

    • The appropriate licenses based on usage and policy requirements
    • The right packages for each specific application
    • The best notification and remediation based on Common Vulnerabilities and Exposures (CVE) security threats
    • The indemnification that fits, based on usage
    • The expertise to build you the language distros you need based on usage, environment, security and compliance requirements and applications.
    • The right builds, standardized for all of your teams and ready to go out of the box

    Thriving in the Wild

    Sometimes, using the “right tools” for the job involves coders building many programming languages in an environment. The resulting “polyglot” situation creates benefits as well as challenges. Better products are made, and products are shipped faster, but it’s difficult to build a core competency in a particular programming language. And it’s impossible to centralize support and difficult maintenance requirements.

    What’s needed is a single, uniform tooling set that can work across multiple languages. This makes open source languages easier to use and implement in the enterprise, addressing the needs of developers as well as those of the enterprise. Working with an expert advisor will help you not just survive but thrive in the wild and woolly world of open source.

    — Bart Copeland