This article is based on an interview with Kubernetes co-founder Brendan Burns who appeared on the Dev Interrupted podcast.
The success of Kubernetes was never preordained - it took years of work.
While today it has grown to be one of the largest and most popular open source projects and become the go-to API for building cloud-native applications worldwide - it almost wasn’t even open source.
Since its start in 2014, Kubernetes (an open-source orchestrator for deploying containerized applications) has transformed from a tiny project co-founded by three people, Joe Beda, Craig McLuckie, and Brendan Burns, into a production-grade infrastructure that powers large-scale production applications in various fields, from machine learning to online services.
Created with the intent to simplify the task of building, deploying, and maintaining distributed systems, it allows people the world over to achieve new levels of velocity, agility, and reliability. Over the years, Kubernetes has grown into a large, successful open-source community - but it was a long journey getting there.
What is a container?
Before jumping into the history of Kubernetes, let’s first define a “container” because it often has a broad set of meanings.
Fundamentally, a container is the process of taking an application and packaging it, building a binary representation of the pieces that make up that application like the software, configuration files, etc., and having a protocol for distributing it around the world.
There are three pillars of what became known as containers:
- Packaging everything so it's exactly the same, for instance, on a laptop as it is out in the cloud
- The distribution of step 1 needs to occur easily and around the world
- Creating an environment where a bug in one component of the process doesn’t affect another component
How it started
When we interviewed Kubernetes co-founder Brendan Burns on the Dev Interrupted podcast, he told us that as an engineer, he found himself gravitating towards spaces with opportunity. While working at Google, he noticed that Cloud had a lot of white space and thought it would be an attractive space to work in. At the time, he led a small team of about seven engineers and decided to transition his team over to Cloud.
At the same time, his eventual Kubernetes co-founders Joe and Craig created Compute Engine, the virtual machine product for Google Cloud, and the three of them began to work together in Google’s Cloud division. While Joe and Craig focused on compute, Brendan worked in config management on things like CloudFormation and Terraform.
Ideas were starting to coalesce, and the three of them were witnessing the challenges people faced trying to adopt Cloud - a far too difficult process. There were also some internal systems at Google, in particular a system called Borg, a cluster manager that’s still used today, that served as the initial inspiration for the three developers as they dreamt up Kubernetes.
However, none of it would have been a reality without Docker.
Docker changes everything
As a prerequisite to the functionality of Kubernetes, people needed to be motivated to build container images and run containers. Docker was the startup that came along and convinced people why they should care about containment. All of a sudden, a use case existed, and an amazing opportunity presented itself.
Docker didn’t have a lot of experience at scale, and they were focused on one machine, with a container and daemon on that machine - what they were lacking was orchestration. If a system was built that could act as a container-orchestrator, it represented not only a massive opportunity to change the market but to change the entire cloud landscape.
When you think about what it takes to deploy an application up to the cloud or even to an on-premise collection of machines, it’s a lengthy process. It requires you to package up an application, distribute it, keep it running, have load-balanced traffic between the various pieces of the application, and an API to tie it all together.
Prior to Kubernetes, some of these systems were in place, but nothing like today. Kubernetes is responsible for mainstreaming the idea of a distributed systems application environment for building and constructing distributed systems that span machines far and wide.
With the need for orchestration realized, the next step was selling the idea to executives.
Selling open source
Convincing people that it was possible and a good idea was pretty straightforward. There were folks at Google who understood what Joe, Craig, and Brendan were trying to do. The real battle was fighting to make Kubernetes open source. As Brendan shared in our interview, they had a lot of internal arguments at Google about it being open source.
Mostly it came down to money and control. From a business perspective, if a product or system is massively successful and you’re the only one who can sell it, then you’re in a great position. Conversely, Brendan told us that he always felt that Kubernetes would only be massively successful if it had an ecosystem, and the best way to foster an ecosystem was to make it open source.
This viewpoint is centered around the community that comes together to build the software. An amazing community formed early on of people who helped build docs, who helped build tutorials, who would talk about their work at conferences, and then an ecosystem of companies that were betting their whole business on the success of Kubernetes. Startups began popping up, saying things like, “Well the prerequisite for using my monitoring software is that you have a Kubernetes cluster.” All of the attention and goodwill formed a sort of virtuous cycle around Kubernetes.
Success has a way of looking easy
Soon enough, Kelsey Hightower, principal engineer for Google Cloud and Brendan’s co-author of the book Kubernetes: Up and Running: Dive into the Future of Infrastructure, came along and started doing a ton of evangelism and driving attention towards Kubernetes
It can be easy to look back and assume that it was easy, because Kubernetes just took over. It's present in every major public cloud at this point, people expect it to be in new systems. But the truth is that in those early years, it took a lot of hard work to build and evangelize Kubernetes.
Brendan shared with us that his hope for the future is that the bits of Kubernetes sort of fade into the background. It’ll be there, and it’ll be important, but it won’t be talked about or thought about from day to day because, as he puts it, “There’s so much more that needs to be built.”
Thanks for reading! If you want to stay up-to-date with what top engineering leaders are thinking about, subscribe to the Dev Interrupted Substack.
You'll get access to weekly articles, podcasts, and news from the best engineering leaders in the industry. Enter your email below to subscribe and be a part of our growing community!
Do you really need developer experience tools? Yes, you do, and we'll show you why: Your devs are mentioning their code is constantly stuck. They’ve been pushing code, but reviews are taking forever. So by the time the code gets back to them, they’ve already mentally moved on.
On top of that, your CTO has seen that your cycle time has increased, and wants you to formulate a plan to reduce it without eating into the budget. Clearly, you’ve got a lot to do.
You’ll need to roll up your sleeves and start working on your developer experience (DX) — a surefire way to help devs work better, leading to massive improvements in your PR processes and cycle times. A better DX will also help you figure out what’s putting a wrench in your system, so you can get to improving your engineering benchmarks across the board.
But you don’t need to do all the heavy lifting yourself! One part of DX is using the best developer experience tools to make the process as smooth as possible so you can keep up with demand, even if you can’t hire more devs.
In this article, we’ll show you some of the best developer experience tools around so you can save weightlifting for the gym!
Table of Contents
Top 11 Developer Experience Tools
Developer experience isn’t a set list of requirements. It’s a methodology that helps developers complete tasks as easily as possible, whether they’re pushing code to reviews or implementing common features without doing it all from scratch.
For you, it means empowering your team with the tools that help their overall development process — from ensuring code doesn’t stay stuck in PR limbo, to streamlining processes and improving important metrics like cycle time.
A good developer tool isn’t there to de-stress software developers — it’s there to improve their workflow and environment. So here are eleven DX tools we think can help you and your other devs!
1. Netlify
Netlify provides an innovative and quick route to using your APIs and tools of choice, enabling devs to collaborate and develop the best sites and apps. It’s a CI/CD infrastructure tool backed with automation and a powerful CLI to sync all your devs’ production environments.
Netlify also adopts a hands-off approach, which improves devs’ experience. This DX tool’s smooth setup system also allows devs to jump between environments when needed, cutting down on tedious upkeep. And this translates to an overall better developer experience.
This great DX tool empowers you and your team to use all the tools you know and love, integrating nearly anything with an API. The Netlify CLI also ensures all the devs on your team have identical environments, eliminating the hassle and time spent on setup.
2. Retool
Retool offers the fastest way to build internal web apps for your team’s needs. It allows you to read data from almost any database, including relational databases like PostgreSQL and MySQL or NoSQL databases like MongoDB and Firebase. This DX tool also offers a robust drag-and-drop system to create no-code web apps in minutes.
You can definitely use this platform to build a great developer experience. And when devs can whip up internal tools, they’ll have everything they need for success. Teams will also have the data or tools they need for a specific part of their workflow. And this is a huge +1 to their experience. 🆙
3. Auth0
Building custom authentication in your source code can pose huge security risks, so it’s a pretty bad practice. But with Auth0, devs can create feature-rich authentication without risking your customers’ data.
This developer experience tool also gives your teams more options, like built-in bot detection, SSO logins, and role-based access control. All these features come in a simple package that works with nearly any programming language. Auth0 has made considerable strides in making its DX platform as easy to use as possible.
The tool also gives all your teams the same functionality, whether they use no code, low code, or pro code methods. This means your devs will have the same result no matter what, and they won’t struggle to create a custom solution that works for them. Talk about major time savings and productivity boosts!
Source: Imgflip.com
4. Flightcontrol
AWS is a definite powerhouse for dev teams, but it isn’t known for its warm embrace. It’s more like a mean personal trainer, electro-shocking you to hit your personal best in burpees. But Flightcontrol aims to free you from that grip, giving you complete control and ownership over your AWS, so you can create a platform that works with you, not by you.
Flightcontrol also provides flexibility with a GUI- or code-based configuration approach to your deployment services and environments. This tool even gives devs all the power between GitHub and AWS, automating the tedious tasks you all know and hate. And with those annoyances out of the way, your devs have more time to push code.
5. Port
Port understands the goal of platform engineering is to provide the best DX possible. So they designed their tool to go as far as possible to ensure it with their internal developer portal. Port provides an organized catalog containing details about all your software, services that use your software, and environments hosting these services. This developer experience tool lets you see what you’ve deployed and where. This way, you gain insight into your overall architecture, development lifecycle, and your team’s collective knowledge.
These insights can also give you actionable information to spot bottlenecks in your processes and eliminate them, so devs can be as productive as possible. This combination of visibility and control substantially improves DX.
6. PlanetScale
Databases are complex and terrifying for some devs, but they don’t have to be. Enter PlanetScale, an advanced serverless MySQL platform. This DX tool leverages the power of Vitess — the tech that helps YouTube scale to hundreds of millions of videos — to change the database landscape for the better.
PlanetScale allows teams to host and manage MySQL databases with incredible scaling and flexibility, so you don’t need to worry about the tiny details of database management. PlanetScale also helps you concentrate on application development instead of putting in administrative or operational effort to maintain your app-dependent MySQL database.
In a nutshell, this developer experience tool reduces the tedious work devs have to do, substantially improving DX and productivity. PlanetScale helps your devs simplify tedious everyday tasks, which in turn boosts productivity.
Check out this discussion with PlanetScale CEO Sam Lambert, where he talks about the annoyances of enterprise SaaS and how it affects DX:
7. Render
Render offers a unified platform for building and running all of your apps and websites. With Render, you can select services like web apps, static sites, messaging queues, databases, containerized apps, and jobs scheduled for deployment.
You can also deploy these services in seconds and even update your apps or websites when you have a patch or new versions to deploy. Render is basically the zero DevOps cloud platform because it eliminates DevOps work. In doing so, Render enhances DX by reducing the friction that comes with building and deploying services.
8. HostedHooks
HostedHooks is a webhooks service platform whose JSON API and integrations make triggering webhook events from your applications simpler than ever. All webhooks with HostedHooks are encrypted with SSL and guard against replay, forgery, and man-in-the-middle attacks.
With HostedHooks, devs can also set up mock webhooks to give users more options overall, and it can pass data to send notifications to the team when needed. This developer experience tool helps expand communication with minimal effort, so nobody gets left out of the loop.
9. Doppler
If you’ve ever felt overwhelmed juggling multiple app or environment secrets, passwords, and .env files, Doppler can come to the rescue. Doppler is a SecretOps platform known for handling secrets effectively and securely across environments, devices, and teams. This tool also lets you put your apps, sites, or environments’ secrets management into production within minutes.
Doppler is simple to use no matter what tech stack you have, which enriches your DX. It also reduces the time developers spend configuring their environments, so they can focus their efforts on getting things done. And we all know that devs are happiest when they’re coding .
10. Prefect
An entirely new method of automating dataflows, Prefect is an open-source orchestration platform. Prefect allows you to use your current infrastructure to run programs and protect data. It also gives you comprehensive control and monitoring capability over your workflows.
Your developers can rely on Prefect to handle scheduling, infrastructure management, failures, logging, monitoring, concurrency, and more. Prefect’s cloud platform can also get data pipelines or workflows up and running with little effort. And that’s a prefectly — err, perfectly — good way to smoothen your team’s tasks and improve developer experience.
10. gitStream
As I’ve already noted, devs are happiest when they’re coding, but a close second might be when their PR finally gets merged. Merging devs = happy devs. And happy devs = more productive devs.
gitStream is a continuous merge tool that uses workflow automation to optimize the PR review process and improve your merge frequency. Repo-owners can configure rules that classify each pull request and automatically route that PR down a unique merge path. These rules can automatically find the right reviewer, check for service deprecation, add context tags, and more.
With gitStream, you can codify your merge policies and use policy-as-code to standardize and audit certain best practices. And when you automate PR routing, you can achieve the level of code quality necessary for the ongoing success of your org. It’s truly a win-win for you and your devs.
Check out this video on our YouTube channel where LinearB co-founders, Dan Lines and Ori Keren, explain gitStream!
How to Choose the Right Developer Experience Tools
Achieving a positive developer experience will improve how developers work. And ultimately, this will boost their morale and improve your developer retention rate. Developer experience tools contribute to a perfect balance of coding and non-coding tasks among your devs, lifting devs up so they can complete their jobs as easily as possible. DX tools also automate some non-coding tasks in your software development lifecycle.
Regardless of the tech stack you choose, offering a great DX should be at the forefront of your developer platform. All of the tools we’ve covered work in some way to make the day-to-day easier for your team members. For example, if you choose Netlify to build and deploy your apps and sites, and Prefect for data pipeline development, you can also use gitStream for managing your PR process. The best part is that gitStream works well with all the tools we mentioned above. It’s also free, so you can go ahead and start using it without passing by the finance department.
Fact: Over 26% of adults in the United States have some sort of disability. To ignore such a massive part of the population would be ill-advised for any company, legally, financially, and above all, ethically. How can you stay ahead of the curve when it comes to maintaining a progressive and responsive organization?
We reached out to two experts - Alwar Pillai and Perry Trinier of Fable – on the topic of designing products that have inclusivity for people with disabilities at their core. Here are the 3 things they think every engineer, developer and product designer needs to know about inclusive design and how it will inevitably affect the future of their companies.
1. Inclusive design has already brought us Alexa, Siri and countless other smart gadgets
Often times people assume that tech companies are driving innovation through focus groups or trying to cater to the average consumer, but that’s not always true. Some of the greatest recent innovations in tech have been found by designing technology to be as accessible as possible to people with disabilities. By keeping the designing process inclusive, you maximize potential for growth.
Alwar Pillai: Each of us today use technology that’s been designed for assistive technology users first, from as simple as an electric toothbrush, which is designed for people with motor impairments, but this is something that everyone uses now… you have voice to text was for people with disabilities again. And now we have... Siri, and Alexa, and like dictation, and all of that existed because it was designed for people with disabilities first, so it is already proven that when you practice inclusive design, and design for the edge cases, there is that broader impact.
2. Inclusive workplace culture draws in better talent
When you put inclusivity and accessibility at the front lines of your work culture and development process, you not only maximize your potential customer base but increase your pool of applicants and make your workforce more efficient. Some of the best talent in the world of inclusive design comes from people who use accessibility technology daily. Maximizing your accessibility to potential employees gives your company the best shot at finding the right person for the job. What does it mean today to build an accessibility first dev culture?
Perry Trinier: I think it's like sort of the opposite of saying that accessibility is an afterthought. In this case, accessibility is absolutely primary. And it's also like a shared understanding on the team that accessibility isn't an extra feature or like a defect that they can backlog. It's just a table stakes dimension of the quality of what they build, and that they kind of aren't finished building what they're doing if it's still inaccessible.
Alwar Pillai: There's a lot of barriers when it comes to trying to build an inclusive team, to just the workplace tools that are out there, you know?... And so we've had to do a lot of... custom workarounds for some things. But it has resulted in every single person in the team understanding the impact of accessibility and taking that extra initiative and make sure whatever they're sharing with... each other internally is easily accessible to everyone.
3. Inclusive design’s influence is set to explode
There seems to be a cultural divide when it comes to inclusivity and many companies are hesitant to make the necessary changes to fuel a more accessible work culture. Making the effort to enact real change is necessary for the health of your business and the respect of the individuals who need accessible technology. More and more individuals and companies are seeing the need to stay current with inclusive design or, better yet, lead the way to establishing new and exciting ways to stay inclusive.
Perry Trinier: I think it's important to invest in helping the team members to build the knowledge and specifically set goals for reports to, for example, complete a course in accessibility. It's an important skill, just like security and performance are for front-end developers. And it should be treated in that same way for professional development. And there are tons of resources online courses on LinkedIn, Udacity. And there are lots of blog posts and talks by experts in the community like Marcy Sutton, and they’re directed to developers, like front-end developers who just need to learn what they need to know to be able to test their interfaces and to build experiences that everyone can use, so I would say that's the place to start is just with building up that capability.
Design is changing… Moving towards a more inclusive future
There is a fundamental gap in what is provided and what is needed for many people who use accessibility technology. The way of the future is to practice an inclusive design culture and keep every person in mind in your design process.
Alwar Pillai: The way we build digital products right now is broken. There is a digital divide between the experiences of people with disabilities and people who are able bodied. And we as people who are part of engineering teams and engineering cultures, it's our responsibility to make sure we change the way we build products and make the process more inclusive, so that more and more people have access to the products that we're building.
If you want to know more about Fable and their ability to help your company evolve and grow while staying accessible to everyone, please visit www.makeitfable.com. Be sure to listen to and review this interview’s podcast and many others on Apple Podcasts, Spotify, Stitcher, YouTube or any of your favorite podcasting apps. Also, be sure to join the Dev Interrupted Discord community where we have conversations about topics just like this going all week long.