Search form

You are here

ActiveState Blog

In my previous post, Why baking security into products is important, I examined the reasons for pushing security leftwards in your development process. Assuming teams do this, how do you ensure security elements added earlier in the development process actually end up in production? Or more importantly, ensure that nothing is in production that shouldn’t be there. In other words, how do you prove your security and compliance process is achieving what it was intended to do.

I joined ActiveState last year. It’s the first time I’m working directly in the open source space. And along with learning a lot, it’s been remarkable to consider not only what the company has achieved but also the proliferation of open source software. I’ve been surprised to learn how many of us take open source for granted, especially since how it enables most of our day-to-day tech.

Can your build pipeline perfectly reproduce a build including its critical bug that is deployed to a particular subset of machines? Reproducible builds is a fundamental problem that any developer who’s shipped software has had to deal with at some point.

Organizations are focused on releasing software faster to stay ahead of the competition. Software development processes have become more flexible, push functionality out more often and in smaller chunks. In other words, organizations have adopted lean and agile principles across the software development lifecycle to move at a faster clip. But this alone wasn’t enough to move at the pace required. In order to bridge the gap between software development and the actual production operations of the code, a new approach was necessary: DevOps; a shifting left of operations.

ActiveState just announced our SaaS Platform. This is another huge step in the evolution of our company. A company that has 20 years rooted in open source languages. And a company that I have had the privilege of leading and growing over the last decade. I’m excited about what the year ahead brings.

A quick look back

When I joined ActiveState in 2006, we were known as a provider of commercial-grade open source languages. But we’re so much more than that, at our core, we’re an innovation lab.

AWS is a great place for accessing scalable, cheap resources on which to deploy data models.

However, actually using AWS for this purpose can be challenging. If you didn't begin your project on AWS, you have to figure out a way to migrate it there. In addition, you have to determine how to handle the dataset against which you run your algorithm: should you move all of that data into AWS (and deal with the privacy challenges that this raises), just stream the data (which is not cheap), or do something else?

In my last post I surveyed the growing array of options for deploying your ML models into production. In this post, we’ll create a demo to see how simple it is to develop your own service using Python’s Flask library.

There are a number of cases where you might not be able to use a cloud service to host your model and would be required to roll-your-own inference service. In many large enterprises, on-premise solutions are mandatory. Approvals to purchase third-party solutions can also be lengthy and complex. So developing your own small service may be the best solution.

Python and R are among the most popular programming languages for data-centric engineers. However, they are not always the languages that the rest of an application is built on. This is why you sometimes need to find a way to deploy machine-learning models written in Python or R into an environment based on a language such as .NET.

In this article, I show how to use Web APIs to integrate machine learning models into applications written in .NET.

Hadoop is an open-source software framework for distributed storage and distributed processing of very large data sets. All the modules in Hadoop are designed with an assumption that hardware failures should be automatically handled by the framework.