If you are confused about what DevOps or Platform Engineering even is, you are not alone. There is a lot of online discussion around this topic, and depending on who you ask, you might get different answers.

Part of the confusion comes from DevOps being often used as a catch-all term. Even Wikipedia is confused about what DevOps really is:

…academics and practitioners have not developed a universal definition for the term "DevOps." ~ Wikipedia

But I'm here to tell you that there is a difference between these two. Let's start by defining them and then see how are they connected…

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

What is DevOps?​

DevOps is not actually a job role, it’s a philosophy. The Dev in DevOps represents software development, such as building applications and features, and the Ops stands for operations, which usually represents pushing, running, and maintaining the software on your servers and infrastructure.

DevOps as a Philosophy​

Consider this: you have a developer team in charge of shipping out applications and features, and you have an operations team in charge of taking that software and running and maintaining it on your infrastructure.

When a bug reaches production, who’s at fault here? Development teams often blame operations for deployment failures, while operations blame developers for writing unstable code.

And these teams have different goals to keep up with. Devs want to ship as much code as fast as possible, while the Ops team prioritizes stability and reliability. This “siloed“ culture causes tension and inefficiency.

This was the reality before DevOps became mainstream (and in some cases, it still is). DevOps as a philosophy promotes a collaborative culture where developers and operations teams work closely together throughout the software development lifecycle. Instead of throwing software "over the wall", both teams share responsibility for building, deploying, and maintaining the software.

DevOps as a Job Role​

I know I said that DevOps is not actually a job role, but in reality, it has become one. While the original term might have meant restructuring organizations to bring the development and operations teams working more closely together, in today's world, it represents a job role akin to Ops.

A DevOps is basically someone who implements things such as automations and CI/CD processes, handles infrastructure, and monitors the metrics of applications. The role can have various responsibilities, but the focus is on enabling teams to build, test, deploy, and monitor their services (this is where the philosophy shines through).

In this role, you will collaborate with development, operations, and infrastructure teams to automate and streamline our processes, build and maintain tools for deployment, monitoring, and operations, and troubleshoot and resolve issues in our development and production environments. ~ a job listing for a DevOps engineer

What is Platform Engineering?​

Platform engineering acts like an internal product team, but instead of serving external customers, its primary users are the company's own developers and internal teams.

The job of platform engineers is designing and building toolsets, infrastructure, and workflows that make it easier for developers to build, test, deploy, and manage software. The goal is to create a unified platform, often called an Internal Developer Platform (IDP), which provides developers with self-service access to everything they need without depending on other teams, like operations or infra.

You will build platform tools and leverage innovative cloud technology to bring joy to your end users - < company's > developers. You are a builder that’s passionate about multiplying our engineering force through automation, cloud technologies, and productivity tools, which enhance the developer experience. ~ a job listing for a Platform engineer

How are they related?​

Platform engineering is not a replacement for DevOps. The goal of DevOps is to improve software quality, speed of iteration, and delivery, which is usually achieved by adopting new tools and workflows. In that regard, Platform engineering is one of the ways to implement and manifest DevOps principles.

The line between the two is usually drawn on the internal developer platform (IDP). While DevOps engineers do build tools for developers (like bash scripts) and try to automate as much as possible, the goal isn’t centered around one specific product.

Platform engineering does have a product at its core - the developer platform, which removes as many obstacles as possible to make developers as autonomous and as fast-moving as possible.

The new kid on the block​

Platform engineering is a relatively new concept, with one of the most famous examples being Backstage. But, building an internal product (the IDP) is a very expensive endeavor for organizations. You won’t see many job listings for platform engineers in smaller companies (a DevOps position is more common here).

At Cyclops, we’re creating a framework for developer platforms that reduces the cost and time needed to build Internal Developer Platforms (IDPs). We want to bring all the benefits of IDPs to companies of any size.

If you enjoyed this article or found it helpful, join our Discord server, where we always let you know about the latest content, new developments, and news from our team!

⭐ Star Cyclops on GitHub ⭐

PS: Oh, and no shade to Wikipedia, I love them 🧡 ~ Juraj

It’s been years since I last played Minecraft, but recently, I found myself itching to jump back in. But working in a startup means you don’t have much time for such activities. Naturally, I needed a perfectly valid work excuse to make it happen. While researching developer platforms, I stumbled across some Helm charts designed to deploy Minecraft servers. Jackpot!

But I was actually amazed at how well-crafted they were. With a bit of work, I knew I could use them to showcase the perfect example of what makes a developer platform truly shine.

In this post, I will walk you through how to run a Minecraft server on your Kubernetes cluster, connect to the server, and, in a fun way, explain the qualities of good developer platforms!

Also, writing this blog post was a great excuse to play a bit of Minecraft at work, so there’s that… 🤷‍♂️

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

Minecraft on Kubernetes​

To be able to follow this tutorial, you will need two things: a Kubernetes cluster and a Minecraft account. (Never thought these two would be requirements for a blog 😅). You can follow along without the Minecraft account, but then you’ll just be spinning up the server and won’t be able to actually play the game.

I used Minikube for my Kubernetes cluster, and it worked fine, you can check here how to set it up for yourself.

Minecraft Helm charts​

Most of the hard work for this wasn’t done by me, that glory belongs to Geoff Bourne. I’ve come across his minecraft-server-charts repository and just had to try it out.

While you can use the Helm charts Geoff created, which would work fine, I wanted to emphasize my point, so I tweaked the values.schema.json just a little bit - you can find my version here.

Cyclops​

The next step is to set up Cyclops. Cyclops allows you to import these Helm charts to instantly get a Developer Platform!

Cyclops runs in your cluster; you can set it up with two commands:

kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.15.4/install/cyclops-install.yaml && 
kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.15.4/install/demo-templates.yaml

After a couple of moments (once it’s up and running), use the following command to access it on localhost:3000 :

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

Now that you have your Cyclops instance set up, import the Helm chart as a template in the Templates tab.

Why is it a good Developer Platform?​

After you import your template, go to the Modules tab and create a new module. The first step in creating a module is choosing a template. Pick the Minecraft template that you imported in the previous step.

Cyclops will provide you with a simple UI and a bunch of options for deploying your Minecraft server. These options were all defined in the Helm chart from before!

Now I haven’t played Minecraft in a long time, but everything is abstracted and neatly described. I can choose the settings of my server without having to research what these options represent and deploy my Minecraft server in a jiffy!

While I wouldn’t know how to set these things up by myself through the developer platform, it’s a piece of cake. You can imagine that instead of setting up Nether regions and generating structures, these could be feature flags for an application that can be toggled on or off.

Or instead of choosing the difficulty, you could choose the resource requirements of your apps, which can be along the lines of “small”, “medium” or “large”, without having to know how much CPU or Memory that actually is and without being able to misconfigure it.

But more things are happening behind the scenes than that are actually shown here.

Some things are not supposed to be edited by me but by someone who is more adept at Kubernetes. In that case, these options are left out of the UI. For example, you won’t find a replicaCount setting in the UI, but if you dig in the values.yaml, you can find this section:

# ### WARNING ###
# Minecraft is not horizontally scalable, adjusting this
# will most likely break your setup.
# ### WARNING ###
replicaCount: 1

This is what I mean when I say that this is an example of a good developer platform. I’m allowed to specify the things that are important to me (like the difficulty and settings of my server), but someone who understands the infrastructure is still in control. That person creates a UI, creates validations and defines what is acceptable for me to mess around with.

Once you got the settings right (and accepted the Minecraft EULA by toggling it on), just click Deploy and Cyclops should take care of the rest.

Not only was I able to configure these options and deploy them, but I also have a nice visual representation of the result running in my cluster. Never once was there a mention of a “Deployment” or a “Service” (or “Secrets” for that matter), but these resources were created for me by using the template.

But that’s enough tech talk; let’s play some Minecraft!

Final Step - Play!​

Now all you need to do is wait for it to be deployed (you know it is ready when the Deployment turns green) and then expose the service:

kubectl port-forward svc/<modul-name>-minecraft 3001:25565

Now start up your Minecraft and login into your account. Click Multiplayer and Add Server. Name the server what you want and put the Server Address to localhost:3001.

That’s it, you should be good to go!

Tell your boss you are researching Dev Platforms​

Cyclops, as an open-source framework for building dev platforms, is highly flexible; Minecraft is only a fun example of what I wanted to showcase today. Cyclops comes with a bunch of predefined templates, but you can import your own Helm charts to get a dynamically rendered UI. Try it out and let us know what you think!

If you have any whacky examples of cool Helm charts like these, link them in the comments or share them with us and our community in our Discord server 👾

Here is your excuse to play Minecraft at work, now enjoy!

⭐ Star Cyclops on GitHub ⭐

In the DevOps landscape, two paradigms have emerged: GitOps and ClickOps, each offering unique approaches to managing Kubernetes-based infrastructure. However, if you ask an experienced DevOps engineer, they might scoff at the idea of ClickOps as an alternative. While their reasoning may be valid, is ClickOps truly as unworthy as they might make it out to be?

In recent years, we have seen the rise of (Internal) Developer Platforms. An IDP can be anything from a couple of scripts to a complete GUI-based platform, but they all share the same goal of enabling self-service for developers when deploying applications and infrastructure. While some IDPs incorporate GitOps principles, this isn't always the case.

This post will explore these two popular methods for managing applications and infrastructure, their strengths, where they fall short, and how to get the best of both worlds.

Click by Click, Commit by Commit…

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub ⭐

What is GitOps?​

GitOps is a method in which the desired state of your application and infrastructure is stored in Git, and an automation tool ensures that those changes are applied to your Kubernetes cluster.

There are usually two approaches to GitOps: the push and the pull approach. The push approach relies on an external system that pushes the infrastructure code to the cluster, typically triggered by a pipeline or event. On the other hand, the pull approach involves a tool running within your cluster continuously pulling the infrastructure code from a Git repository and applying it to the cluster.

While GitOps is considered best practice amongst the DevOps community because of its automatization and version control, it depends on practitioners having a strong understanding of how to write infrastructure as code (be it YAML, Terraform, or others).

What is ClickOps?​

ClickOps usually relies on a user-friendly UI through which individuals can click through forms, fields, and checkboxes and provision and deploy their infrastructure and software. With its visual, interactive experience, ClickOps makes managing complex systems easier and more approachable, no matter your skill level.

Professional DevOps might be turned off by the lack of a single source of truth that describes your whole infrastructure (like code stored in Git), but ClickOps shines when it comes to quick adjustments and enabling self-service for less infra-oriented people (like most developers). It is a core component in any Internal Developer Platform (read more about IDPs here).

Getting the Best of Both Worlds​

Both approaches offer various benefits but also have their shortfalls. GitOps offers version control but is more complicated for developers since it relies on infrastructure as code (IaC), which can quickly become complex. It is great for stable environments where changes should be documented.

ClickOps enables quick changes and an interface that makes it easier to interact with Kubernetes but requires manual input (the clicks) and does not have a single source of truth you can point to. It is perfect for short-lived environments that serve as a playground for testing.

At Cyclops, we are committed to creating a framework for building internal developer platforms. Understanding the challenges of both GitOps and ClickOps, we wanted our tool to handle both sides of the DevOps coin. 🪙

GitOps & ClickOps with Cyclops​

All applications in Cyclops are defined as custom Kubernetes resources called Modules. Each time a Module is created, the Cyclops controller picks it up, creates other Kubernetes resources from it, and applies them to the cluster. Because Modules are CRDs, you can define them via a YAML manifest. And since a Module can be defined through a manifest, it can be stored on a Git repo and included in your GitOps workflow!

Let’s take a look at an example of Module manifest:

apiVersion: cyclops-ui.com/v1alpha1
kind: Module
metadata:
  name: module-in-action
  namespace: cyclops
spec:
  targetNamespace: default
  template:
    path: demo
    repo: https://github.com/cyclops-ui/templates
    sourceType: git
    version: main
  values:
    image: nginx
    name: demo-app
    replicas: 1
    service: true
    version: 1.14.2

Modules, even in their YAML format, offer a much simpler interface for developers to interact with. The values section is the only important thing for developers if they are using the GitOps approach, and is defined and customized by their DevOps.

From the code above, template is actually a reference to a Helm chart. The Helm chart is hidden from developers and offers DevOps engineers all the flexibility Helm usually does. Applying the above manifest, Cyclops knows it needs to create a deployment of nginx with 1 pod and a Kubernetes service.

Cyclops offers a dashboard for developers to visualize what their application is made of. Here, they can perform basic actions. To name a few: restarting their application, editing the configuration and viewing the logs of their app.

Because you can edit the configuration through the Cyclops UI, it allows for much quicker changes. However, this clashes with the GitOps philosophy. That is why we introduced immutable fields. When a field is classified as immutable (in the Helm chart), it can only be configured through the GitOps workflow.

The image above shows the edit screen of a module. Fields for image and version cannot be updated through the UI and should be updated through the GitOps workflow. But, not all configuration values are created equal. In the above module, environment variables are not specified as immutable and can be changed through the UI (a ClickOps approach).

See it in Action!​

If you want to see how a ClickOps and a GitOps workflow can supplement each other, check out this tutorial we made to get you started.

This is something we recently released and is just one of the possible ways to pair GitOps and ClickOps. We would love to hear what you think about this setup, so feel free to share it in the comments or in our Discord. Any new idea is more then welcome!

This was part of our first-ever Launch Week. If you are interested in what else we uncovered, check out a short recap here 👀 #cyclopslaunchweek

⭐ Star Cyclops on GitHub ⭐

Cyclops is having its very first launch week, starting on November 25th!

For an entire week, we will be unveiling a feature a day - that's five features in total!

We don't want to spoil the surprise just yet, but if you're as impatient as we are, we invite you to join our Discord session that is happening on Monday, November 25th, at 6 pm CET! We will preview all of the features we plan to reveal throughout the week and host an Ask-Me-Anything session afterward.

To reserve your spot, visit the event in our Discord server and mark yourself as interested.

Come back here each day to see what we launch, or follow us on X and LinkedIn to keep up to date and follow the hashtag #cyclopslaunchweek

#1 Helm Releases ⚡​

With the release of this feature, Cyclops will pick up on any installed Helm releases in your cluster and showcase them in our new tab - Helm Releases.

Besides reviewing all of your installed Helm releases in a cluster, through this tab you can inspect them as well. You can view all the resources your Helm release is made up of, edit the releases through the UI, and delete them.

Although Cyclops Modules are a more powerful way of managing your applications in the cluster, the Helm releases manager offers a good starting point since it does not require you to change your current CI/CD pipelines or workflows. We also found them great for environments with short lifecycles - such as testing or staging clusters!

#2 GitOps 🦑​

We know this was a highly requested feature, and we are happy to announce that Cyclops now supports a GitOps workflow!

All applications within Cyclops are defined as CRs called Modules. Each time a Module is created, the Cyclops controller picks it up, creates other Kubernetes resources from it, and applies them to the cluster. Since Modules are CRDs, you can define them via the YAML manifest. Those manifests allow you to define everything you need for your application in a single place.

Since a Module can be defined through a manifest, it can be stored on a git repo and included in your GitOps workflow!

Through the Module manifest, you can also define which values you want to make editable through Cyclops and which values should be handled only with GitOps. For example, the image version should only be handled with GitOps, but you want to enable developers to scale the number of replicas through Cyclops.

We created a guide you can follow to get started, check it out here!

#3 Namespace Scoped Cyclops 🔬​

We know this was a thorn in your side, but from now on, you can restrict Cyclops to a single namespace to limit the permissions needed for your Cyclops installation!

Firstly, we introduced three new environment variables WATCH_NAMESPACE, MODULE_TARGET_NAMESPACE and WATCH_NAMESPACE_HELM, which will help you configure your Cyclops instance to act only in specific namespaces.

...
- name: cyclops-ctrl
  image: cyclopsui/cyclops-ctrl:v0.15.2
  ports:
    - containerPort: 8080
  env:
    - name: PORT
      value: "8080"
    - name: WATCH_NAMESPACE
      value: "my-namespace"
    - name: MODULE_TARGET_NAMESPACE
      value: "my-namespace"
    - name: WATCH_NAMESPACE_HELM
      value: "my-namespace"
...

Secondly, we created a Helm chart that utilizes these env variables to create Roles and RoleBindings for Cyclops to be scoped to a single namespace of your choosing. And, of course, we made a guide on how to use these env variables and how to easily get set up - check it out here!

#4 Private Repositories 🔐​

Most companies do not store their configurations & Helm charts in open repositories, so this feature was a MUST-have! However, accessing private repositories requires authentication.

We did not want to bloat Cyclops with a database, so we introduced a new custom resource called TemplateAuthRule! This resource defines which templates you want to authorize and points Cyclops to the authorization data that is stored securely in Kubernetes secrets.

Of course, we created a tutorial on how to enable Cyclops access to your private repos here.

#5 Streaming 🌊​

If you've used Cyclops recently, you may have noticed a more responsive and smoother experience. This improvement comes from our latest enhancements: streaming resource status updates and real-time app logs.

You can now rest comfortably knowing that the resources are getting their status (health) updated live from the cluster!

REACT_APP_ENABLE_STREAMING: true

Of course, if your bandwidth is not allowing you to keep an SSE connection open (or you just don’t care about having the state streamed to the UI), we introduced a new environment variable in cyclops-ui that allows you to disable this feature ⬆️

If you've used Cyclops recently, you may have noticed a more responsive and smoother experience. This improvement comes from our latest enhancements: streaming resource status updates and real-time app logs.

Launch Week Wrap Up 🎁​

This wraps up Cyclops Launch Week! We’re thrilled to have shared these five amazing features with you, each designed to make your Kubernetes experience more efficient, secure, and user-friendly.

Thank you for being a part of our journey! If you are interested in keeping up to date, be sure to join our Discord community where we always share the latest news! 👾

Looking forward to our next launch week 🚀

Whether you are a veteran or just started coding, chances are you stumbled upon Kubernetes. It's arguably the most popular platform for deploying applications as containers.

But should we use Kubernetes as just a container orchestrator, or is there more to it?

Kubernetes allows you to extend its mechanisms with your own custom resources and functionality. Its extensible API allows you to define resources outside of applications, such as cloud resources (an instance of MySQL in GCP or an S3 bucket in AWS).

This allows you to manage all of your system components through Kubernetes, from cloud resources to running applications. With Kubernetes, you can easily build your very own Internal Developer Platform that is tailored specifically for you and allows developers to manage and provision everything they need to ship products.

Through the blog, we will build exactly that - a friendly platform that will allow us to simply deploy our apps to K8s, as well as provision AWS resources. We will use the AWS S3 bucket operator to create buckets and Cyclops to get a super simple Kubernetes UI.

Any software engineer can now select a couple of fields, and behind the scenes, it unravels into a complex cloud setup tailored for your organization that can be easily managed.

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

What is a Kubernetes Operator​

Kubernetes operators allow you to extend K8s functionality with custom resources and logic. Operators naturally follow Kubernetes’ philosophy of a control loop - bringing the state of your resources towards what was defined.

You can divide a Kubernetes operator into two parts:

• custom resources - defined through Custom Resource Definitions (CRDs) that allow you to extend the Kubernetes API with new types and kinds. Using custom resources, we can define the desired state of our system.
• controller - will implement the mentioned control loop to make sure the defined state from the CRD is, in fact, brought to reality. Controllers listen to changes in custom resources and react to them to make sure the system achieves the desired state.

For example, Kubernetes Deployments are resources that define how to deploy our application, and the controller manager implements the control loop to create Replica Sets and Pods to ensure our app is running.

Without changing the Kubernetes codebase, you can leverage the mechanisms from your clusters, like the API and the database. We made a blog post on CRDs and whether Kubernetes is just a glorified database. It explains how you can make the command below a valid kubectl command - check it out here!

kubectl get apples

NAME          AGE
green-apple   6s

You are more than welcome to implement a Kubernetes operator yourself, but there are plenty of operators/controllers already out there you can just install into your cluster. There is a long list of well-known operators for different use cases you can check on https://operatorhub.io/

AWS controllers for Kubernetes​

There is a family of controllers that allow you to manage your AWS cloud resources like S3 buckets, databases, and applications. AWS Controllers for Kubernetes is a project that implements a collection of controllers that each manage one AWS service.

For example, one controller defines a Kubernetes custom resource for an AWS S3 bucket and makes sure all the S3 buckets are created. The same goes for other AWS services, which each have their own dedicated controller.

If we take the mentioned S3 bucket controller, we can define an S3 bucket in our Kubernetes cluster with the following YAML:

apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: my-new-bucket
spec:
  name: my-new-bucket
  tagging:
    tagSet:
    - key: env
      value: prod

In the spec, we can add all of the config we need for our S3 buckets, like permissions, object lifecycle, and website hosting… but this time through Kubernetes resources.

Once you apply the manifest from above into a Kubernetes cluster with a configured S3 controller, the controller will create an S3 bucket in your AWS account with all the configuration defined in the YAML.

Controllers with Cyclops​

Provisioning cloud resources through Kubernetes objects is (in my opinion) an awesome concept. Now, your Kubernetes cluster is not only running containers but is also controlling all of your system’s components, like networking policies and databases.

Defining stuff in Kubernetes has benefits but also some downsides. Which cloud resources should you use, and how should you configure them? Which fields do you need to populate, and what values are valid? And once everything is configured… how do you keep it running smoothly?

These are all valid questions, and this is what we will use Cyclops for 🔥

Cyclops allows you to hide all of the complexities of Kubernetes under a simple UI that anyone can customize to their specific needs. In the next chapter, we will combine an AWS controller for S3 buckets with Cyclops to get a simple UI that abstracts (somewhat) complex S3 bucket configuration.

Install​

Through the following section, you will install the S3 controller along with its Bucket Custom Resource Definition. You won't be deploying your buckets through kubectl like some savage; we will also install Cyclops, which comes with predefined templates for your Buckets.

And we will do all that with a single command 🔥

There are some prerequisites before we get to deploying:

• AWS account to deploy S3 buckets to
• AWS account credentials your S3 controller can use
  • You will need an Access key and a Secret access key that has permissions on the S3 bucket. You can use the full access S3 policy
• running Kubernetes cluster
  • Even though you will be creating AWS resources, your cluster does not need to run in AWS. If you don't have a cluster, you can spin up one with minikube
• kubectl and helm cli tools

If you have everything from the list above, install Cyclops and S3 bucket controller with a single command. Make sure you populate the region you want to deploy to and your access key and secret access key mentioned in the prerequisites.

helm install cyclops-aws oci://registry-1.docker.io/cyclopsui/cyclops-aws-s3 \
--version 0.3.0 \
--namespace cyclops \
--create-namespace \
--set s3-chart.aws.region=<aws region> \
--set aws.accessKeyId=<your access key> \
--set aws.secretAccessKey=<your secret access key>

You can check if all the pods we installed are up and running with

kubectl get pods -n cyclops

And you should get an output similar to this one:

NAME                                    READY   STATUS    RESTARTS   AGE
cyclops-aws-s3-chart-684cdd9b8c-cpfrz   1/1     Running   0          40s
cyclops-ctrl-5ddd9b8bc9-7b5pq           1/1     Running   0          40s
cyclops-ui-7d55d588cd-kdrgt             1/1     Running   0          40s

Once the pods are up, you can port forward your Cyclops instance to access with the following command:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

And you can now access Cyclops on http://localhost:3000/

Deploying an S3 bucket with Cyclops​

To create a brand new S3 bucket, go to Add module in your Cyclops dashboard, and select the s3-bucket template.

Cyclops templates are nothing more than Helm charts anybody can create and import into Cyclops through the templates tab. You can find this template here and use it to create your own UI 😄

Here, you can configure your bucket:

• Bucket name override - by default, your AWS bucket will be called after the module, but this field allows you to name it differently from your module
• Bucket use case - select the use case for your bucket
  • testing - all bucket objects will expire after 3 days which makes it great for testing and automatically removing objects after you are done with testing
  • production - will only expire older versions of your objects after 30 days. Last 3 newer versions of objects will be retained.
  • website - enable static website hosting

Once you deploy the Module, you will see your shiny new S3 bucket custom resource in the Cyclops console. Also, you can check you AWS account to see a new bucket.

Since the bucket above was created with the testing type, the bucket you created has a lifecycle rule for expiring objects like the one below.

You can now go back to your Cyclops console and edit the module you used to create your S3 bucket. Change the Bucket use case to production and check your buckets lifecycle rules. You can see that the rule is now called expire-prod and if you check its configuration, you will find it defines a completely different lifecycle which you never had to care about and somebody did for you.

Combining applications with Cloud resources​

Since our cloud resources are defined the same way we would define an application running in Kubernetes, we can deploy them as a single unit!

Sure, some cloud resources (like VPCs or subnets) should not be deployed as part of an application, but if we are talking about storage or load balancers, it might be an awesome productivity boost for developers to ship their apps without thinking a lot about provisioning and infrastructure.

Let’s pretend we have an application that depends on an S3 bucket and you want to deploy and manage them together. The same way you created an S3 bucket earlier, you can now choose the app-with-s3-bucket template and configure your application and your S3 bucket in the same place.

This template is also available here.

You can now play around with your app and your bucket config as much as you want, but the important thing is that you can manage it from a single place. Changes in your resources, whether they are cloud services or Kubernetes deployments, are now atomic, and you can ship your apps and their dependencies together 🔥

Custom cloud platform​

Through the example above, you can see how flexible Kubernetes is. With Kubernetes and its countless operators, you can control any resource your system needs, whether it is a container or a cloud resource.

Using Cyclops with such a setup allows any engineer to have full power over their system at their fingertips with the right abstraction.

They can now ship whatever component they need in a couple of clicks while being sure what they are doing is not going to break anything - what Platform engineering is all about.

If you enjoyed this article, or got some ideas on how to implement something similar for yourself, remember to show us your support by starring our repo 🌟 🧡

Gartner predicts that by 2026, 80% of software companies will have established platform engineering teams (source). As companies grow, so do the challenges of keeping things running smoothly, and developers want tools that make their work easier and more intuitive.

The main responsibility of platform engineering teams is to create and maintain internal developer platforms (or IDPs for short). In our last post, we gave a more in-depth look into platform engineering and IDPs, exploring how this new trend emerged and its benefits.

But when considering IDPs, you have two options: building one yourself or getting an off-the-shelf solution. Building one yourself is often too time-consuming and expensive for most companies, and that's why off-the-shelf platforms are an attractive alternative. There are a lot of such solutions available, and we will not cover all of them in this post, but let's look into five internal developer platforms you need to know about…

Cyclops​

Developer-Friendly Kubernetes

Cyclops is an open-source tool that simplifies Kubernetes for development teams by hiding its complexity behind a customizable user interface.

Cyclops allows DevOps teams to quickly create custom UIs for their development teams and empowers them to create validations on developer actions to establish guardrails that reduce the risk of misconfigurations reaching production.

After a developer deploys their app, Cyclops provides an intuitive overview of the application running in your cluster. This allows developers to quickly spot and fix errors and easily access their app logs without ever having to onboard on Kubernetes.

Cyclops is cloud agnostic; as long as you are running a Kubernetes cluster, you can set it up with a single command from your terminal. It has a couple of predefined templates to showcase its customizability and enable you to quickly deploy your apps to K8s.

What makes it special: Cyclops' customizable UI allows DevOps teams to easily create user-friendly interfaces that match their organization's needs, giving developers the right level of abstraction over their underlying infrastructure. Because Cyclops dynamically creates UIs based on Helm charts, you can plug your existing Helm charts into it and have a fully functioning UI for your developers in minutes!

Humanitec​

Build a Platform That Drives Change

Humanitec is a modular platform designed to help organizations build scalable, enterprise-grade internal developer platforms.

The product philosophy at Humanitec emphasizes flexibility and a code-first approach. Their tools are modular, ensuring there is no vendor lock-in while being enterprise-grade. This approach means there's no "black box" feeling.

Humanitec's product suite includes The Portal, which provides developers with an easy-to-use UI for configuring applications, checking container logs, and debugging errors. Additionally, Score allows developers to define their workload requirements in code, promoting consistency across teams.

The Platform Orchestrator is at the core of Humanitec's offerings. It is an engine that enables platform teams to define templates and establish golden paths for their developers. Resource Definitions serve as open-source building blocks that tell the Platform Orchestrator how to create/update infrastructure in a particular environment. ****

What makes it special: Humanitec's platform is highly modular, allowing organizations to build IDPs using its products as a whole or as building blocks in a larger platform. It easily integrates with existing infrastructure-as-code (IaC) setups, making Humanitec great for large teams looking to scale their operations efficiently.

Qovery​

DevOps on Autopilot

Qovery is a DevOps automation platform designed to eliminate the need for dedicated DevOps hires by providing a comprehensive self-service infrastructure for developers.

It streamlines the entire process of infrastructure provisioning, transforming what is usually a time-consuming and manual task into an automated workflow. It can provision infrastructure assets into ready-to-run environments, whether for development, QA, or anything else.

In addition to simplifying infrastructure management, Qovery is designed to help organizations optimize their cloud spending. The platform offers various strategies for cost reduction (like automatically shutting down unused environments) and detailed insight into resource usage.

Qovery is built to integrate with your existing toolset and cloud accounts. It supports integration with a wide range of monitoring, CI/CD pipelines, and security solutions, allowing teams to continue using their preferred tools while leveraging Qovery's automation and management capabilities.

What makes it special: With Qovery, teams can provision and maintain secure cloud infrastructure in hours, not months. It offers features such as environment provisioning, developer self-service tools and cost optimization.

Mia Platform​

The Leading Platform Builder for Cloud Native at Scale

Mia Platform is a comprehensive platform that aims to cover the full lifecycle of your applications on Kubernetes with smooth developer experiences.

Mia-Platform simplifies the development process with built-in CI/CD pipelines, eliminating the usual complexity of setup and automating processes to accelerate software delivery.

With a rich catalog of prebuilt microservices and built-in orchestrators for managing them, it speeds up development by allowing you to use the industry standard services out of the box and focus on developing your own product-specific ones.

Mia-Platform also provides clear API management, helping you with design, security, versioning, and retirement. With an API portal, you can simplify the process of establishing new partnerships by making APIs easily accessible.

With a built-in Developer Portal, your development teams have the entire lifecycle of their Kubernetes applications centralized in one place. The portal provides them with easy access to their app's health, resource usage, relevant documentation, etc.

What makes it special: Mia-Platform stands out by offering an all-in-one platform for managing the entire lifecycle of cloud-native applications. It simplifies development with a self-service Internal Developer Platform, built-in CI/CD pipelines, and a catalog of ready-to-use microservices.

Porter​

Platform as a Service, Reimagined

Porter is a platform that deploys applications into your own cloud account with just a few clicks. It automates infrastructure provisioning on AWS, GCP, or Azure and makes it easy to deploy, manage, and scale applications on Kubernetes.

Porter simplifies infrastructure provisioning by connecting directly to your cloud account. With minimal effort, it spins up a Kubernetes cluster along with essential infrastructure like VPCs, load balancers, and image registries.

Deployment is equally straightforward - by linking your Git repository, Porter handles building your application using Dockerfiles or Cloud Native Buildpacks and setting up CI/CD via GitHub Actions, which can be customized later to fit your workflow.

Porter continuously monitors your Kubernetes cluster to ensure smooth performance and scalability, keeping track of both your application metrics and logs. If any critical issues arise, Porter will send alerts to notify your team.

What makes it special: Porter focuses on enabling startups and small teams to leverage production-ready Kubernetes infrastructure right out of the box, without needing deep DevOps knowledge.

Before You Go​

Thanks for reading! I hope this overview helped you orient yourself in the developer platform landscape. While these are not the only players on the market, they are a great starting point for you to explore. If you enjoyed this article and are looking forward to more blogs on developer platforms, open-source and Kubernetes-related topics, remember to show your support by starring our repo ⭐🙏

Modern software engineering is becoming more and more complicated, especially in cloud-native environments like Kubernetes. There are countless moving parts and pieces and no two applications are built the same.

The larger the company, the more moving parts there are. With more moving parts, development cycles become stretched, onboarding developers takes longer, and the chances of mistakes increase. Because of this, companies stagnate and become slower to innovate and push new products and features.

The modern answer to this problem is Platform Engineering and, according to Gartner, 80% of software engineering organizations will establish platform teams by 2026.

In this blog we will discuss what platform engineering is and what can you do to stay ahead of the curve…

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

What is platform engineering?​

Platform engineering acts like an internal product team, but instead of serving external customers, its primary users are the company's own developers and internal teams.

The job of platform engineers is designing and building toolsets, infrastructure, and workflows that make it easier for developers to build, test, deploy, and manage software. The goal is to create a unified platform, often called an Internal Developer Platform (IDP), which provides developers with self-service access to everything they need without depending on other teams, like operations or DevOps.

Why platform engineering?​

“The goal of Platform Engineering is to allow as much speed as possible, with as much safety as possible” ~ Jason Warner, CEO @ poolside, former CTO @ GitHub (source)

Platform engineering creates an abstraction layer that simplifies infrastructure management for developers. Instead of dealing with the complexities of infrastructure, developers can focus on writing code, leading to quicker onboarding and faster time to market.

A good IDP enables separation of concerns. Most of the time your DevOps teams and Product teams do not need to talk to each other and they can move independently. It also provides guard-rails and ensure standard and secure practices across the organization.

Fun fact: when Spotify built its own Internal Developer Platform (now known as Backstage) they realized that their developers were 5% more likely to stay at the company one year later. Developer experience matters!

Internal Developer Platforms (IDPs)​

When it comes to Internal Developer Platforms (IDPs), you typically have two options: build one yourself or buy an off-the-shelf solution.

Building your own may seem like the ideal choice. You can tailor it perfectly to your specific needs, ensuring it integrates with your existing tech stack, workflows, and infrastructure. However, building an IDP from scratch is both time-consuming and expensive, it’s essentially a full product in itself. For this reason, custom-built platforms are typically reserved for larger organizations with the resources to invest in such an undertaking.

On the other hand, off-the-shelf platforms offer a quicker, more affordable alternative. These platforms are designed to cater to a wide range of users and needs, which can be both a blessing and a drawback. You may end up with features you don’t need or find key functionality missing. In the latter case, you’re dependent on the vendor’s roadmap, which may not prioritize your needs. While they provide immediate value and are a solid starting point, you have to keep in mind that your organization will eventually outgrow them as your requirements evolve.

But, at Cyclops, we are building something in between…

Cyclops​

Cyclops is an open-source tool that bridges the gap between fully custom-built Internal Developer Platforms (IDPs) and off-the-shelf solutions. It enables you to build IDPs for Kubernetes in hours instead of months, providing the flexibility to tailor the platform to your specific needs without the high cost and time investment of building from scratch.

Cyclops enables your Platform teams to build custom user interfaces for configuring and deploying applications and services to Kubernetes clusters. It leverages Helm charts (learn more here) to generate these UIs. You can easily import any of your existing Helm charts into Cyclops as templates and create a user-friendly interface tailored to your specific needs.

The fields shown above are entirely customizable along with the validations. Cyclops allows you to define how much of configuration you want to expose to your developers, while the validations you put in place prevent them from making mistakes.

After a developer has configured the application, with a click of a button it is deployed to the cluster. Cyclops then displays all resources related to the application, offering easy access to relevant information, including logs, health checks, and status updates.

In a nutshell, Cyclops lets you provide the guard rails for your developers to safely deploy their application to Kubernetes and then overview the status of their apps.

Looking for more?​

Thanks for reading! In future blogs you can expect us going more in depth on Cyclops and how you can create some pretty fun stuff with it. If you enjoyed this article and are looking forward to more, remember to show your support by starring our repo ⭐🙏

Whether you are new to Kubernetes or maybe you're part of a startup that's always short on time, this guide is for you. Kubernetes is an incredibly powerful tool for managing containerized applications, but it's also notorious for its complexity and steep learning curve.

And if you're running a startup, you probably don't have the luxury of spending days (or weeks) wrestling with configuration files and cloud infrastructure. Setting up a Kubernetes cluster can feel like a daunting task, but it doesn't have to be.

This article will show you how to quickly spin up a Kubernetes cluster in the cloud and deploy your applications in just minutes. And we're making it a speedrun! In less than 10 minutes, you'll have everything up and running, including your own software.

Start your timers! ⏳

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

What is Civo?

Civo is a cloud service provider that allows you to quickly spin up Kubernetes clusters - it takes about 90 seconds to get it up and running! If you have ever tried spinning up a cluster on other cloud service providers (AWS, I'm looking at you 👈), it will be a refreshing experience to see how easy and fast it is with Civo.

Although Kubernetes is not Civo's only service, this article will mainly focus on it as it is the fastest setup I've encountered (apart from local setups).

How to spin up a Kubernetes cluster with Civo?​

The first step is to create an account on Civo (obviously 🫴). If it's your first time trying out Civo, they will provide you with $250 worth of credits! You can follow along for free and work with a real Kubernetes cluster running in the cloud. Even if you do not have the credits anymore, Civo will tell you the monthly cost of running your cluster, so you do not have to dread receiving the bill at the end of the month 😅

Once you have created your account, you should be greeted with the Civo dashboard. To set up your cluster, click the "Launch a new cluster" button or go to the Kubernetes tab, where you will find a similar button.

You will be taken to a screen that lets you customize the specifics of your cluster. Here, you can choose how many nodes you want, what sort of nodes (Standard, Performance, CPU Optimized, or RAM Optimized), firewall configuration, cluster type…

In the spirit of a speedrun, I'll leave it all on the default values (except the name, which I wanted to fit the theme 😁).

But before launching your cluster, let's stop at the Civo Marketplace (on the same screen). The Marketplace has lots of tools that can help you in various ways, and they will be deployed to the cluster upon its creation so you can use them instantly.

Under the Management tab, you can find Cyclops UI. Cyclops will allow you to deploy your apps to the cluster without any extra configuration. It only requires you to have a docker image of your apps. And Cyclops is open-source, so it won't impact your Civo bill!

You can select to install Cyclops just by clicking on it, and it should have the blue checkmark as it does on the image below.

Now that we have configured our cluster and included Cyclops, let's launch it! Click the "Create cluster" button on the bottom of the screen, and let's go!

How to access your Kubernetes cluster?​

After less than 2 minutes ⏳ (you can see the countdown when the cluster is being created), you will have your cluster up and running. You will talk to the Kubernetes API in that cluster to access it. For this, we will be using the terminal, but only a couple of commands will be needed before we can start deploying our applications.

The first thing is to install kubectl (you can find how to install it here). kubectl is the Kubernetes command-line tool used to interact with your cluster.

Once you installed kubectl, download the Kubeconfig file of your cluster. You can find it in the Cluster Information section.

Once downloaded, which takes about a second or two ⏳, go to your terminal and type in the following command:

export KUBECONFIG=<insert-path-to-the-downloaded-kubeconfig-file>

To check if we set the Kubeconfig correctly, run any kubectl command and see if it's interacting with the right cluster. For example:

kubectl get pods

NAME                                 READY   STATUS      RESTARTS   AGE
install-traefik2-nodeport-ku-4b5zn   0/1     Completed   0          1m
install-cyclops-kubernetes-s-md5mz   0/1     Completed   0          1m

Our Kubernetes cluster is up and running, but now we want to use it and deploy our applications to it, and for that, we will be using Cyclops.

What is Cyclops?

Cyclops is an open-source tool that allows you to deploy your applications through a UI, hiding all of the complexity of Kubernetes.

The UI is highly customizable and is generated from Helm charts (read more about it here). You can use any of your existing Helm charts, import them into Cyclops as templates, and get a UI made for your specific use.

For now, we will be using the default templates that all Cyclops instances get out of the box (it is a speedrun, after all ⏳)

Deploying Applications to Kubernetes​

We selected Cyclops in the Marketplace when creating the cluster, so it should already be installed. To access it, run the following command from the same terminal as before:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

⚠️ It is important to run this command from the same terminal as before because, with the first command, we set the context of the terminal to be able to access our Kubernetes cluster in the Civo cloud.⚠️

If you have configured the Kubenconfig correctly, the port-forward command will allow us to access Cyclops's UI from our browser.

To access it, go to https://localhost:3000, and you will be greeted with an empty dashboard. To deploy your application to the cluster, click the "Add module" button in the top right corner. You should be taken to a screen where the first step is to choose a template.

Feel free to use the existing templates or you can import your own (read more about it here). I will use the demo template for this guide as it is the simplest. I name my new module (in the theme of the article) and use the default values for the rest of them. If you want to deploy your own application, use your docker image (with the correct version underneath) in the image field.

To deploy your application, click "Save"!

Cyclops will use the values you specified on the previous screen and, based on the template you used, will create all the necessary resources your application needs. You never had to even look at configuration files! After a couple of seconds ⏳ (depending on the docker image you used in the image field), your application should be up and running.

Now you can access your app with a port-forward command (in a similar way that we access Cyclops), and that’s it ⌛

kubectl port-forward svc/speedrun 3001:80

Time’s Up ⌛

If you followed along, you should have been able to deploy your application to a Kubernetes cluster running in the Civo cloud - in under 10 minutes!

We used the default setup for Civo and for Cyclops. This setup can be vastly improved by using more powerful nodes or adding more of them - all of this can be configured when creating the cluster in the Civo dashboard!

And the demo template that I used in Cyclops is just a simple example of what it can do for you. Play around with other templates and try to make your own. Cyclops was made to quickly and easily create developer platforms that hide the complexities of Kubernetes from developers. It brings the developer experience of big tech to companies of any size.

If you enjoyed this guide, show us your support by starring our repo ⭐

For the past few days, we at Cyclops have been walking between the whiteboard and our laptops, trying to figure out how to design one important part of our project: the authentication of Cyclops to different services. To be more precise, we wanted to allow users to access their private GitHub repos through Cyclops.

Why was this an issue? In the beginning, we were torn between solutions that either bloated the codebase by adding a database that Cyclops would not use apart for the authentication or made the onboarding process overly complicated and scare away potential new users.

After some brainstorming, we found a solution that checked all of our requirements. In this article, I will showcase how Cyclops manages your secrets, the Kubernetes way…

Why did we need to manage secrets?​

A short background about Cyclops so the rest of the article is easier to follow:

Cyclops is a developer-oriented Kubernetes platform. Instead of making your devs learn Helm, Kustomize, or some other Kubernetes configuration manager, Cyclops provides a user interface where they can easily fill in the values to generate needed Kubernetes manifests.

We say it's a platform because you can easily create custom UIs for your Kubernetes workloads (read more about it here). You would store these UIs as templates. You can store templates in several ways, like Helm charts or OCI repositories, but the most popular is probably GitHub repositories.

Cyclops can access templates stored in public repos without issues; provide a repo + path + version, and BAM, you got it. But we wanted to enable Cyclops users to access the templates they stored on their private GitHub repositories (because you rarely make your infra code public).

We knew we could use GitHub tokens as a form of authentication, but how do we securely handle them?

By the way…​

Cyclops is open-source, we would greatly appreciate it if you could support us by giving us a star on our repo ⭐ 🙏

Kubernetes Secrets​

The first issue was storing the GitHub access tokens. Cyclops does not have a database of its own, so implementing one just for storing GitHub tokens seemed like a bad idea. So, we opted to use Kubernetes secrets.

“A Secret is an object that contains a small amount of sensitive data, such as a password, a token, or a key.“ ~ Kubernetes docs

Kubernetes secrets are a great way of storing sensitive data (like tokens) without exposing it in the pod definition or configuration files, so they seemed like a great fit.

However, the second issue was how to use these secrets securely.

Kubernetes Custom Resources (CRDs)​

Let’s quickly discuss custom resource definitions and then we can go on to how we implemented access to private repos.

In Kubernetes, Custom Resource Definitions (CRDs) let you create your own resource types, adding to the default ones Kubernetes provides (pods, deployments, …).

You can define a schema for your custom object with a YAML file and inform Kubernetes. From then on, you can use your custom resource as any other native Kubernetes resource.

Check out our previous blog, where we explore CRDs and use kubectl to gather apples!🍏

kubectl get apples

NAME          AGE
green-apple   6s

How we manage secrets, the Kubernetes way​

Cyclops has a CRD called TemplateAuthRule that allows you to define authorization for specific repositories. The CRD defines which templates you want to authorize and points Cyclops to the authorization data needed for those templates (Kubernetes secrets).

Each time the Cyclops controller fetches a template, it retrieves all TemplateAuthRules from the cluster and tries to match the templates repository to any of the TemplateAuthRules repositories (in the picture below spec.repo). If it does, it will fetch the referenced Kubernetes secrets and apply username and password to authenticate.

In the image above, the Cyclops controller fetches all TemplateAuthRules and tries to match the template repository to spec.repo from a TemplateAuthRule. If it matches, it will fetch the username and password from the referenced secret. In this case, both username and password reference the same secret my-cyclops-secret (spec.username.name and spec.password.name).

To fetch the username secret value, the Cyclops controller will fetch the referenced secret and use the key provided in spec.username.key to get the value from the fetched secret. The same goes for the password.

Since TemplateAuthRulesdoes not store secrets directly, you can still integrate your cluster with the External Secret Operator or other secrets management solutions!

Find a more detailed view into TemplateAuthRules and a tutorial on how to allow access to your own private repos here or by using our CLI here

Any questions?​

Hope I managed to explain how Cyclops manages your GitHub tokens and maybe even given you an idea of how to manage secrets in your own projects.

If you are interested in being a part of the Cyclops community, to contribute with code, content, or even critique, be sure to join our Discord community and leave a star on the repo ⭐ 🙏

Kubernetes applications rarely (if ever) consist of a single resource. In a basic example, you have a deployment running your app and a service to expose its functionality. This requires you to either have one manifest containing the definitions of both the deployment and service or two separate manifests (one for each resource).

Now, imagine you have multiple apps that require multiple manifests to run. To make managing them easier, you will want to group them together in logical units (or packages).

Further, when running microservices, many of these manifests will look very similar, often differing only by a couple of values or lines. As you can imagine, this can quickly become cumbersome to manage.

This is where Helm steps in. While Helm is not new to the scene, in this article, I will show you its benefits and how to improve the Kubernetes experience even further with something a bit newer…

Support us 🙏​

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository 🔗. If you like what you see, consider showing your support by giving us a star ⭐

What the Helm ?!​

Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application.

This is a quote directly from the Helm website 🔗, let’s “unpack” what it means…

Package manager​

Helm is often called the package manager for Kubernetes because it allows you to group multiple connected manifests that create an application into a Chart (package), making them easier to maintain.

A chart’s structure looks something like this:

my-chart
├── Chart.yaml
├── values.yaml
├── values.schema.json
└── templates
    ├── deployment.yaml
    └── service.yaml

A chart can contain additional files, but these are the essential ones (for example, a README.md perfectly aligns with Helm's definition of a chart).

The Chart.yaml file could be considered “metadata” of the package, containing some basic information like name, version, maintainers…

In the /templates directory, you will find all the resources that make up your application. All the manifests are grouped here (in this example, it's just a deployment and service).

Instead of using kubectl and applying these resources separately, charts allow you to package them together and install them into your cluster with a single command.

One of the big things that made Helm so popular was the public charts repositories(like ArtifactHub 🔗 or Bitnami 🔗). This allowed people to use complex configurations others made. Many companies publish and maintain helm charts of their own software so people can easily install them in their clusters.

Templating engine​

The second big feature of Helm is the templating engine. In the structure above, you probably noticed the values.yaml file. To understand why it's here, let’s actually look at our deployment.yaml. It can look something like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: {{ .Values.image }}
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels:
      app: {{ .Values.name }}
  template:
    metadata:
      labels:
        app: {{ .Values.name }}
    spec:
      containers:
      - image: {{ .Values.image -}}:{{ .Values.version }}
        name: {{ .Values.name }}
        ports:
        - containerPort: 80
          name: http

You will notice it looks a bit different than your normal deployment manifest (like the one you can find on the Kubernetes documentation 🔗).

This is actually a blueprint. Helm allows you to create blueprints with placeholders - {{.Values.image}}. The values for these placeholders are defined in the values.yaml file.

For example, values.yaml might contain:

name: my-app
image: nginx
version: 1.14.2
replicas: 1
service: true

Imagine you have multiple microservices that all use *almost*** the same YAML manifest, apart from a couple of lines or values. For example, they differ only in the image. Helms' templating engine allows you to use the same blueprint for all your microservices and customize the specific details using the values.yaml file.

So, if you have several microservices, you don’t need to write separate YAML files for each one. Just create a template and adjust the values.yaml for each microservice as needed.

The Developer Experience​

While packages and blueprints help when dealing with large manifest files, changing values in such a structure can still be an issue for inexperienced developers. If you look again at the values.yaml file from above, you can easily see how someone can mistakenly type the string “true” instead of boolean true, or even integer 1. It's an honest mistake, but it can cost you hours and hours of debugging time.

That is where values.schema.json comes into play. In this file, Helm lets you define the type of values and their limitations - essentially providing validations for the values.yaml. This makes it harder for developers to make mistakes similar to the ones mentioned above.

But the values.yaml from above is a pretty simple example. You will usually find much larger files with many more values (finding your way here 🔗 will take some time 😅).

And this is where Cyclops 🔗 lets you take the developer experience even further. Cyclops lets you define a UI that hides the complexities of large templates and allows you to define which fields your developers are exposed to.

The screenshot shows the Helm chart I used as an example before but now rendered in Cyclops. You can mold this screen to fit your needs, with many more (or fewer 😊) fields, allowing inexperienced devs to feel confident when deploying their applications in Kubernetes.

And the validations haven’t been lost with Cyclops, far from it → now they are shown instantly.

The great thing about Cyclops is that if you are already familiar with Helm, creating a UI for your use case is quick and simple because Cyclops renders the UI based on the values.schema.json.

To clarify, you can import your own (already existing) Helm charts to be rendered in Cyclops! If you are storing your charts on a private repo, check the documentation 🔗 to see how to connect it securely.

Cyclops is open-source, so give it a go!

Open Source Fiesta​

Helm is one of the most popular ways of handling Kubernetes configurations. It is a graduated project in the CNCF 🔗, maintained by the Helm community 🔗. The project is open-source, and its GitHub repo 🔗 has more than 26K stars and around 670 contributors - a testament to the size of the community around it. e

While Cyclops is a relatively new project compared to Helm, it is following in its footsteps. Cyclops has already been accepted into the CNCF landscape and has a fast-growing community around it.

Hope it helps 🙌​

Thanks for reading the article. I hope you found it useful. If you wish to be a part of the Cyclops community, to contribute with code, content, or even critique, be sure to join our Discord community 🔗 and leave a star on the repo 🔗 ⭐