Alternatives to Pipelines logo

Alternatives to Pipelines

AWS Data Pipeline, AWS Glue, Bamboo, Jenkins, and TensorFlow are the most popular alternatives and competitors to Pipelines.
27
67
+ 1
0

What is Pipelines and what are its top alternatives?

Kubeflow is a machine learning (ML) toolkit that is dedicated to making deployments of ML workflows on Kubernetes simple, portable, and scalable. Kubeflow pipelines are reusable end-to-end ML workflows built using the Kubeflow Pipelines SDK.
Pipelines is a tool in the Machine Learning Tools category of a tech stack.
Pipelines is an open source tool with 2.6K GitHub stars and 1.1K GitHub forks. Here’s a link to Pipelines's open source repository on GitHub

Top Alternatives to Pipelines

  • AWS Data Pipeline

    AWS Data Pipeline

    AWS Data Pipeline is a web service that provides a simple management system for data-driven workflows. Using AWS Data Pipeline, you define a pipeline composed of the “data sources” that contain your data, the “activities” or business logic such as EMR jobs or SQL queries, and the “schedule” on which your business logic executes. For example, you could define a job that, every hour, runs an Amazon Elastic MapReduce (Amazon EMR)–based analysis on that hour’s Amazon Simple Storage Service (Amazon S3) log data, loads the results into a relational database for future lookup, and then automatically sends you a daily summary email. ...

  • AWS Glue

    AWS Glue

    A fully managed extract, transform, and load (ETL) service that makes it easy for customers to prepare and load their data for analytics. ...

  • Bamboo

    Bamboo

    Focus on coding and count on Bamboo as your CI and build server! Create multi-stage build plans, set up triggers to start builds upon commits, and assign agents to your critical builds and deployments. ...

  • Jenkins

    Jenkins

    In a nutshell Jenkins CI is the leading open-source continuous integration server. Built with Java, it provides over 300 plugins to support building and testing virtually any project. ...

  • TensorFlow

    TensorFlow

    TensorFlow is an open source software library for numerical computation using data flow graphs. Nodes in the graph represent mathematical operations, while the graph edges represent the multidimensional data arrays (tensors) communicated between them. The flexible architecture allows you to deploy computation to one or more CPUs or GPUs in a desktop, server, or mobile device with a single API. ...

  • PyTorch

    PyTorch

    PyTorch is not a Python binding into a monolothic C++ framework. It is built to be deeply integrated into Python. You can use it naturally like you would use numpy / scipy / scikit-learn etc. ...

  • Keras

    Keras

    Deep Learning library for Python. Convnets, recurrent neural networks, and more. Runs on TensorFlow or Theano. https://keras.io/ ...

  • scikit-learn

    scikit-learn

    scikit-learn is a Python module for machine learning built on top of SciPy and distributed under the 3-Clause BSD license. ...

Pipelines alternatives & related posts

AWS Data Pipeline logo

AWS Data Pipeline

88
339
1
Process and move data between different AWS compute and storage services
88
339
+ 1
1
PROS OF AWS DATA PIPELINE
  • 1
    Easy to create DAG and execute it
CONS OF AWS DATA PIPELINE
    Be the first to leave a con

    related AWS Data Pipeline posts

    AWS Glue logo

    AWS Glue

    301
    546
    6
    Fully managed extract, transform, and load (ETL) service
    301
    546
    + 1
    6
    PROS OF AWS GLUE
    • 6
      Managed Hive Metastore
    CONS OF AWS GLUE
      Be the first to leave a con

      related AWS Glue posts

      Pardha Saradhi
      Technical Lead at Incred Financial Solutions · | 6 upvotes · 31.9K views

      Hi,

      We are currently storing the data in Amazon S3 using Apache Parquet format. We are using Presto to query the data from S3 and catalog it using AWS Glue catalog. We have Metabase sitting on top of Presto, where our reports are present. Currently, Presto is becoming too costly for us, and we are looking for alternatives for it but want to use the remaining setup (S3, Metabase) as much as possible. Please suggest alternative approaches.

      See more
      Punith Ganadinni
      Senior Product Engineer · | 2 upvotes · 24.2K views

      Hey all, I need some suggestions in creating a replica of our RDS DB for reporting and analytical purposes. Cost is a major factor. I was thinking of using AWS Glue to move data from Amazon RDS to Amazon S3 and use Amazon Athena to run queries on it. Any other suggestions would be appreciable.

      See more
      Bamboo logo

      Bamboo

      461
      441
      17
      Tie automated builds, tests, and releases together in a single workflow
      461
      441
      + 1
      17
      PROS OF BAMBOO
      • 10
        Integrates with other Atlassian tools
      • 4
        Great notification scheme
      • 2
        Great UI
      • 1
        Has Deployment Projects
      CONS OF BAMBOO
      • 5
        Expensive

      related Bamboo posts

      xie zhifeng
      Shared insights
      on
      BambooBambooJenkinsJenkinsGitLabGitLab
      at

      I am choosing a DevOps toolset for my team. GitLab is open source and quite cloud-native. Jenkins has a very popular environment system but old-style technicals. Bamboo is very nice but integrated only with Atlassian products.

      See more
      Jenkins logo

      Jenkins

      43.2K
      35.8K
      2.2K
      An extendable open source continuous integration server
      43.2K
      35.8K
      + 1
      2.2K
      PROS OF JENKINS
      • 522
        Hosted internally
      • 465
        Free open source
      • 315
        Great to build, deploy or launch anything async
      • 243
        Tons of integrations
      • 210
        Rich set of plugins with good documentation
      • 109
        Has support for build pipelines
      • 72
        Open source and tons of integrations
      • 63
        Easy setup
      • 61
        It is open-source
      • 54
        Workflow plugin
      • 11
        Configuration as code
      • 10
        Very powerful tool
      • 9
        Many Plugins
      • 8
        Continuous Integration
      • 8
        Great flexibility
      • 8
        Git and Maven integration is better
      • 6
        Github integration
      • 6
        100% free and open source
      • 6
        Slack Integration (plugin)
      • 5
        Easy customisation
      • 5
        Self-hosted GitLab Integration (plugin)
      • 4
        Docker support
      • 3
        Excellent docker integration
      • 3
        Platform idnependency
      • 3
        Fast builds
      • 3
        Pipeline API
      • 2
        Customizable
      • 2
        Can be run as a Docker container
      • 2
        It`w worked
      • 2
        JOBDSL
      • 2
        Hosted Externally
      • 2
        It's Everywhere
      • 2
        AWS Integration
      • 1
        NodeJS Support
      • 1
        PHP Support
      • 1
        Ruby/Rails Support
      • 1
        Universal controller
      • 1
        Easily extendable with seamless integration
      • 1
        Build PR Branch Only
      CONS OF JENKINS
      • 12
        Workarounds needed for basic requirements
      • 8
        Groovy with cumbersome syntax
      • 6
        Limited abilities with declarative pipelines
      • 6
        Plugins compatibility issues
      • 5
        Lack of support
      • 4
        No YAML syntax
      • 2
        Too tied to plugins versions

      related Jenkins posts

      Tymoteusz Paul
      Devops guy at X20X Development LTD · | 23 upvotes · 4.6M views

      Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

      It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

      I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

      We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

      If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

      The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

      Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

      See more
      Thierry Schellenbach

      Releasing new versions of our services is done by Travis CI. Travis first runs our test suite. Once it passes, it publishes a new release binary to GitHub.

      Common tasks such as installing dependencies for the Go project, or building a binary are automated using plain old Makefiles. (We know, crazy old school, right?) Our binaries are compressed using UPX.

      Travis has come a long way over the past years. I used to prefer Jenkins in some cases since it was easier to debug broken builds. With the addition of the aptly named “debug build” button, Travis is now the clear winner. It’s easy to use and free for open source, with no need to maintain anything.

      #ContinuousIntegration #CodeCollaborationVersionControl

      See more
      TensorFlow logo

      TensorFlow

      2.7K
      2.9K
      77
      Open Source Software Library for Machine Intelligence
      2.7K
      2.9K
      + 1
      77
      PROS OF TENSORFLOW
      • 25
        High Performance
      • 16
        Connect Research and Production
      • 13
        Deep Flexibility
      • 9
        True Portability
      • 9
        Auto-Differentiation
      • 2
        Easy to use
      • 2
        High level abstraction
      • 1
        Powerful
      CONS OF TENSORFLOW
      • 9
        Hard
      • 6
        Hard to debug
      • 1
        Documentation not very helpful

      related TensorFlow posts

      Conor Myhrvold
      Tech Brand Mgr, Office of CTO at Uber · | 8 upvotes · 1.3M views

      Why we built an open source, distributed training framework for TensorFlow , Keras , and PyTorch:

      At Uber, we apply deep learning across our business; from self-driving research to trip forecasting and fraud prevention, deep learning enables our engineers and data scientists to create better experiences for our users.

      TensorFlow has become a preferred deep learning library at Uber for a variety of reasons. To start, the framework is one of the most widely used open source frameworks for deep learning, which makes it easy to onboard new users. It also combines high performance with an ability to tinker with low-level model details—for instance, we can use both high-level APIs, such as Keras, and implement our own custom operators using NVIDIA’s CUDA toolkit.

      Uber has introduced Michelangelo (https://eng.uber.com/michelangelo/), an internal ML-as-a-service platform that democratizes machine learning and makes it easy to build and deploy these systems at scale. In this article, we pull back the curtain on Horovod, an open source component of Michelangelo’s deep learning toolkit which makes it easier to start—and speed up—distributed deep learning projects with TensorFlow:

      https://eng.uber.com/horovod/

      (Direct GitHub repo: https://github.com/uber/horovod)

      See more

      In mid-2015, Uber began exploring ways to scale ML across the organization, avoiding ML anti-patterns while standardizing workflows and tools. This effort led to Michelangelo.

      Michelangelo consists of a mix of open source systems and components built in-house. The primary open sourced components used are HDFS, Spark, Samza, Cassandra, MLLib, XGBoost, and TensorFlow.

      !

      See more
      PyTorch logo

      PyTorch

      1K
      1.1K
      42
      A deep learning framework that puts Python first
      1K
      1.1K
      + 1
      42
      PROS OF PYTORCH
      • 14
        Easy to use
      • 11
        Developer Friendly
      • 10
        Easy to debug
      • 7
        Sometimes faster than TensorFlow
      CONS OF PYTORCH
      • 3
        Lots of code

      related PyTorch posts

      Server side

      We decided to use Python for our backend because it is one of the industry standard languages for data analysis and machine learning. It also has a lot of support due to its large user base.

      • Web Server: We chose Flask because we want to keep our machine learning / data analysis and the web server in the same language. Flask is easy to use and we all have experience with it. Postman will be used for creating and testing APIs due to its convenience.

      • Machine Learning: We decided to go with PyTorch for machine learning since it is one of the most popular libraries. It is also known to have an easier learning curve than other popular libraries such as Tensorflow. This is important because our team lacks ML experience and learning the tool as fast as possible would increase productivity.

      • Data Analysis: Some common Python libraries will be used to analyze our data. These include NumPy, Pandas , and matplotlib. These tools combined will help us learn the properties and characteristics of our data. Jupyter notebook will be used to help organize the data analysis process, and improve the code readability.

      Client side

      • UI: We decided to use React for the UI because it helps organize the data and variables of the application into components, making it very convenient to maintain our dashboard. Since React is one of the most popular front end frameworks right now, there will be a lot of support for it as well as a lot of potential new hires that are familiar with the framework. CSS 3 and HTML5 will be used for the basic styling and structure of the web app, as they are the most widely used front end languages.

      • State Management: We decided to use Redux to manage the state of the application since it works naturally to React. Our team also already has experience working with Redux which gave it a slight edge over the other state management libraries.

      • Data Visualization: We decided to use the React-based library Victory to visualize the data. They have very user friendly documentation on their official website which we find easy to learn from.

      Cache

      • Caching: We decided between Redis and memcached because they are two of the most popular open-source cache engines. We ultimately decided to use Redis to improve our web app performance mainly due to the extra functionalities it provides such as fine-tuning cache contents and durability.

      Database

      • Database: We decided to use a NoSQL database over a relational database because of its flexibility from not having a predefined schema. The user behavior analytics has to be flexible since the data we plan to store may change frequently. We decided on MongoDB because it is lightweight and we can easily host the database with MongoDB Atlas . Everyone on our team also has experience working with MongoDB.

      Infrastructure

      • Deployment: We decided to use Heroku over AWS, Azure, Google Cloud because it is free. Although there are advantages to the other cloud services, Heroku makes the most sense to our team because our primary goal is to build an MVP.

      Other Tools

      • Communication Slack will be used as the primary source of communication. It provides all the features needed for basic discussions. In terms of more interactive meetings, Zoom will be used for its video calls and screen sharing capabilities.

      • Source Control The project will be stored on GitHub and all code changes will be done though pull requests. This will help us keep the codebase clean and make it easy to revert changes when we need to.

      See more
      Conor Myhrvold
      Tech Brand Mgr, Office of CTO at Uber · | 8 upvotes · 1.3M views

      Why we built an open source, distributed training framework for TensorFlow , Keras , and PyTorch:

      At Uber, we apply deep learning across our business; from self-driving research to trip forecasting and fraud prevention, deep learning enables our engineers and data scientists to create better experiences for our users.

      TensorFlow has become a preferred deep learning library at Uber for a variety of reasons. To start, the framework is one of the most widely used open source frameworks for deep learning, which makes it easy to onboard new users. It also combines high performance with an ability to tinker with low-level model details—for instance, we can use both high-level APIs, such as Keras, and implement our own custom operators using NVIDIA’s CUDA toolkit.

      Uber has introduced Michelangelo (https://eng.uber.com/michelangelo/), an internal ML-as-a-service platform that democratizes machine learning and makes it easy to build and deploy these systems at scale. In this article, we pull back the curtain on Horovod, an open source component of Michelangelo’s deep learning toolkit which makes it easier to start—and speed up—distributed deep learning projects with TensorFlow:

      https://eng.uber.com/horovod/

      (Direct GitHub repo: https://github.com/uber/horovod)

      See more
      Keras logo

      Keras

      926
      959
      14
      Deep Learning library for Theano and TensorFlow
      926
      959
      + 1
      14
      PROS OF KERAS
      • 5
        Easy and fast NN prototyping
      • 5
        Quality Documentation
      • 4
        Supports Tensorflow and Theano backends
      CONS OF KERAS
      • 3
        Hard to debug

      related Keras posts

      Conor Myhrvold
      Tech Brand Mgr, Office of CTO at Uber · | 8 upvotes · 1.3M views

      Why we built an open source, distributed training framework for TensorFlow , Keras , and PyTorch:

      At Uber, we apply deep learning across our business; from self-driving research to trip forecasting and fraud prevention, deep learning enables our engineers and data scientists to create better experiences for our users.

      TensorFlow has become a preferred deep learning library at Uber for a variety of reasons. To start, the framework is one of the most widely used open source frameworks for deep learning, which makes it easy to onboard new users. It also combines high performance with an ability to tinker with low-level model details—for instance, we can use both high-level APIs, such as Keras, and implement our own custom operators using NVIDIA’s CUDA toolkit.

      Uber has introduced Michelangelo (https://eng.uber.com/michelangelo/), an internal ML-as-a-service platform that democratizes machine learning and makes it easy to build and deploy these systems at scale. In this article, we pull back the curtain on Horovod, an open source component of Michelangelo’s deep learning toolkit which makes it easier to start—and speed up—distributed deep learning projects with TensorFlow:

      https://eng.uber.com/horovod/

      (Direct GitHub repo: https://github.com/uber/horovod)

      See more

      I am going to send my website to a Venture Capitalist for inspection. If I succeed, I will get funding for my StartUp! This website is based on Django and Uses Keras and TensorFlow model to predict medical imaging. Should I use Heroku or PythonAnywhere to deploy my website ?? Best Regards, Adarsh.

      See more
      scikit-learn logo

      scikit-learn

      900
      943
      36
      Easy-to-use and general-purpose machine learning in Python
      900
      943
      + 1
      36
      PROS OF SCIKIT-LEARN
      • 20
        Scientific computing
      • 16
        Easy
      CONS OF SCIKIT-LEARN
      • 1
        Limited

      related scikit-learn posts