DEV Community: Sudhir Jangir

A multi-node and production like local kubernetes development environment

Sudhir Jangir — Fri, 30 Apr 2021 09:06:28 +0000

For Developers to run and test their containerized applications on a local system, a few options are available like Docker Desktop, Minikube, Kind or K3s, and many more. There is one more to the list — Roost, which is a complete end-to-end development platform with easy integration to various tools like Jenkins, Argo, Falco, Linkerd, or Istio.

In this article, we will compare Docker Desktop with Roost. Both of them use native virtualization technology available by default.

While both of them are one-click installs, Roost comes with a lot of enterprise-level configuration options. Docker desktop is a single node cluster, Roost gives your development team a multi-node Kubernetes environment on their local systems (Mac, Windows, and Ubuntu). Roost users get a rich UI to configure the cluster as per their needs.
Docker Desktop is controlled and managed by individual developers. While working in a team, you need consistency in your development environment. Roost also has a SaaS Control Plane component with unique Left-Shifted Enterprise Policies, allowing you to create teams and define cluster policies/configuration, enabling your team’s consistent and production-like development experience. At the same, Roost allows you to have these development clusters on-prem or the cloud.

Even with multiple nodes, Roost is much more lightweight and easy to configure. Making a configuration or a policy change on the development machine with the Roost control plane can easily be controlled by team admins. Policies can also be changed dynamically and can be different for various teams. A developer may also be part of multiple teams; switching teams is just a click away, and your cluster configuration will change accordingly. With Docker Desktop, you get an isolated environment, which is way different than production.

Roost has a Team Dashboard built-in, which allows you to audit logs for compliance needs. They may be related to Docker file inspection or scanning or any other cluster event.

On Roost, teams can also create a shared Team cluster, and users, if a need is there, would be able to acquire an exclusive lock on the cluster.

Roost: Desktop/cloud-based cloud-native application collaboration & health platform

Sudhir Jangir — Thu, 19 Nov 2020 09:40:56 +0000

Roost is a desktop/cloud-based cloud-native application collaboration & health platform. Developers struggle to learn or migrate to Kubernetes; this will help them get-going the moment they have it installed.

They can just signup on https://roost.io and download the product.

Developer to developer collaboration: Simplify your multi-developer workflow around coding and testing using Roost collaboration.
A multi-node Kubernetes cluster: to make developers' life more comfortable, and bring them close to the production environment.
Development environment: A complete Kubernetes ecosystem/tooling on one-click options.
Service health and analytics: Monitor the health of your services.
Service change management automation: Manage your micro-service changes/versions in a better way.
Team/Enterprise Dashboard: Get your team productivity insights (number of collaborations, number of image scans, dependent service development efficiency)

learn more at https://roost.io

Develop, build, and run in a production like cluster

Sudhir Jangir — Wed, 19 Aug 2020 11:37:47 +0000

Because of environment and tools gap: When a service is moved to a staging or production environment, the service may behave in a different way. We might have to spend multiple dev cycles before we get to a stable version.

These differences can be close to zero if we can have a multi node cluster on the desktop. Or, we would have to run the code in dev or staging cluster with a different namespace.

There are options like Minikube or Docker Desktop; they create a single node cluster on your desktop. But actual need is to have multi node production like environment.

Roost

It creates a multi-node Kubernetes cluster on your desktop based on your system resources. It also provides a single click option to change cluster sizing, memory, CPU cap etc. as per your system or application requirements.

Check my video for details:
https://youtu.be/SGF4NGX0Jmw

Roost Desktop: No more mock services or versioning pain

Sudhir Jangir — Wed, 19 Aug 2020 11:29:22 +0000

How Roost is helping cloud native service development without the need for Mock services, and how to achieve production like accuracy from the first line of the code.
 
Typically an application has multiple discrete services. These services may be dependent on some internal or external services, because of that there will be some challenges, some of those challenges are:

my service keeps on changing with time

over the time, the format in which data is shared might just keep on changing from service to service. I would need to be in sync with those changes. The change might break the services, which are dependent on it.

Creating a different service versions for this change may be a solution; it's very difficult to maintain these versions. Or create one more endpoint for that particular change.
 

Performance/Integration Testing of my change

If make a change in my service, and then if I need to do performance testing of my change, which depends on some other service. To do it without hitting a real service in production, I may have to create a mock service.

Latency

As microservices are developed in isolation, this means I might have to wait for the dependent service to be ready before starting my work.  

So versioning is challenging to maintain and endpoints add lot of work. Mocking creates a fake version of a service, besides that keeping my mock in sync is not an easy task.
 

So how Roost is solving these problems:

Roost provides a peer to peer collaboration feature, where services can be shared in a secure, and a realtime way with other Roosters or Roost instances

With this, we can do realtime integration, end to end testing; will eliminate the need of Mocking, versioning, or separate end-points.

https://youtu.be/RGuky8rVGX0

Kubernetes in Restrictive or regulated environments

Sudhir Jangir — Sat, 06 Jun 2020 11:47:30 +0000

There could be situations where Internet access is regulated or even not there. These "air-gap" or regulated/isolated deployments become more involved with cloud-based environments, where full control is not available. Existing k8s/Cloud providers don't give you access to the cluster or configuration, or may not have an equivalent distribution for your local network or environment.

Now public cloud offering is being centred around containers/Kubernetes/open source, having these in Hybrid or local system has become a need. Localstack or outposts still ties you with the cloud providers, while container movement is also about flexibility. The whole exercise becomes too complicated where the effort to put this in place becomes more than a few weeks of effort.

How do you install/run packages in these Restrictive or regulated environments?

Running Kubernetes cluster in "Air-gap" kind of environments means having local repositories for container images, bundled packages, or approved/regulated binaries. Even for additional tools like image scanning or ci/cd, should be available locally. The application package may include everything needed to run the application – binaries, dependencies, or built-in container registry.

With work from home situations (COVID or even after that), "air-gap" kind of need would arise even for desktop users, where they may have limited connectivity or restricted by office network/installation policies. Users should be able to get a production-like environment with a local registry, control over cluster resizing, version switch capability, or configuration control.

Such packages should not interfere with your existing installations and should be light on your machine.

As a developer working from home, I need to bring my cluster closer to me and should be able to control my cluster behaviour even if I am in Air-gap environment. Developer Focus should be on service development rather than getting worried about how to install or how to run or configure in these situations.

Scala or Go

Sudhir Jangir — Tue, 14 Apr 2020 13:48:06 +0000

Compared to scala: easier to learn, understand code and write; faster to build; smaller image; performance closer to c++, great for microservices; easier with docker/containers/k8s; newer tools/frameworks are on it; go, grpc, protobuf is the way.