The Battle Of Push-Based VS Pull-Based Deployment Strategy For DevOps In Every Startup

Software development processes are evolving day by day. Initially, many businesses used monolithic applications and manually tested them. However, things have changed over time. Microservice architecture and orchestration techniques along with CI/CD strategies are setting up new industry standards.

The two prominent flavors of GitOps: Push & Pull, have been a hot topic lately and are essential to the GitOps pipeline. Now, the question is which strategy you should choose for your startup? Before we discuss that, let us throw some light on these strategies:

What is a push-based process?

In this scenario, you use GitHub Actions or Webhooks to trigger your CI/CD tool to begin the build, testing, and deployment process. You can use various tools like AWS code pipeline, Azure CI/CD tools, Github actions, Jenkins, etc., to do that.


When your infrastructure is below 500 assets, it works like a charm, but beyond that, this method starts to fail because of the following reasons.

  1. If your DevOps/Infra operations team is maintaining untagged assets in cloud or data centers, they will tend to lose track of your assets, or they will spend time keeping assets in Google sheets.
  2. Servers are built to fail; at scale, one or the other servers won’t be responding when you are doing change management of the system.
  3. You will tend to keep your infra credentials like SSH password outside the servers, and PEM files will be roaming in your employee’s laptops and google drives or apple notes in plain text.
  4. It increases the load on the single or cluster of servers to deploy the change or product build, so finding a sweat capacity spot for your pushing infrastructure will keep changing as you add more assets.
  5. If push-based deployments are poorly implemented, it will keep pushing infrastructural drift in your system. Moreover, it will keep your engineering team busy with different functionality issues.

What is a pull-based process?

In this scenario, you can treat a cluster of servers like chef-server, AWS code deploys, or any other agent-based deployed in high availability formation to pull the build and auto-heal your infrastructure.

1_8XiQlujjlg7yGbrz4IOv2g.jpeg When your infrastructure is below 500 assets, it works like a charm, but beyond that, this method starts to fail because of the following reasons.

  1. You will have more human resources managing these configurations from GUI or not following other IaC practices, making it your single point of failure.
  2. With scale, you miss creating active-active or divide the blast radius of your infra assets. A logical group of services based on service type or product type would reduce the impact of failure.
  3. With scale deployment agents, maintenance and optimization become very tricky, job workload keeps increasing, and workload rises over the period. One day few servers will break, and the agent takes the troll, which is ignored to be optimized by the fellow DevOps engineers.
  4. Every startup engineering team wants to keep capacity for a product, but they don’t want to spend a dime on monitoring and observability frameworks. It keeps the business profitable, but as you scale, you need to find the right time to start spending because you literally cannot drive a car at a high pace without knowing monitoring and business data.

What is mutable vs. immutable infrastructure?

Mutable infrastructure can be updated and configured as per the requirement. You can treat the MySQL community setup used by most startups as a perfect example for mutable infrastructure. With mutable infrastructure, you can log in to servers, apply patches, update configuration, scale up/down it, etc.

On the other hand, Immutable infrastructure can never be modified once it is deployed. A perfect example is your docker images for your Kubernetes cluster.

The most prominent mistake startups make is by using push-based leading tools like Ansible for mutable infrastructure or not using the benefits of spot instances for their Kubernetes cluster. The combination that works well for startups uses a push-based strategy for mutable infrastructure and a pull-based strategy for immutable infrastructure. Both these strategies come along with their own set of pros & cons. The answer depends on your primary demand and how much customization you are ready to perform.

Push-based configuration management is better suited to static infrastructure, whereas pull-based configuration management is better suited to an excessively dynamic system.

While, the pull strategy is far safer since cluster credentials are not accessible outside the cluster, and this would boost security so significantly that the extra effort would be worthwhile.

Both approaches function and are not mutually exclusive, but it is critical to grasp their significant disparities.

Using a combination of the two could also work wonders, use the right tool and right strategy in the right problem.

Happy CI/CD!