There is no denying the fact that Kubernetes has experienced widespread adoption in the last few years. Its automated deployment and scaling capabilities have made it easier and more convenient for developers to manage and develop advanced applications and services.
Kubernetes brings some challenges to developers. They need to learn some new concepts, how they connect to each other, and most importantly, how to develop applications using a Kubernetes cluster.
The possibilities that Kubernetes has brought to the container orchestration space are vast. Kubernetes simplifies the deployment and operation of such systems. However, from a developer’s point of view, it may not be as simple as their previous workflows; there are some nuances of the system to be learned.
Applying the notion of user experience (UX) to software engineering, developer experience takes place on the other side of the product. The concept of developer experience describes how developers feel about working with or within a system.
In this series, we’re looking at alternatives to using Docker Compose for building apps that run in Kubernetes clusters. While Compose is a handy way to stand up apps locally, there are advantages to running your apps in a Kubernetes environment while you develop.
As more developers use Kubernetes, a variety of deployment tools are emerging to help them. Three interesting examples are Skaffold, Tilt, and DevSpace. While they all assist in building and deploying on Kubernetes clusters, their approaches are noticeably different.
Kubernetes is an excellent open-source container orchestration platform that brings automatic scaling, automatic recovery, observability, and many more features. Since it differs from traditional operations, it has changed the development and deployment workflows as well.
In recent years, many companies have turned to containerization for application delivery. However, containerization in an enterprise or production-grade environment presents different levels of complexity in terms of managing containerized applications at scale.
Octant is one of the best-known tools in the Kubernetes dashboard space. It’s a project that Bryan Liles built a lot of back when he was at Heptio.
Headlamp is an open source web UI for Kubernetes created by the team at Kinvolk, which was recently acquired by Microsoft. It’s a great-looking alternative to the built-in Kubernetes Dashboard.
When getting started with Docker, many developers quickly turn to Docker Compose to run their applications. Compose offers many advantages, such as having your configuration stored as code, making it easy to maintain and expand upon.
Command-line tools like kubectl are a great way to interact with Kubernetes clusters for some of us, but many people prefer a graphical interface. Kubernetes has a built-in dashboard, but some people are looking for features that it doesn’t support.
If you’re developing apps that run in Kubernetes, running them locally with Docker Compose may seem like a simple solution. But it can cause problems, as your local environment will be very different from how your apps run production.
Containerization is on an upward trajectory when it comes to enterprise adoption. This is primarily due to how containers solve the problem of application delivery and portability.
Many engineers developing apps that run in Kubernetes use Docker Compose for their local environment, but a lot of great alternatives are out there that make developing against a Kubernetes cluster fast and easy.
What makes developers happy and productive? If you talk to people who work in the tech industry, they will likely all have opinions on it, but there’s no clear, shared definition of developer productivity.
Using sandbox environments is very common for software developers because it allows them to work, test, and experiment in an environment that is isolated from the production system but still provides a realistic experience.
Kubernetes has left the state when it was mostly an ops technology behind and now is also very relevant for many developers. As I wrote in my blog post about the Kubernetes workflow, the first step for every developer who starts to directly work with Kubernetes is to set up/get access to a Kubernetes development environment.
More developers than ever before are now working with Kubernetes. This means that also their workflows have to change to account for this technology that originally was not made for developers.
Kubernetes has matured so much recently that it even expanded beyond its original space as operations technology. So, also at least 1.7 million developers are already using Kubernetes as “The State of Cloud Native Development” by the CNCF stated for Q2 2019.
Adopting Kubernetes is a process that many companies are currently going through. The introduction of Kubernetes as infrastructure technology can take some time. (It took almost 2 years for Tinder to complete its migration to Kubernetes.
If you are on a higher level of cloud-native development (level 2 or higher according to this article about the typical cloud-native journey of companies), the developers in your team need to have a direct access to Kubernetes.
If you are one of the many companies using Kubernetes as an infrastructure technology, you might now ask yourself how to guide your engineers to use Kubernetes in the development phase of the software.
In recent years, more and more companies have realized that sentences such as “every company is a software company” and “software is eating the world” are more than theoretical statements.