One of the most common failure modes in microservice adoption isn’t a technical problem — it’s a process problem. Deployment planning gets neglected until the last minute, causing delays, organisational friction, and a growing sense that microservices simply aren’t worth the trouble.
The good news is that a modest amount of upfront preparation dramatically reduces that friction. This article, adapted from a piece originally published on enterprisersproject.com, walks through a structured Ready – Aim – Fire framework for aligning development and DevOps teams before a microservice goes to production.
Why Deployment Planning Is Often an Afterthought
Developers are understandably focused on building features. Operations teams are focused on keeping existing systems running. The result is that the handshake between the two — deploying a new microservice into production — is often the least-planned part of the entire effort.
Microservices also introduce real complexity that a monolithic WAR file dropped onto a Tomcat server does not. Container orchestration, service discovery, secrets management, network policies, and distributed tracing all create new requirements that must be understood — and automated — before you ship.
The goal of the framework below is to surface those requirements early, assign ownership, and drive toward a push-button deployment pipeline that supports the “you build it; you run it” model.
Ready: Understand What You Are Actually Deploying
1. Identify Dependencies and the Technology Stack
Start by cataloguing everything the microservice depends on. Deploying a containerised service into Kubernetes is considerably more involved than placing a WAR file on a Tomcat server. If your organisation has no Kubernetes infrastructure in production yet, that gap is itself a major dependency that needs a plan.
Also consider the relationship back to existing applications. If you are extracting functionality from a monolith into a new microservice, the older application now has a runtime dependency on the new service. That dependency must be versioned, documented, and accounted for in your deployment sequencing.
2. Write Down Every Deployment Step
This sounds obvious, but “just cf push” is not a deployment runbook. Create an exhaustive, ordered list of every step needed to move the service from a developer’s laptop to production. This exercise almost always surfaces hidden dependencies.
Producing this list requires conversations across organisational boundaries:
- DevOps and platform engineers — pipeline tooling, environment configuration, secrets injection
- Site Reliability Engineers (SREs) — service-level objectives, alerting, on-call runbooks
- Database Administrators (DBAs) — schema migration strategy, connection pooling, credentials rotation
- Security teams — vulnerability scanning, access controls, compliance sign-offs
Yes, this is uncomfortable for teams that are used to working in silos. That discomfort is the point: breaking down those silos now is far less painful than a production outage later.
3. Classify Each Step: Automated, Automatable, or Manual
Once you have a full list of steps, divide them into three buckets:
- Already automated — steps your pipeline already handles reliably.
- Can be automated — steps that are currently manual but have a clear technical path to automation.
- Cannot yet be automated — steps that require a human decision, a regulatory approval, or a tool that doesn’t exist yet.
Bucket three is where your risk lives. A truly “you build it; you run it” deployment model requires that the path to production be fully automated — or at minimum, that any required human approvals be as frictionless and auditable as possible. If too many steps remain manual and unowned, you should reconsider whether your organisation is ready to operate this microservice independently.
Aim: Plan the Work Before You Start the Work
Tackle the Biggest Blockers First
With your dependency list and step inventory in hand, prioritise by impact. If a compliance approval step takes two weeks based on ticket history, that is your critical path. The question to answer is: can the approval process itself be automated, or does the underlying work need to change so that approval is no longer required?
This phase is largely project management work. Identify blockers, find the stakeholder who owns each blocker, build a plan to reduce or eliminate it, and repeat. Getting a two-week manual step down to minutes — or seconds — often requires executive sponsorship and cross-team agreement, not just engineering effort.
Build vs. Buy: Make an Informed Decision
Use this phase to have explicit build-vs.-buy conversations about your DevOps toolchain. Typical questions include:
- Can the existing CI/CD pipeline that serves the monolith be extended to serve microservices, or does its architecture make that impractical?
- Is it worth upgrading shared tooling now, with future microservices in mind, rather than building a parallel pipeline?
- Are there open-source or commercial products that meet your requirements without significant custom development?
By this point you have a concrete requirements list — use it. Vague build-vs.-buy discussions that happen without requirements produce poor decisions. Decisions made against a specific, prioritised list of steps produce much better ones.
Fire: Execute Iteratively, Not All at Once
The automation you build for deployment is software — treat it accordingly. Don’t wait until it is perfect before using it.
- Start in development. Run every deployment through the new automated pipeline from day one, even when a manual workaround would be faster. The pipeline needs real usage to surface edge cases.
- Promote with the application. As the pipeline matures and proves itself in a lower environment, promote it to integration testing, staging, and eventually production in step with (or just ahead of) the application itself.
- Communicate continuously. Keep stakeholders informed at every stage. Early transparency builds trust, turns observers into advocates, and gives stakeholders time to raise concerns before they become blockers.
Just as you write post-mortems for application incidents, review deployment failures as a team. Each failure is a signal that an assumption was wrong or a dependency was undocumented. Fixing the underlying assumption is more valuable than fixing the symptom.
Don’t Forget to Celebrate — and Then Improve
The first production deployment of a new microservice represents a significant cross-functional achievement. Acknowledge it. Teams that celebrate milestones maintain the morale needed to sustain continuous improvement.
After the celebration, run a retrospective. What did the team learn? What assumptions turned out to be wrong? What would you do differently the second time? Feed those answers back into your process before the next microservice goes through the same journey.
Key Takeaways
- Deployment planning is as important as development planning — don’t leave it to the last sprint.
- Writing down every deployment step forces cross-team conversations that surface hidden dependencies before they become production incidents.
- The “Ready – Aim – Fire” framework — inventory dependencies, plan automation, then execute iteratively — gives teams a repeatable structure for each new microservice.
- A genuine “you build it; you run it” model requires a pipeline that is push-button from development through production. Manual steps are a risk that must be quantified and owned.
- Build-vs.-buy decisions are more productive when made against a concrete requirements list rather than in the abstract.
Microservices and DevOps are natural partners, but that partnership doesn’t happen automatically. It requires deliberate coordination across development, operations, security, and business stakeholders. The upfront investment in the Ready–Aim–Fire process pays dividends in every subsequent release.
Original source: The Enterprisers Project.