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!
Companies Mentioned
Coins Mentioned
Deploying, consuming, and developing APIs can be difficult. The Postman 2021 State of the API Report shows . 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 , can be built with different technology stacks to serve different requirements and preferences.
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 . 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 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 , 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
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 can help.
Testing
A Platform Ops team can offer a number of benefits for testing:
Performance 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 .
Governance
Finally, we come to governance. Consolidating on a platform approach, a Platform Ops team can support:
Audit-ready design
Running
Ensuring
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:
Are APIs expanding rapidly as we grow?
Do we already have a team responsible for Platform? Hint: Look to teams with "core" or "services" in their names.
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:
Identify any platform need that can evolve into a self-service offering.
Score these opportunities in a cost-benefit analysis.
Pick the low-hanging fruit to help negotiate low-risk entry.
.
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. ✨