Developer Platforms for Startups
As discussion about developer control planes and centralized developer platforms reach a crescendo in the crowded cloud native space, it’s safe to say that platforms for Kubernetes developers can drive everything from curiosity to productivity.
There seems to be a growing consensus about using developer platforms to reduce complexity — leading to centralized platforms, and by extension, a more centralized developer experience.
And while startups are one of the most vocal proponents of the idea of simplification through platforms, a number of these smaller organizations have questions about how effective or efficient developer platforms would be for them.
Most industry focus shines a light on the Big Tech/FAANG (tech companies Facebook, Amazon, Apple, Netflix and Alphabet/Google) approach to platforms, in cases where large companies have unlimited resources and larger budgets.
So how can budget-conscious startups reap the benefits of developer platforms without having to rival massive companies’ investment in them?
Developer Platforms for Small Teams
In 2021, Dave Sudia, the CTO of U.S.-based nonprofit UPchieve, shared insights on how a developer control plane helped his small team unleash big results. He knew UPchieve’s mission — to democratize access to academic support through free, 24/7 online tutoring for high school students from low-income communities — wasn’t achievable without streamlining processes that allowed his team to iterate quickly across multiple dev setups.
At the time, UPchieve had a 3.5-person engineering team that was responsible for the “911 of academic support” site they’d created for more than 10,000 students.
Sudia himself admitted that before his experience with UPchieve, he cautioned small teams not to use Kubernetes, largely because of its complexity. But, as he shared, “Kubernetes is where the exciting things are happening in dev tooling,” and he realized it could be a way to innovate creatively and do more with less.
Developer Experience: Create around Constraints
As an organization operating largely on grant-based funding, UPchieve had a bootstrap approach to supporting a long-term business strategy. There is no time or funds to burn. Being resource-limited “makes interesting opportunities and constraints that make you creative,” said Sudia.
A passion for enabling developers to do their best work and move quickly without breaking things ultimately led Sudia to follow the Kubernetes path forward — and he is not alone. A number of startups have found that the vast cloud native tooling landscape creates opportunities to be more lean, agile and creative in delivering on and simplifying the developer experience. That is, if you’re careful about tooling, which leaders echo throughout the ecosystem.
With a paved path and the right abstractions, the size of the team doesn’t matter. According to Sudia, “I don’t chase tooling for its own sake, but I knew Kubernetes is where we would be able to execute with a minimal footprint. A developer control plane lets us do this. We have one app, a monolith, but we have multiple environments that need to be kept separate. That plays into how we use tooling. We need to keep our process simple, right? We need powerful tools, but they can’t bog us down.”
The developer control plane works as a stable jumping-off point to which developers can continually return, as it provides a clear, opinionated way to work and empowers efficiency and saves time in the long run.
Time Saved with Tooling: Embracing Cloud Native at the API Gateway
For Sudia, tooling is where efficiencies are found. One tool, Ambassador Edge Stack (AES), has been a constant part of Sudia’s own cloud native ecosystem since the beginning, even as other tools changed. “AES is easy to install and just works. I can always recommend it without issue. When I am trying to pay for support or advanced features, like at my last organization, AES was easy to get budget for.”
Sudia explained, “I run a minimum number of highly available instances. At our peak, we hit about 5,000 requests per minute. And that sounds like a low number. But I like to say, ‘We have lots of headroom. We are not even touching the amount of traffic that we could be handling.’ Also, I’m really proud of being a tiny engineering team with three people that offers end-to-end encryption.
“We are encrypted all the way into our cluster via Ambassador Edge Stack, and then from Ambassador to Linkerd, where we use inner service encryption. In my last org, we never really hit end-to-end encryption despite having 55 engineers and millions of requests a day. The ease of getting security in ingress is super easy and nice.”
Integral Tooling: Searching for a Fast Inner Dev Loop
Another key to tooling, in Sudia’s experience, is adopting tools that are not just for use in special circumstances, but that can become integral to your work, your speed and efficiency. And, in the case of UPchieve, your ability to get rid of tasks that do not scale. In part, this is how his team accelerated their use of, for example, Telepresence.
Sudia’s team has become self-proclaimed “super-heavy users of Telepresence” because they are a technologically divergent team working in a variety of environments and across a variety of operating systems. Sudia works primarily on a Mac, but sometimes on Linux and mainly with Jetbrains. Other developers on the team use Macs with VS Code, while one developer does most of his work on a remote Ubuntu VM.
Sudia explained, “We still need to work together — quickly and easily — and Telepresence lets us do this. One developer lives in Telepresence because he can’t actually do local development because of how he’s chosen to set up his dev environment. He can’t access localhost because the localhost is on a remote VM. His morning routine is to get up, start Telepresence, and then he works all day going through a custom URL and is able to hit the functionality on his remote machine, and that’s how he develops.
“This speaks to the speed and ease of the Telepresence tool itself. It allows us to do more than just a ‘here, let me share this code with you real quick’ thing. It works to a point where a developer can live in it.”
According to Sudia, traditionally with local development, organizations had to constantly commit code to version control, crank the handle on the build pipelines, push to a dev environment to do testing, and then promote code to staging and then production. This process was necessary even for tasks requiring a large amount of rapid iteration. It also constitutes a lot of potentially unnecessary steps and adds overhead in terms of time when something like Telepresence lets development teams skip steps and save time.
“Every time we needed to check something, we had to wait seven minutes for it to build, and then we had to wait another couple of minutes for deployment. Now, we just run Telepresence and check it in staging. If we can cut nine minutes off every commit check, which probably happens 10 to 50 times per day per developer, that is an incredible amount of time and productivity that Telepresence has delivered for us.”
Using Telepresence for ‘Tiny Canaries’
Sudia’s team finds this approach less risky than pushing code through the entire pipeline and deploying it, only to have to roll it back. Telepresence routes select requests to a developer’s laptop and empowers them to make code changes and then roll it out with just a few clicks. In a sense, Sudia shares, it’s like a tiny canary for testing.
“Without this step, the risk is you think you’ve fixed a problem, and you roll it out to production only to realize that, ‘Oh, actually, we haven’t fixed it.’ And then you have to roll the whole thing back. And in the meantime, you’ve got your 5, 10, 15, 20% of traffic in canary until you realize it didn’t work or, potentially if you’re not canary, all of your requests are going through a system that still isn’t fixed.”
The process at UPchieve is to do actual development in a semi-staging environment, but really, it’s through Telepresence against their staging infrastructure.
“With Telepresence, when we’re confident about something, we merge to main because we’ve got really high confidence about it. Then it goes through CI/CD, the CD process pushes to staging, we do one last sort of QA smoke testing check, and then we push that to production. So that pipeline becomes very quick because the vast majority of testing has happened in a high-validity environment before it ever goes through the pipeline.”
Summary: Transparency and Efficiency with Developer Control Planes
Nonprofit or small startup, either way, Sudia said, every small organization can benefit from saved time, resources and greater efficiency with relevant, carefully selected tools put together in a central developer control plane. Regardless of whether an organization is a grant-funded nonprofit or a venture-capital-backed company, organizations of all sizes are looking for efficiencies.
Money saved on investments in your infrastructure can get you another engineer. Being able to easily configure security and reliability guardrails on an API gateway and then letting developers configure their own API endpoints via self-service can free up the ops team to focus on other high-value opportunities across the business.
Massively reduced build time could equal the development of another feature. Tools like Telepresence help increase fast feedback with cloud native technologies and become a valuable asset as the number of services grows in a microservices-based architecture.
This is true for every organization, and a developer control platform built from open source tools supports the developer experience, improving efficiencies across the full app development life cycle so they can code, test, ship and run their Kubernetes workflows fast and with confidence.