Development Guides

Introduction

The Introduction of the DevOps model into the Development Culture has become an anti-pattern. Instead of providing solutions that optimize an help developers to build better products faster and with less overhead, it has become a problem that has comsumed development time with building increasingly complex Internal Developer Platforms (IDP). Having to deal with building Internal Developer Platforms is a project in itself and removes developers and steal time away from developers working on the product. Kubernetes is complex – it has a host of specialized terms used to identify to core resources that are required to deploy web applications. The ecosystem surrounding Kubernetes, makes matters even more complicated by trying to provide their own YAML formats, supposedly to help clarify and ease the pain of using Kubernetes YAML manifests. If developers are spending their time in this specialized domain and its offerings, each with their own internal domain specific languages, it is no suprise that this effort become and all consuming task. Developers need to focus on product. And any platform development environment should be so constructed, to empower developes to build product and not to build internal developer platforms.

Foo

Kinetic is a Cloud Native Development Environment. It is built with many of the core features that developers need to build Cloud Native software products. It is modular and can be assembled to meet the needs of diverse organizations. The primary goal of building this environment is to remove to toil, cognitive load and confusion of tongues that surrounds the Kubernetes ecosystem.
There are many different ways for developers to start using a CNDE without the heavy lifting normally required for this effort. This guide shows some of the ways Kinetics CNDE eases the on-boarding experience for developers working with a cloud based developer platform.

The LAN Scenario

CNDE can be hooked up to the local area network of an organization. It can also be configured so that Services and Ingresses can be configured and be directly accessed through the LAN. A CNDE contains a product catalog that a developer can deploy with a single command. This will create the resources – database, cache, object storage, search – that the developer needs. The developer can then access these resources directly from their IDEs using a local area network.

Taking the example from the Product Catalog a developer can start building out their web application and integrating it with the database and the object storage immediately. there is no need in the beginning, for a developer to deploy their application into the cloud at least not until it is ready. The benefits of this approach are:

  • Developers integrate with cloud artifacts immediately.
  • Developers can focus on their product and how it integrates with its dependencies.
  • Developers don’t need to run minikube or docker on their local machines.
  • This frees up the resources of their machine and reduces the load and allows them to work in an upfront integrated environment.

Remote Development

There are time when developers are not colocated with the cloud instance they are workng with. In this case the CNDE could be in the building, another state or even another country. In this scenario there are two options that a developer can use. The first one use the in build of the CNDE to be on a VPN. Every CNDE come with tailscale builr in. CNDE can be used to start tailscale make it part of a LAN. Of course this needs a tailscale account. The developer can access the CNDE from anywhere.