 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
I recently wrote about the power of “drinking your own champagne” and the internal and external benefits of building and actively using your own software tools. In that article, I discussed how developer productivity and a better developer experience are positive outcomes of using your own tools.
What is the next step, though? As useful as a single tool can be, having random, orphan tools that are used haphazardly or by a single developer, while other developers in a team use whatever tools they want, limits the productivity we’re all trying to achieve.
An internal developer platform paves the path to frictionless development experiences, tying together both the standardized tools you need and unique solutions you select to meet your productivity and business goals.
Just as not every tool you use will fit every task, not every platform will suit your needs, and you can tailor your platform for your organization’s needs.
We know the concept of platform engineering is everywhere these days, and not without reason. Every cloud native organization is looking for viable ways to reduce complexity and give developers easy pathways to productivity. This can include everything from developer self-service, to offering a “paved path” to get their work done efficiently, to reducing developer cognitive load and guessing games, and so on. What this looks like will differ for every organization based on what you need to achieve.
At Ambassador Labs, we wanted to use and test our own tools, which are designed to:
Our platform view has focused on “champagne-drinking experiences” (weaving our own tools into the developer platform). We build what we need, but we know we are not unique in needing the tools we develop.
A developer platform exists to reduce developer toil and pave a “seamless path to production,” as Bo Daley of Zipcar said of good developer platforms. If this is the case, your platform is not just about drinking your own champagne but actively creating and bottling it.
What do I mean? I can point to the Ambassador experience as an example. We’ve built and used our own tools, but we don’t build all the tools we need. There are times that we need to find and use external tools to augment the platform and pave the path, which isn’t unique to Ambassador by any means. In fact, most cloud native organizations are deciding what makes up their developer platform, but the common denominator is the need for some kind of platform.
Director of DevOps at nesto, Mathieu Frenette, echoed this, “A platform is everything that we can provide as tools, components and foundations to help developers do their job more easily, faster, and ideally with more robustness, predictability, repeatability and confidence. I would like to emphasize confidence because confidence is key to and a prerequisite for innovation. If we want developers to be at ease trying out new things, they need to be confident that they have a solid platform underneath them.”
Tools are key enablers — not just enabling the developer experience and productivity, but also the culture. Your platform can and should reflect your culture. As Frenette shared, the platform enables innovation, if that is what the platform is built to do. The platform becomes your “champagne-bottling operation” because it makes the internal developer experience more consistent across your organization, is unique to your organization and will hopefully open the door to creative thinking.
Frenette paraphrased Albert Einstein in describing how his organization thinks of platforms: “Einstein said, ‘You can’t solve a problem with the same thinking that created the problem.’ One key to building and making a developer platform successful is having a platform team that can take a step back from the daily noise and figure out the value stream, bottlenecks and solve at that level, routinely bringing in a fresh perspective.”
For us, “drinking our own champagne” is very much about creating and using our own tools, and then shaping a platform that incorporates our tools and supports developers in their work. But keeping the champagne flowing is more than just the champagne/tools themselves. It’s about the organizational culture and how that is reflected in the platform, processes and tools that result.
The best vintage is one in which all the ingredients — people and their experience, tools and processes — meld to make it what it is. The “champagne” flows because of the culture underpinning well-functioning tools and developer platforms.
