How Software Development Teams Can be More Productive with Platform Ops

Deploying, consuming, and developing APIs can be difficult. The Postman 2021 State of the API Report shows 39% of respondents spend between 10 and 20 hours of their week working with APIs. This number has grown since the previous report in 2020. 🤯

As APIs proliferate rapidly through an organization, teams experience new challenges.

• How do we create repeatable build and deployment processes?

• Do we have consistency in our architectural patterns?

• How do we maintain a delivery cadence as we continue to scale?

  
  

Luckily, a platform approach can help!

Strive for flow

With the rise of DevOps and self-contained, cross-functional teams, we've opened a world of opportunity for team autonomy. There is no longer one right way to accomplish tasks. Slices of business enablement, living under warm blankets of Bounded Contexts, can be built with different technology stacks to serve different requirements and preferences.

"You build it, you run it." In June of 2006, Werner Vogels, CTO of Amazon, proclaimed this mantra as a supporting factor to increased quality of service.

Teams are now responsible for owning the entire lifecycle of their applications, and depending on architectural coupling, may have the ability to iterate in isolation. One downside to this development is what Dr. Jean Yang refers to as the Software Heterogeneity Problem. When no two application stacks are alike, how can we assert quality and scale effectively? How does this impact developer experience? The outlook can appear fairly grim.

Don't worry. We can compensate for that!

The proliferation of APIs presents a pathway to scaling architecture and also encourages us to evaluate how we scale the communication between folks on different teams. 🤔

The approach detailed by Team Topologies teaches us how to model team composition for optimizing the flow of change. When it comes to scaling API teams, the most significant team topology in this approach is the Platform team.

High-level Overview of the 4 Team Topologies

Stream-aligned teams

Continue to follow DevOps patterns by building and running their software.

Enabling teams

Can parachute in to assist in leveling up.

Complicated Subsystem teams

Help build and maintain software requiring specialized knowledge.

Platform teams

Assist stream-aligned teams by off-loading lower-level responsibilities for cross-stream concerns.

Platform Ops for APIs

One or more Platform teams often manage a set of responsibilities. As a Platform Engineer or Operator, our customers are internal and our mission is to create a great experience for developers and operators. 🎉

Platform Engineering and Platform Ops are closely related, and in fact, they may be the same team in certain organizations. Teams may be composed in many different configurations. It can be helpful to separate the responsibilities. While Platform Engineering may deliver common services and boilerplate templates through a solution like Backstage, a Platform Ops team will be responsible for:

• Running a container orchestration system like Kubernetes
• Building reusable CI/CD pipeline assets
• Applying best practices at an infrastructure level

With a basic understanding of what a Platform Ops team might do, let's take a look at how having such a team might help scale API development.

Security

A common platform concern is securing communications. This may come in the form of:

• Network access control
• Continuous, dynamic application security testing (DAST)
• Authorization or security token service

Traffic management

If running on a common platform like Kubernetes, traffic management can all be delegated to the Platform Ops team. Examples:

• Rate limiting

• Dynamic target routing

• Quota management

  
  

See how API Gateways can help.

Testing

A Platform Ops team can offer a number of benefits for testing:

• Performance testing
• Continuous regression testing
• Chaos testing

Observability

Instrumentation comes in many different forms. While we should always have observability baked into our applications—which can be provided via templates—we must also have observability in our infrastructure. These activities can be surfaced to stream-aligned teams:

• Metrics

• Logging

• Tracing

  
  

These are often included in fairly advanced setups, such as Prometheus monitoring Pods in Kubernetes.

Governance

Finally, we come to governance. Consolidating on a platform approach, a Platform Ops team can support:

• Audit-ready design
• Running Architecture fitness functions
• Ensuring adherence to API design guidelines

Jumpstart a Platform Ops strategy

We've seen some of the issues that warrant a Platform Ops team: repeatable processes, architectural consistency, maintaining a release cadence. And we've looked at only a few of the responsibilities that can be managed by a Platform Ops team: Security, Traffic management, Governance. When evaluating a Platform Ops strategy for scaling API teams, there are a few questions to ask:

1. Are APIs expanding rapidly as we grow?
2. Do we already have a team responsible for Platform? Hint: Look to teams with "core" or "services" in their names.
3. What are the pressing business needs that might be best served by enabling stream-aligned teams with Platform Ops? Make a case.

Once a paved road to Platform Ops has been established, here are some tips for getting started:

1. Identify any platform need that can evolve into a self-service offering.
2. Score these opportunities in a cost-benefit analysis.
3. Pick the low-hanging fruit to help negotiate low-risk entry.
4. Measure developer productivity.
5. Implement a minimum viable platform.

Treat Platform Ops like an experiment, keep iterating to improve, and be sure to report your findings with the rest of the organization! 📢

Oh, and don't forget to sleep. Crafting a great developer experience is hard work. ✨

First Published here