ActiveState recently launched the first feature of our new SaaS Platform: Python Runtime Security. In the second part of this 4-part Q&A blog series, ActiveState Chief Technology Officer and VP of Engineering, Scott Robertson, outlines his approach to solving three key challenges of the software development lifecycle: creating reproducible builds, managing dependencies and configuring environments.
ActiveState: We’re focusing on 3 key aspects of the Software Development Lifecycle (SDLC): reproducible builds, dependencies, and configuring environments; talk to me about why these three things and what are the challenges with these 3 aspects in the SDLC?
Scott: I touched on these a bit in the last segment. The challenges with reproducible builds are related to software development. It isn’t a solo sport, more often than not it’s a team-based sport. But if everybody shows up on your team using different equipment it’s hard to score and work as a team. In software development that translates into issues like chasing a bug and finding the root issue is that Developer A used software version 1.2 and Developer B used version 2.5, and that these two versions had slight incompatibilities. Some languages provide support to tell you that you have this problem but it’s not universal across all the different programming languages you have.
Being able to get to the exact same state, the exact same build on every machine eliminates a vast swath of those types of errors that pop up and in the end become a huge team time drain over and over. If every developer only spent one hour tracking down one bug, that still amounts to thousands of developer hours in large organizations. Multiply that by developer salaries and the cost can be considerable. With the ‘same state’ approach you’d reap tons of rewards with fewer headaches, time and cost savings.
No project exists without it naturally bringing in software dependencies. There’s a good chunk of time that’s spent finding dependencies, building and compiling those dependencies and sorting out the difference between what the developer platform is versus the production platform. If you look around any Dev shop you’ll tend to notice they’re all running on Macs or some portion of your Devs are running Macs. And you have some version of Linux and / or Windows to run in production.
You need to be able to support things across different platforms in a way that makes sense and is helpful. There’s a reason why developers use Macs and there’s a reason why we run on different hardware in production. And the difference in hardware platforms from one environment to another isn’t something that’s going to go away.
Containers and Docker have tried to get rid of issues arising with the difference in hardware platforms but there will always be a case where the tooling has to run natively on the hardware platform. And containers don’t solve everything. And so our feeling here is that – while you can’t have different languages run on different platforms, you can have something that makes it easier to run across different platforms and solve some of those issues. Or, I should say, take out all the work of getting the right dependencies on the machines and the environments built for your laptops. Not having to wait for these things to be built are timesavers for everyone in the organization.
Ultimately, and we might be getting ahead of ourselves in this discussion, I like to say that we’re trying to build a platform that lets us say “Yes” to what developers want to do versus traditionally how enterprises address these concerns. For example, if dependencies are drifting or they’re not working on a particular platform or we don’t understand a toolset we tell the developers “No”. We end up picking a smaller subset of the possible items Devs can use to solve their problem even though that may result in subpar solutions.
Ultimately, and we might be getting ahead of ourselves in this discussion, I like to say that we’re trying to build a platform that lets us say “Yes” to what developers want to do versus traditionally how enterprises address these concerns. For example, if dependencies are drifting or they’re not working on a particular platform or we don’t understand a toolset we tell the developers “No”. We end up picking a smaller subset of the possible items Devs can use to solve their problem even though that may result in subpar solutions.
For instance, there are tools that are very good at data science processing but they’re also some of the hardest tools to set up. So some organizations won’t allow you to use the better performing tools because it’s too big of a burden on the DevOps team or it’s too hard for SecOps to stay up on this particular set of tools.
Or maybe it comes down to a language and the people running things in production only understand Java and yet other teams want to run Python. The traditional answer to solving these problems is just saying “No”.
So what we want to do is build a platform that can say “Yes” to developers because we can take out some of the harder things like finding dependencies, making sure things get rebuilt the same way across all the organization’s environments, from development and testing to production, and give you visibility to know what’s running where and if it matches your security and compliance requirements. If we can address these challenges in a holistic way, we man ensure enterprises don’t have to say “No” AND enable them to move at the speed of their developer innovation.
More to Come
Stay tuned for Part 3 of our Q&A series. Scott talks Continuous Integration / Continuous Deployment and how the Platform enables enterprises to move at the speed of development.
Interested in trying out Beta functionality? Create a free account of our new SaaS Platform for open source languages.
