If you have been looking for a tool to deploy your applications into a Kubernetes cluster, you have definitely stumbled upon Helm. Its the most common Kubernetes configuration management tool out there.

Helm is a package manager for Kubernetes. This means you can group your deployments, services, ingresses, and all other Kubernetes resources into meaningful units. This means that a software vendor (for example, Grafana) can create a single Helm chart, and all users can simply install a gazillion of resources with a single command, knowing it’s going to work.

I think some parts of Helm are awesome, and some are often misused and introduce complications without much benefit.

If you have some running Helm releases in your Kubernetes cluster, this one is for you!

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 Helm?

An application deployed to a Kubernetes cluster is usually not just a Deployment but a list of other Kubernetes resources like Configmaps, Secrets, Ingress, and many others. Instead of manually creating all of them time and time again, you could create a Helm chart that would define all of these resources in a single place, and then you can reproduce them when needed.

A Helm chart is a single Helm package. Grafana has its own Helm chart which defines all the resources you need to run it, MySQL has its own chart, and so on.

If you want to run a MySQL in your cluster you can simply install the chart to your cluster and not think about specific resources. With that installation, you just created a Helm release. Releases track what has been installed in the cluster so you can check what Helm charts you installed later on.

In a Helm chart, Kubernetes resources are defined as templates that allow users to customize them without having to dive into each one. You can customize your releases using the values files that contain configuration, which would be injected into the resource templates to create Kubernetes manifests. And this is where the trouble with Helm begins.

Cons​

I love the way Helm implemented their package management, but there are some things I’m not the biggest fan of.

YAML Configuration​

Helm’s templating engine is great for abstracting and reusing configuration. But each time you encounter a new Helm chart, you will need to spend some time figuring out what you can and can’t configure.

values.yaml is usually a good place to start since there you can find the default configuration. But, not all configuration needs to be defined in values.yaml, and you will need to dig through the docs (if there even is any) or, God forbid, the Helm templates to see how things map between values and templates.

There is no type safety, and you could easily make a typo in your configuration, resulting in an outage.

Configuration Persistence​

When you install a Helm release, Helm will, by default, use values from the values.yaml. You can inject any values from a file or directly with the --set flag while running helm install, but that then begs the question of what is actually deployed. Each time you want to upgrade your Helm release, you need to know exactly what is currently deployed to not override something by accident.

For example, you and your colleague are working on the same application deployed as a Helm release. Your colleague wants to set the number of replicas to 5:

helm upgrade my-release <helm repo> --set replicas=5

After that, you want to bump the version of your application to latest with the following command:

helm upgrade my-release <helm repo> --set image.tag=latest

You deployed a new version, but without knowing it, you have just overridden your colleague's changes and you are back to a single replica. Unless you check for the currently deployed values, you can’t be sure if you are overriding something deployed by somebody else (or even yourself a month ago).

Resource Overview​

Once a release has been installed, you will likely want to check what resources have been deployed and whether they are running as expected. Helm solved it with the helm status command that can list all the resources.

This is more a personal preference, but I find it strange to list deployed resources with the helm cli and then dig deeper with kubectl. Ideally, I could check my resources from a single pane of glass.

Managing Helm Releases with Cyclops

Cyclops natively supports Helm charts and their deployment. It addresses the problems listed above and provides you with a custom UI for all of your Helm charts.

Instead of configuring your Helm charts via YAML, Cyclops will generate a UI based specifically on the Helm chart values. Since you are configuring your app through a form, you can now see all of the fields you can configure and be sure the values you provided are validated.

Instead of relying on Helm releases, Cyclops implements its own Custom Kubernetes Resources called Modules, which reference Helm charts and keep all of your values persisted.

Since version v0.17.0, Cyclops allows you to migrate your existing Helm releases to Cyclops Modules in a non-invasive fashion. It will just create a new Module for your application and delete the release without deleting or redeploying your applications.

Migrate to Cyclops​

Cyclops can automatically pick up on all of your Helm releases currently running in the cluster and offers you the ability to migrate them to Cyclops Modules. A Cyclops Module is a custom Kubernetes resource that references a Helm chart and contains all the values used to configure that chart.

With such an approach, you don’t have to worry about what value files you need to use, how those overlap… Instead, everything is in a single place defined declaratively. If you want to change any of the values, feel free to do it via Module YAML, in the Cyclops UI, or any other way you want.

Let’s migrate those releases!

Install Cyclops​

First of all, you will need to install Cyclops into your running Kubernetes cluster. You can install Cyclops with the command below:

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

To access the cyclops-ui you can just port-forward its service, but for production usage you can expose it via an ingress or a load balancer.

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

You can now access Cyclops at http://localhost:3000/.

Migrating Helm releases​

For the sake of the tutorial, I installed three Helm charts. If you don’t have any Helm releases installed to try the migration, you can install the official PostgreSQL chart with the following command:

helm install my-api-database oci://registry-1.docker.io/bitnamicharts/postgresql

When you open Cyclops, you can navigate to Helm releases in the sidebar to list what is currently deployed in your cluster.

From there, you can select any of your Helm releases and check Kubernetes resources deployed with that specific release.

When you are ready to migrate your release and use Cyclops modules, click the Migrate to Cyclops Module, which will open a pop-up where you can input the Helm chart reference. In this case, it would be the Bitnami git repo and its PostgreSQL chart on the main branch.

Chart reference can also be a Helm repository or an OCI Helm chart.

Once you confirm the chart reference, Cyclops will pull it to verify it, and if the reference is valid, redirect you to a page where you can tweak the configuration before migrating to a Cyclops module.

Don’t worry; Cyclops will retain the configuration you previously had for your Helm release; this step only allows you to change it if needed.

Once you are happy with your configuration, you can hit Deploy, and Cyclops will create a new Module with your template reference and all of the values you provided.

All previously deployed resources will remain unchanged, and none will be destroyed in the process. The only change that happened is that you now have a Module managing your resources.

With Cyclops, you now have a centralized place for your app configuration and can now view all of your resources and their status in a single place. Also, you and your colleagues are not stepping on each other's toes!

Future work

We at Cyclops plan to expand beyond supporting Helm and want to make our Modules support any kind of configuration language. Let us know what you are using (Kustomize, KPT, Cue…), and we would be happy to support it next!

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 ⭐

Before diving into internal developer platforms, it’s important to understand platform engineering first. Platform engineering evolved from DevOps and aims to address the growing complexity of modern software development.

However, while DevOps focuses on bridging the gap between development and operations, platform engineering takes it a step further. The goal of platform engineering is to establish a unified platform that enables developers to move as fast as possible with as much safety as possible.

But why did this trend emerge, and how does it differ from what is currently out there?

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 ⭐

Why Developer Platforms​

A lot of the motivation behind building internal developer platforms is centered around the idea of self-service.

When you think of DevOps, you envision automation, pipelines, monitoring, and other Ops-like functions. While most of these things are focused on enabling developers to move faster, in reality, the DevOps team can often feel like a bottleneck.

If you need to raise a ticket with the DevOps team whenever you want to create a new service, change something in the configuration, or have issues with a deployment, it will inevitably slow you down.

On the other hand, the DevOps team doesn’t always want to spend their time reviewing every minor change requested by developers. They’d rather focus on more productive work than act as a helpdesk for routine requests.

A system where every infrastructure and deployment change has to be reviewed and approved by the DevOps team is often called ticket ops

(Internal) Developer Platforms​

A developer platform is a product built by the platform team to support application developers and the rest of the engineering organization. It connects all the tech and tools in a company into streamlined workflows, often called "golden paths," that reduce cognitive load and simplify self-service for developers.

Since these platforms are designed specifically for internal use within an organization, they're often called Internal Developer Platforms.

A developer platform can take many forms. From a documentation page and a couple of bash scripts all the way to fully fleshed-out self-service portals.

A platform's features and use cases should be driven by what developers actually need, whether it's provisioning infrastructure, spinning up environments on demand, or providing a central catalog of services.

At its core, a developer platform should act as a force multiplier, enabling teams to ship faster by removing friction and streamlining workflows.

Just to clarify the distinction between developer portals and developer platforms, a developer portal is simply the interface (typically a GUI) developers use to access the internal developer platform.

Building Internal Developer Platforms​

There are a couple of important things to keep in mind when building an internal developer platform.

The platform is a product, and you should treat it as such. It should be designed around user needs and continuously improved, just like any other software product. Just in this case, the users are your own developers!

A good platform abstracts complexity, reduces the cognitive load for users, and makes it easier for product teams to focus on delivering value rather than dealing with infrastructure.

But in the end, it’s all centered around self-service. Developers should be able to request and provision resources independently and with confidence without relying on manual approvals.

A platform should support the above features and workflows, but just because it provides certain capabilities, it doesn’t mean the platform team has to build everything themselves. In many cases, a lot can be accomplished with the use of external tools (proprietary or open-source).

Learn more ⬇️​

At Cyclops, we’re creating an open-source framework for building internal developer platforms on Kubernetes. We make it easy for you to provide golden paths to your developers by allowing you to create custom UIs from your Helm charts.

If you are interested in learning more about platform engineering, I’m nudging you to check out the CNCF Platforms White Paper, the Internal Developer Platform Org, and the Platform Engineering Org. Hope you find these sources as useful as I did.

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 ⭐

Platform engineering is possibly the biggest concept to take hold in infrastructure over the last 5+ years, and there’s a big reason why. For decades, application engineers have dealt with systems that have constantly thrown roadblocks and delays in their way. Platform engineers address this problem by building systems that enable self-service and provide useful abstractions that help those other engineers build and run their applications. As we know, enabling self-service helps both productivity and developer happiness.

However, building and maintaining a platform can be expensive, and not every organization has the budget for a dedicated platform team. For organizations with platform teams, there’s an ongoing tension between either building custom tools, using open source tools, or buying commercial solutions. Each of those options requires some kind of investment, but for many teams, building platforms largely composed of open source tools is a strong choice. The team doesn’t spend a lot on software licenses and isn’t stuck maintaining all the code.

In this post, we’ll look at Cyclops, an open source tool for building developer platforms. Cyclops lets teams deploy and manage applications using Helm charts as templates.

Prerequisites​

The main requirement for this tutorial is a Kubernetes cluster. In this example, we’ll use kind to provision a cluster, but feel free to use a different method if you prefer. If you’re not already using kind, you can install it using the instructions in the docs. You also need a local Docker-compatible daemon to use kind, like Docker, Podman, or Colima.

You will also need kubectl. You can find instructions for installing kubectl in the Kubernetes docs.

Provision a cluster and install Cyclops​

First, provision a cluster.

kind create cluster --name cyclops-demo

Your kube context should already be set to point to the kind cluster. You can test that you can connect by viewing the namespaces in the cluster.

kubectl get namespaces

Next, install Cyclops into your cluster with kubectl.

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

As you’ll see from the output, Cyclops is composed of Kubernetes native objects.

customresourcedefinition.apiextensions.k8s.io/modules.cyclops-ui.com created
customresourcedefinition.apiextensions.k8s.io/templateauthrules.cyclops-ui.com created
customresourcedefinition.apiextensions.k8s.io/templatestores.cyclops-ui.com created
namespace/cyclops created
serviceaccount/cyclops-ctrl created
clusterrole.rbac.authorization.k8s.io/cyclops-ctrl created
clusterrolebinding.rbac.authorization.k8s.io/cyclops-ctrl created
deployment.apps/cyclops-ui created
service/cyclops-ui created
networkpolicy.networking.k8s.io/cyclops-ui created
deployment.apps/cyclops-ctrl created
service/cyclops-ctrl created
networkpolicy.networking.k8s.io/cyclops-ctrl created

There should now be two pods running in a new namespace called Cyclops. We can view them with:

kubectl get pods -n cyclops

You should see output like this:

NAME                            READY   STATUS    RESTARTS   AGE
cyclops-ctrl-7984df7589-wv4dw   1/1     Running   0          36s
cyclops-ui-64c4cdd7f7-fxnb7     1/1     Running   0          36s

The first pod handles the Cyclops API, manages the CRDs, and communicates with the Kubernetes API server. The second pod runs the Cyclops web UI.

Next, we will install a set of example templates that we will use to see how Cyclops works.

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

Finally, let’s connect to the Cyclops web UI. First, forward a port to it using kubectl.

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

Next, connect to the UI with your browser at http://localhost:3000/.

Deploy Nginx with a generic app template​

For the first portion of the demo, we’ll deploy Nginx using Cyclops.

Open a new terminal window/tab and create a namespace called nginx.

kubectl create namespace nginx

Now, go back to the Cyclops UI tab in your browser. Click Add module in the upper right corner of the Cyclops screen. Think of a module in Cyclops as an application and all of the other Kubernetes resources required to run it.

Next, we’ll select a template. Cyclops templates are Helm charts, and Cyclops can use charts from GitHub repositories, Helm chart repositories, or OCI repositories.

Select app-template from the Template pull-down list. This generic template creates a Kubernetes deployment and service for an application.

For the module name, enter nginx. Click on Advanced. Select the nginx namespace from the Target namespace pull-down menu.

Click on General. You can see that some defaults have been populated, like the image name version. Leave them set to the defaults. Those values are being pulled from a values.yaml file in the Helm chart.

You’ll see some other configurable options under Scaling and Networking. You can also leave those set to the defaults. Scroll down and hit the Deploy button in the bottom right of the window.

On the next screen, you’ll see more information about the module and its status as it’s deployed. There’s a link to the template it was deployed from and information about the Kubernetes resources that have been created.

Click on nginx Deployment to see that one pod is running. We can confirm that info in the terminal by running this command:

kubectl get pods -n nginx

That output should match what you saw in Cyclops.

Go back to the Cyclops browser tab. Under Actions, you can see several buttons for making changes to a running module. Edit will let you change the configuration. Reconcile will re-create the resources. Rollback will revert to the previous version of the module if you have made changes. You can view the code for the module using the Module manifest button, and Rendered manifest lets you view the Kubernetes YAML for the running resources.

Click Edit, and then change the number of replicas to 2 under Scaling. Then, hit the Deploy button.

Once the status goes back to green, hit the Rollback button. You’ll see a list of the module's previous generations (versions). There should just be one. Click the Rollback button for that generation, and you’ll see a diff of the changes that were made.

Click the OK button to perform the rollback.

Some teams won’t want to manage changes through the Cyclops UI, of course. You can instead use Cyclops with GitOps tools like Argo CD. There’s a GitHub repo with examples here.

Finally, let’s clean up. Click Delete, and type in the module name to confirm.

Deploy Redis with Cyclops​

We’ve seen how to deploy an app with a custom Helm chart, but Cyclops can also deploy applications using existing Helm charts. Let’s look at how that works by deploying Redis using the Bitnami chart, which is included with Cyclops.

At the terminal, create a namespace called redis.

kubectl create namespace redis

In the Cyclops browser tab, click Templates in the left nav bar. Type “redis” in the search box to see the info for the installed template. The source for it is the Bitnami GitHub repo, and it’s coming from the main branch.

No, click on Modules in the left nav and then Add module again. Select redis from the module pulldown list, and type in “redis-cache” for the module name. Click on Advanced and select redis from the list of namespaces.

Scroll down. You will see many other options that can be customized for the Redis install. Feel free to expand and view any that interest you, but leave them set to the defaults. Then, click the Deploy button in the bottom right.

It may take a bit for Kubernetes to spin up all the resources, but eventually, they should all go green.

We can confirm the pods are running with this command:

kubectl get pods -n redis

You should see the primary/master node and three replicas like this:

NAME               READY   STATUS    RESTARTS   AGE
redis-master-0     1/1     Running   0          4m6s
redis-replicas-0   1/1     Running   0          2m21s
redis-replicas-1   1/1     Running   0          3m10s
redis-replicas-2   1/1     Running   0          2m46s

We can use any Helm chart with Cyclops like this to allow users to deploy the applications they need to run. In the case of a complex module like this one, you can set default values that are needed for your team or even create a custom Helm chart that exposes fewer options.

That’s it for the tutorial. To clean up, you can delete the kind cluster.

kind delete cluster -n cyclops-demo

Conclusion​

We’ve learned how to deploy applications with Cyclops using pre-existing Helm charts and custom ones, and we’ve seen how Cyclops allows teams to easily expose the abstractions they need for developers to deploy and manage their apps.

Whether you’re at an organization that’s not staffed for a dedicated platform team or your platform team would like an easy way to provide self-service for developers, Cyclops could be a great fit for your workflow.

Learn more​

• The Cyclops docs are a great place to start.
• Check out their open-source repository and support them with a star.
• There’s a community Discord if you’d like help or to give your feedback.

To start this off, I want to say that I’m not some sketchy betting tips dealer and to be honest, I don’t even watch sports. But I want to share why we’re placing a big bet, a startup-sized bet, on Kubernetes (and we are not the only ones doing it).

And no, it’s not what you think. We’re not just using Kubernetes as part of our tech stack. It’s not that simple. Our entire startup depends on the success of Kubernetes. We are literally all in, and I want to tell you why we feel comfortable with that decision.

I have a couple of important points I want to lay down, and I hope they’ll give you a clear picture of why Kubernetes is not just a safe bet for us but an inevitable one.

It’s Open-Source​

The first thing I need to mention is that Kubernetes is open-source and supported by a massive, active community. On GitHub, it boasts over 112K stars.

Being open-source has cultivated a thriving community around it, and I don’t mean that as a buzzword. There’s an incredible amount of content available - blogs, tutorials and videos. While Kubernetes is famously complex, the wealth of resources online makes it far more approachable.

But it doesn’t stop at educational content. Kubernetes’ open-source nature has also enabled an extensive ecosystem of tools, integrations, and extensions, from Helm charts to advanced monitoring tools like Prometheus. Tools like these emerged to fill the gaps in Kubernetes, moved it towards widespread adoption, and have become almost a core part of it.

It’s Battle-Tested​

The first commit of Kubernetes was pushed to GitHub on June 6th, 2014, which was more than ten years ago.

Since then, it has seen a massive rise in popularity. Not only can you run Kubernetes on your home lab, but every major cloud provider offers a managed version of Kubernetes. Over the years, it has gained the status of “production-ready” and is now the most popular container orchestrator. In 2021, there were 5.6 million developers that use Kubernetes worldwide; today, that number is undoubtedly even higher.

It’s the platform for building platforms​

“Kubernetes is a platform for building platforms. It’s a better place to start; not the endgame.” ~ Kelsey Hightower

One of the most fascinating aspects of Kubernetes is that it’s not just a tool for managing containers - it is an extensible API.

The creators and maintainers of Kubernetes have had great foresight when creating the architecture and design patterns for it. Kubernetes allows you to extend its base functionality with your own custom operators and resources.

Apples 🍏​

Let’s say you want Kubernetes to manage something completely unrelated to containers—like apples. By defining a Custom Resource Definition (CRD) for apples, you can “teach” Kubernetes to recognize them as a resource type. Kubernetes is now not only a manager for deployments and pods, but for apples, oranges, or whatever else you want. Once that’s done, you can use native Kubernetes commands to interact with your apples:

kubectl get apples

NAME          AGE
green-apple   6s

This silly example shows the power of Kubernetes’ extensibility. By defining apples as a custom resource, you make them behave like any native Kubernetes object. This means you can manage them declaratively (e.g., creating or updating their desired state) and enjoy Kubernetes’ core features, like self-healing, scaling, reconciliation loops...

You can imagine that instead of apples, you are interacting with databases or S3 buckets. Now, suddenly, you can use Kubernetes to provision infrastructure instead of just managing your applications.

This is a very powerful concept.

So, what are we betting?​

At Cyclops, we are creating an open-source framework for building developer platforms on Kubernetes.

We believe that Kubernetes is not just a trend - it’s the future of building cloud-based services. As the ecosystem matures, Kubernetes is quickly becoming the standard for managing and orchestrating workloads in the cloud.

We’re betting on Kubernetes becoming the foundation for developer platforms. More and more companies are interested in building custom developer platforms that empower their teams. These platforms streamline workflows, simplify the development process, and provide tailored tools for their unique needs (learn more about platform engineering).

We are betting on companies building developer platforms on top of Kubernetes, and we want to help them on this journey.

By the way… 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 ⭐

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 ⭐🙏