Kubernetes for the poor

Kubernetes is great, since the last few years, it has proved that it is the best container orchestration software on the market.

However, there is 2 problems, though:

1. It is difficult to learn (and pronouce, lol)

Successfully managing Kubernetes clusters requires a deep understanding of so many concepts, definitions, and practices involved. With so much to consider, it can be difficult for developers to know how to deploy apps in the most effective way.

To deploy apps on Kubernetes you will need a CI/CD process, so you have to learn a little bit about building container images, pushing it to the container registry, telling the cluster to pull & run a container, monitoring the logs,…

2. It’s not cheap

Google Cloud, AWS, Azure,… they are all providing well managed Kubernetes engine service. And they are not cheap, you will be charged for the control plan, and also for the compute engine usage for each nodes of a cluster separately. (Not counting other network & storage costs)

If you're thinking about running your own managed Kubernetes cluster on your infrastructure, then you will back to deal with the first problem - Kubernetes complexity.

But that’s not it, if you don’t monitor your workloads well, such as control, and analyze your resource usage, you may end up having to pay huge Kubernetes bills at the end of the month.

Another issue is deployment, to deploy on K8S, you need to go through many steps as I mentioned earlier in the (1) section, or you can use CI/CD services like Github Actions or Bitbucket Pipeline to automate the tasks.

That brings you to find the DevOps engineers for doing such a job. And trust me, human resources are much expensive than any infrastructure resources.

Additionally, CI/CD services are not free. At first, you might think a thousand build minutes per month is a large number and that you would never reach it. However, in reality, it often ends up being a much higher number.

(Just do a quick math: if you have four people working on a project, and each of them builds three times a day on average, and each build takes three minutes, by the end of the month you will have spent 1080 minutes on builds: 4 x 3 x 3 x 30 = 1080 minutes, see?)

Note that you will likely have more than one project per month, and not all project builds will take less than three minutes!

And guess what? If you want to build app faster or your app requires more compute resource to build, you need to pay more money for extra resource quotas!

How did I deal with these problems?

1. I learned Kubernetes so you don’t have to

Kubernetes is hard. Pushing developers to learn it even harder (and cruel, their life is already really tough nowadays)

So I learned Kubernetes, and I’ve tried to train my team to use it a few times.

After more than 6 years of working with Kubernetes for my clients, partners, and my own teams, I have realized that the most difficult aspect is training others on how to use Kubernetes and deploy applications onto it.

Developers should not have to be frustrated by deploying their apps to the infrastructure, or having to bother DevOps engineers to help with deployment. They should be able to fully focus on developing their apps without needing to understand complex concepts or definitions of servers, domains, and infrastructure-related topics.

So I started building tools, to help my team deploying apps to Kubernetes cluster.

Why not using Jenkin? Because I don’t like Jenkins. Just that, lol. Actually because Jenkins can solve the deployment, but I want more than that, I want to take more control, automation & monitoring my K8S clusters.

It went well… until I started losing control of monitoring workloads when it started growing. Then I still needed someone with DevOps/Kubernetes knowledge to help out, but…

2. I’m poor and I still want to keep adopting Kubernetes…

I faced the challenge by keep evolving the tool I made recently.

My goals are simply summarized in:

• Simplify those Kubernetes concepts & definitions to something our developers can understand.
• Enhance our developer experience with easy-to-remember commands.
• Centralized monitoring our K8S clusters no matter where it is and what is its cloud provider.
• Build and deploy apps on our own server, so it can take the full compute resource for faster build time.
• Manage our cloud resources other than K8S clusters, such as databases, health check,…
• Automate whatever tasks I want…

It took me months to build this tool, luckily we've been working with a lot of clients, who have multiple Cloud resources across cloud providers, so I got opportunities to fix and improve the tool day by day.

Until now, my companies have been using this tool for years.

I really want to add more features, but as I've become increasingly busy, the release of new features has been slowing down.

Well, I started considering open-sourcing this project because I believe it can significantly improve the efficiency of those working with multiple Kubernetes clusters and other cloud resources, as it has for me. (and also being poor just like me, lol)

And there it is…

Diginext

is the web app server and command line interface (CLI) client to help developers deploy their projects & interact with their cloud resources easily.

Think of it like your own “Vercel” platform which is running on your own infrastructure, and managing your cloud resources.

Wanna try out?

I have a small K8S cluster for free on https://hobby.diginext.site so you can get your hands dirty right away.

Just follow these steps:

1. Before creating a new workspace, you will need a key, get one here (no worries, it’s FREE).
2. Create a new Diginext workspace with your DX key in the previous step at: https://hobby.diginext.site
3. Connect your Github to that workspace: https://hobby.diginext.site/git
4. Connect your Docker Hub to the workspace to store the container image: https://hobby.diginext.site/infrastructure/registry
5. Install Diginext CLI on your computer: npm i @topgroup/diginext --location=global
6. Connect your Diginext CLI with that workspace: dx login https://hobby.diginext.siet
7. Create new app with this CLI command: dx new For example:
   • Project: Something
   • App: Static Site
   • Framework: pick “Static Site Framework”
   • Git provider: select the one you have connected recently.
8. Deploy it: cd ./something && dx deploy
   • Cluster: pick “Default Cluster”
   • Container registry: pick “Your Docker Hub”
   • Use generated domain: YES
   • Port: 80
9. Watch the build process at: https://hobby.diginext.site/build/logs?build_slug=...
10. When it’s finished… Boom! There you go, your website is live at: https://something.dev.diginext.site

💡 Notes:
Since this “hobby” workspace is FREE (and I'm poor), I cannot provide any uptime guarantee or SLA, plus that it will have some limited quotas on number of concurrent builds, amount of apps,…
So please don't use it as a production environment, deployments on this cluster are subjected to be deleted to free up the resources at any time.

🔆 By validating DX API keys, I would be able to limit resources in the workspace, just to make sure my server is having enough rooms for everyone who wanna try out. If you want to get rid of these limits, set up your self-hosted workspaces by following this instruction.

Wanna set up your own workspace?

I wrote some articles to help you getting started below:

I turn my company’s PC into my own “Vercel-like” platform

Conclusion

Any feedbacks are welcome. If you are looking for other features, or wanna give me a hand, below is where you can start:

• Roadmap

• Getting Started

• Contributing

Thank you!

It's a long article, thanks for getting here. If you find any difficulties (or bugs), please let me know, I'm happy to help.