Skip to main content

Why nobody grows up wanting to be a DevOps engineer

· 13 min read
Jake Page
Developer Relations Engineer

article-thumbnail

When I look at younger generations that didn’t grow up largely offline like I did, I feel slightly sorry for them. I’m in my mid-thirties, so I know what it was like to grow up tapping into dial-up internet as quickly as possible (to avoid blocking the phone line for too long) to access a couple of Wikipedia pages to do my homework and not feel like anything was missing. By personally living through the ascendence of the personal computer we all have in our pockets I feel, not immune, but better equipped to use it to my advantage and not fall victim to its false promises of limitless bliss and fulfillment simply for being more “connected”.

On the other hand, there is another revolution that I was not directly a part of, the revolution that happened in the IT departments worldwide across the 00s in the aftermath of the now-legendary Flickr talk at the O’Reilly Velocity conference in 2009. An event that put DevOps on the map and showed a future that could pivot from the siloed, slow-moving ITIL-based organization to something better.

Since I recently switched careers from teaching to tech less than 5 years ago. I don’t know what it’s like to work in any other professional environment that doesn’t live and breathe the practices imparted in that seminal Flickr talk. Agile methodologies and the still difficult-to-pin-down definition of “DevOps“ is a status quo I’ve never had to question.

But I question it now. If I argue that up-and-coming generations are missing fundamental perspective and have a lot to gain from knowing what it was like to live without smartphones. I have to apply the same logic to myself and make a concerted effort to understand what DevOps really is? What did it emerge as a response to? What were its initial promises and have those promises been delivered? How and why do people end up being DevOps engineers? And what will it mean to be a DevOps engineer in the future?

How DevOps Started and it’s original Promise

I sometimes wonder what it must have been like back in the days when devs had to put in infrastructure provisioning request forms and wait days or weeks to be served. I’ve heard the stories of what stereotypical Ops people of that culture were like, finger-pointing grumps whose favorite words were “NO“ and “Where’s my pager?“ .

John Allspaw and Paul Hammond, as well as many attendees of their famous velocity talk, “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr," didn’t have to wonder, the common friction between devs and ops teams must have been all too vivid to them.

After watching the talk a handful of times over the years, a few things stand out to me. The first, is that I was unaware that talks back then contained so much swearing or maybe it’s just Mr. Allspaw. Another was the key message the speakers put forth, that both Dev and Ops teams effectively shared the same objective. To enable the business.

They go on to talk about the tools and cultural traits organizations might want to adopt to achieve multiple deployments to production a day. They spoke of automated infrastructure, feature flagging, shared alerting and monitoring, all coalescing around a renewed collaborative culture that valued trust and a healthier attitude towards system failures and blame avoidance above all else.

The shape of what DevOps would come to mean in the following years was further crystalized in large part by the hugely influential DevOps Handbook and Site Reliebility Engineering books.

the-main-books

The opening chapter of the former describes in few words what a DevOps way of doing things aspired to unlock

“[Multiple team working together to] enable the fast flow of planned work into production (e.g., performing tens, hundreds, or even thousands of code deploys per day), while achieving world-class stability, availability, and security.”

Have we delivered on the promise?

The feeling of walking on the shoulders of giants comes to mind when I think of the ideas presented in that Flickr talk. Those ideas that must have been so revolutionary to many are the only professional reality I've ever known. So regardless if improvements could be made to current DevOps methodologies, best practices and tooling, I for one am grateful for all the progress that has been achieved so far. Anyone I ask who was configuring servers or hacking before 2009 corroborates that things are better now than they were back then.

Having said that, are most companies shipping like crazy, while achieving world-class stability, availability, and security? Largely no. The DevOps world even with a massive toolbox full of modern tooling available, still runs off of the exact same framework that was proposed in that talk.

In the words of Adam Jacob

“The problem isn’t that we haven’t optimized each individual part of the system enough. We’ve built more efficient tooling at every step. But the way the whole system is put together? The experience of using it? That’s basically identical to how it was in 2009, and it’s the reason we’re stuck.“.

Siloes still exist, handoffs are error-prone and collaboration on many occasions is quite forced and rigid. Anybody who has worked as a DevOps engineer for any length of time will have a long list of things they think their organization gets wrong and will often have equally low amount of faith in their organization’s capacity to do anything about it. Adam, a veteran DevOps practitioner, has even called for a second wave DevOps which goes further than trivially improving tools and invites us to think outside of the box, challenge the established rules, and see what’s on the other side.

Speaking of DevOps practitioners, who are these people? How and why does one become one?

How do people end up in DevOps in the first place?

In just 15 years, the technology industry has evolved significantly. Job titles like DevOps engineers, SREs, and Platform engineers are now common on job boards and are hot items for tech recruiters. However, outside the IT world, these terms are still largely unknown. Despite its rapid growth, DevOps isn’t yet a profession people aspire to join; instead, it’s something many simply "fall into".

I stumbled into DevOps after a conversation with my cousin, who suggested it following my decision against a strict network engineering path after earning a CCNA certificate. Curious about who ends up in DevOps and if future engineers might choose it as their first career option, I asked the /devops subreddit and was surprised by the variety of opinions.

I found some fellow “I just fell into it“ people:

fell-into-it

Others are moderately bullish on newer generations:

optimistic-devops

DevOps-chooses-you

Others not so optimistic:

I-hope-not

kids-aspire

Even though the definition of DevOps is still highly disputed, it seems unlikely to ever position itself as a profession students hear about at job fairs or see permanently added to university curriculums. This might be because we tend to imagine ourselves excelling in specific areas, believing that specialization increases our chances of success.

When I was growing up, I fantasized about being the lead guitarist in a famous band, with god-level shredding abilities. I wasn't dreaming about being reasonably good at playing all the instruments.

In DevOps, there are no guitar solos. To excel, you need to be familiar with a long list of tools, languages, frameworks, hyperscalers, and processes. The best DevOps engineers are generalists at heart. This modular, Lego-like nature of the work and experience might make DevOps less popular outside of IT departments.

The case for generalists, tinkerers, and the concept of glue

It’s impossible to attempt to form a non-subjective profile of what traits a DevOps practitioner should have but in my short experience and what I’ve learned from conversations with more experience individuals than I, a few traits emerge.

Generalists

Have you ever read a “How to land a job in DevOps“ guide? Remember the knowledge requirements section? Linux, Docker, CI/CD, Git, Hypersclaer of choice, Networking etc. The list goes on usually in the desired experience section of DevOps job requirements.

If you’ve interviewed for roles such as developer or product design roles you will more than likely have to show a portfolio at some stage of the process. This is rarely the case in DevOps interviews. I can’t think of one person who has assembled and updated a DevOps portfolio on a regular basis? The modular and distributed systems-building nature of DevOps roles just doesn’t lend itself well well-curated displays in a portfolio.

As someone who was bored out of his brain teaching high school-level English for seven years, I naturally gravitated towards DevOps, a field requiring me to learn many tools and concepts and piece them together collaboratively. Not specializing deeply in any one concept but refining the skill of quickly learning new things is the callus I developed. Generalists who thrive in such environments fit right in.

Tinkerers

People who do well in DevOps might think of themselves as tinkerers.

tinkerer

I love this idea, and it fits many DevOps engineers I've met. Being interested in learning how things work simply for the knowledge of it is a common trait among the DevOps mentors I’ve had. Sure, spending the weekend installing a beefier switch in your home lab or rendering new mini figurines on your 3D printer doesn't directly show DevOps skills, but this background knowledge can indicate potential success in DevOps more than certificates can.

Glue

Much of the work in complex systems can go under the radar since it’s hard to plan or predict. Since DevOps involves weaving tools together to build a platform or delivery system, a lot of glue is needed.

Processes must be put in place and automated to keep up with technical debt and maintenance work that accompanies every tool in a tech stack. Individuals who can naturally and often thanklessly act as the glue, connecting disparate parts of the system through automation, communication, or improving repetitive processes, are instrumental to organizational success. This skill isn't something you list on your CV, but combined with the curiosity of a tinkerer and the openness of a generalist, it's a potent combination.

The current state: Platforms vs DevOps

A false dichotomy often arises in these discussions usually for marketing reasons: that DevOps is dead and platforms are the future. Platform engineers aim to give developers autonomy over traditionally Ops-related components (k8s, IaC components, IAM) without direct interaction, allowing developers to self-serve and be independent.

A well-designed, context-specific platform can increase developer velocity. According to the 2023 Puppet State of DevOps report, over two-thirds (68%) of respondents saw improved development velocity after adopting platform engineering. However, velocity shouldn't be the only metric. As georgouslyhumble points out on Reddit, sometimes the goal is to maintain existing velocity while meeting new organizational requirements. For instance, a logging sidecar can standardize log collection without changing developer velocity, enhancing the platform to meet increased company requests.

Ops work remains complex and dynamic, and skilled Ops personnel are essential above a certain threshold of complexity. Platforms enable developers but notice that they don't necessarily reduce silos or integrate Dev and Ops teams more closely.

Teams are rightly cautious when adding new tools to their stack because new tools often introduce introduce maintenance and upkeep overhead that quickly stacks up. Tools like Glasskube, which reduce operational overhead, are essential. These are the tools we need more of to create robust and efficient DevOps platforms for the future.

Future predictions

A certain type of platform will win out

The systems, platforms or methods of working that will win out will not have to “teach“ its users how to work and collaborate together. A future system that delivers the incredible possibilities of endless software shipping without compromising security and stability will only be possible if it makes team collaboration and cooperation the easiest, most intuitive, and most natural way of working while abstracting the work that neither devs nor ops are excited to do.

To create it though we are going to have to think outside of the box.

A second wave of DevOps might be one the way

Thankfully there are many restless and nonconforming people who contribute to the constant improvement of methodologies, processes, and tooling in the DevOps space. Some might say that a formal movement of rethinking what DevOps could be is already emerging and that’s pretty exciting.

The more generalists and tinkerers, the better

The best-equipped individuals to keep connecting the puzzle pieces, close feedback loops, and rethink lousy ideas are those who are not afraid to trade deep specialization for professional genaralization. Those who dare to venture out and learn on the fly by tinkering, testing, and asking questions along the way are the ones who will keep the figurative ship afloat as it moves faster and faster towards engineering excellence.

How to find enough of these people is another question.

Conclusion

It looks like I'm no closer to knowing why people don't grow up wanting to be DevOps engineers, perhaps it's a blend of still being a relatively new field coupled with the fact that generalists aren't usually know as the coolest kids on the block.

Looking ahead to the next wave of talent, whether they consciously choose or stumble into DevOps roles, one thing is certain: understanding the field's history is key. It's the only way future engineers can develop the ability to identity the gulf between the current state and the aspirational future of what could be. By neglecting this gap, the status quo will prevail and we will be destined to stagnant mediocrity.

While it's undeniable that the tech landscape has vastly improved since the pre-DevOps era, it's equally evident that DevOps is still finding its footing 15 years in.

Seasoned professionals need to keep a keen eye to identify and encourage the young tinkerers, generalists, and "glue people" around them to not worry about chasing certain titles but rather help redefine and **evolve DevOps into something that delivers on the original aspirations of 2009.


If you like this sort of content and would like to see more of it, please consider supporting us by giving us a Star on GitHub 🙏 cats-like--github-stars

Glasskube Beta is live.

· 5 min read
Jake Page
Developer Relations Engineer

Product hunt upvote

Glasskube has been on a tear lately. 🚀

Having only just launched officially last February and having been received incredibly positively by the cloud native and Kubernetes community we are happy to announce that Glasskube Beta is upon us. The Glasskube team as well as the growing community of Glasskube open source contributors have rallied and combined forces to bring the Beta release sooner than expected. Everybody involved deserves a huge round of applause. 👏

As we release Glasskube Beta we aim to bring to Kubernetes engineers tasked with maintaining the lifecycle of the packages that make up their clusters with an expanded and more mature version of Glasskube that delivers on the early promises of on app package configuration, automated updates and an ever growing package catalogue. The Beta release is still not intended to be run in production environments, in order to become production ready in the upcoming releases we hope to get valuable feedback from the Glasskube community.

We are so excited to get this release in the hands of all of you and see what you think. Here as some of the features and updated shipped:

  • 👍 Easy package configuration options
  • 🏗️ Added dependancy management
  • 📊 Shipped graph-based dependency validation
  • 🆕 Supported three new packages
  • ✨ Many CLI and UI upgrades

Easy package configuration 📦

One of the main issues we see with traditional Kubernetes package managers is the inability to configure packages without having to depend on third party configuration tools to get the job done. Now with Glasskube if your package depends on additional configuration steps it can be done right in the UI or CLI. Let’s take the example of the k8sgpt-operator, you can decide on which language you want the operators output to be in as well as being able to add the OpenAI API key upon installation to make sure k8sGPT runs right out of the gate.

Package configuration feature

New package integrations 🆕

We added to the package catalogue, actively supporting 10 packages. Check out to see both the supported and upcoming packages we will support next right here.

New packages supported

Grafana

Grafana open source software enables you to query, visualize, alert on, and explore your metrics, logs, and traces wherever they are stored. Grafana OSS provides you with tools to turn your time-series database (TSDB) data into insightful graphs and visualizations. The Grafana OSS plugin framework also enables you to connect other data sources like NoSQL/SQL databases, ticketing tools like Jira or ServiceNow, and CI/CD tooling like GitLab.

K8sGPT

K8sGPT is a tool for scanning your kubernetes clusters, diagnosing and triaging issues in simple english. It has SRE experience codified into its analyzers and helps to pull out the most relevant information to enrich it with AI.

Kube Prometheus stack

A collection of Kubernetes manifests, Grafana dashboards, and Prometheus rules combined with documentation and scripts to provide easy to operate end-to-end Kubernetes cluster monitoring with Prometheus using the Prometheus Operator.

Next packaged to be supported ⏭️

Litmus

Litmus is an open source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way.

Kubeflow

The Kubeflow project is dedicated to making deployments of machine learning (ML) workflows on Kubernetes simple, portable and scalable. Their goal is not to recreate other services, but to provide a straightforward way to deploy best-of-breed open-source systems for ML to diverse infrastructures. Anywhere you are running Kubernetes, you should be able to run Kubeflow.

Robusta

Robusta is an open source observability tool for Kubernetes, which extends Prometheus. Using automation rules, Robusta automatically fetches the data you need to investigate, and attaches it to your alerts.

Check our of webinar last Tuesday with Kunal Kushwaha 🌐

Here Glasskube co-founder Philip Miglinci walked us through the new Glasskube features, improvements and gave a greate demo that included how to install and manage kubernetes packages using a GitOps framework by leveraging ArgoCD and a super simple process to seemlessly manage your cluster package stack. Really cool talk!

We launched on Product Hunt 😼

We launched the project on Product Hunt on April 24th.

It was a great exercise to get Glasskube in front of an audience that we might not have known about the project. Product Hunt isn’t best know for showcasing developer tools but he got a great reception from the community and some stellar feedback too. Well worth the effort.

Product Hunt profile

By getting a sizable amount of upvotes for a niche DevTool, we are extremely happy to see those upvotes translating over to many users visiting the GitHub repo and leaving their support and even picking up open issues.

Feedback wanted 🙏

Glasskube is a tool designed for Kubernetes enthusiasts and engineers alike. As we're currently in the early stages of development, your feedback could be pivotal in shaping the direction and features of our upcoming product roadmap. We invite you to explore Glasskube Beta, integrate it into a non-production Kubernetes cluster, and experience a streamlined approach to managing your third-party cloud-native packages. Share your experience with us, and help us refine Glasskube for optimal usability and effectiveness.

Support is always welcome ⭐

Do you like the project and want to help us out? Giving us a star on GitHub will really make our day!

Screenshot 2024-04-26 at 10 54 54

Why contributor guidelines matter.

· 5 min read
Jake Page
Developer Relations Engineer

TL;DR

As an open-source project maintainer, you should be obsessed with Developer Experience. I don’t need to convince you that the README.md needs to be clear and informative. Everybody knows how great documentation can elevate a project. Having a top-notch CONTRIBUTING.md file is the missing piece to retain the open-source contributors you attract.

The CONTRIBUTING.md file should not be confused with a tutorial or a project guide, it’s reference material for developers who want to understand what work is available and how to get involved quickly.

Make sure your guidelines are:

  • Clear and actionable
  • Use precise language
  • Easy to skim through
  • Point to additional resources

Understand your audience

Developers are not a monolithic group of internet dwellers who all care about the same problems, have the same experience, or work the same way. Having said that, there are a few things that are broadly applicable. They want to read less and build more. 🏗️

Developers care about getting started quickly and it’s on the project maintainer to remove as many obstacles as possible to make that happen.

How can you reduce the time from when a developer finds your project to when they submit their first PR?

To get started, contributors need to find an issue to work on. Make sure you have open issues ready that are tagged to cater to all potential contributors. If a junior developer wants to learn a new language through your project make sure good first issues are easy to find. If more ambitious, senior types, are ready to make an impact, make sure it’s clear which issues you would like them to consider, pointing them to a current milestone or GitHub project.

Define contribution paths

Make clear what kind of paths there are to contribute to. Which areas of the project need help? Leverage GitHub tags to segment each project domain. In our case, Glasskube has different components such as a GUI, a CLI and Package Controller, Docs, a UI and the repo itself.

Community engagement

Ok, so the contributor knows that there are open issues ranging in different levels of complexity and they understand the different areas they can contribute to. How can they let you know they are ready to contribute to the project? What if they have additional questions? Make it clear how you prefer them to communicate with you, through GitHub, Discord, or Slack.

Try to not only limit communication to the GitHub issue itself. For many Open Source contributors the fun is meeting other like minded people to collaborate and share. Not to say they everybody want that, but make sure you invite contributors to a community, since they are not part of it.

Community engagement

Contribution workflow

Probably one of the most important parts of the Contributor guidelines is for contributors to have clear instructions and answers to the following questions

Detailing the step-by-step process for contributing code changes: 🪜

  • Issue selection and assignment.
  • Forking the repository.
  • Branching, coding, and committing conventions.
  • Pull request submission and review.
  • Handling feedback and iteration.
  • Merging contributions into the main codebase.
  • Addressing best practices for commit messages and keeping forks up-to-date.

Development guidelines

Each open-source project aims to solve a different problem and build on a certain stack that might be new to some contributors. Assume they know nothing about your tool and precisely explain the project’s building blocks.

Focus on informing how the code base is built, how each component fits together and describing setup environments. Ideally, contributors should be able to build local versions of the components they contribute to and validate their work.

If you only find out during the PR review process that it wasn’t clear to the developer, it's a sign that either the guidelines or collaboration process could be improved.

Testing

I can’t stress the importance of providing clear instructions for testing code contributions 🧪. For example, Glasskube operates within Kubernetes clusters, every contributor must have access to one for local testing before submitting a PR. While imposing testing criteria might be challenging, it's essential to remind contributors that PR reviews shouldn't be the moment where issues with functionality are discovered.

Documentation and best practices

Leverage your documentation heavily, the contributor guidelines as mentioned are reference material aimed at giving guidance by pointing the contributor in the direction of the answer they are looking for. 🔍

Keep the file structure very clear. Most people skim through this sort of material looking directly for what they need at the time. Make your guidelines skimmable.

Also, it’s safe to assume some contributors will never make it to your CONTRIBUTING.md page, and those who do will spend a limited amount of time there. Share a TL;DR that gives the main points you would like contributors to remember. Also, add the TL;DR to other places outside of the GitHub repo. I’ve added it to the #help-forum on our Discord server

Best practices

I’m really happy you have a killer README.md file, you have a bunch of well-tagged issues and are ready to welcome as many contributors as possible. But to retain and build trust within your community make sure to nail the CONTRIBUTING.md too.

To understand the value of the CONTRIBUTING.md file. I feel a restaurant analogy might be useful.

💡 We've all been drawn to a restaurant by it’s food menu, only to return for the exceptional service. Similarly, in the realm of Open Source projects, the README.md acts as the initial attraction, the enticing menu. However, it's the CONTRIBUTING.md file and how it enhances the overall developer experience that makes them return for more.

10 Steps to Build a Top-Tier Discord Server for Your Open Source Community. ✨

· 10 min read
Jake Page
Developer Relations Engineer

It’s well-established that Discord is a great platform for Developer communities. What’s less established are clear, best practices on how to configure a server from scratch to best serve a community of devs. If you are a community manager or Discord moderator, this blog post aims to give you the definitive guide to getting a working server that will feel welcoming, resourceful, and intuitive for all your community members.

Configuring a top-tier server is not difficult at all, the Glasskube server is an example of a “less is more” approach. Having said that, we will explore some additional intermediate and advanced practices that might make sense for some use cases. Let’s not waste any more time and jump straight in.

1. Don't Reinvent the Wheel 🛞

As developers we spend a large amount of time working on challenging tasks and solving hard problems, Discord can be complex and a bit daunting as a beginner to the platform, but if you take away anything from this blog post it should be that you do not need to over-engineer your server for it to be highly effective.

Any community platform should have the following ingredients:

  • Clear lines of communication
  • Clearly document known or past bugs
  • Easy to navigate
  • Relevant and customizable to each community member
  • Safe from Bot attacks or raids
  • And if it’s fun, even better

Discord as a product has evolved immensely in the last few years allowing community managers to easily adapt the platform to the needs of their ecosystem.

Focus on applying some of the tips in this blog post to build an MVS (minimum viable server), there will always be time to pivot and add fancy features down the road. Let’s take each point one by one.

2. Establish Clear Lines of Communication 🗣️

Before creating your first channel, think to yourself, what brings a user to your server? Whether it’s product updates, open-source development, or job searching. Make sure those as the main channel lanes.

It’s always good to have a #general, catch-all channel and then a handful of other channels that might guide server members to more targeted conversations around troubleshooting bugs, asking for help, or even having off-topic conversations. If you see the need, consider dividing your channels into categories to give further context.

When a new member joins an overly complicated and cluttered server, it can be daunting to engage and integrate into the community. “Where do I even start?” - Me on most servers.

Simplifying the structure by focusing solely on essential channels, categories, roles, and resources is crucial. This approach creates a welcoming environment where newcomers can easily navigate and become active participants in the community.

3. Are you Into Role-Play? 📛

Nah, me neither, but they are useful on Discord. Roles are a great way to understand the different user profiles that make up your community and to assign custom permissions.

Most new members are shy and you might not want to force them to introduce themselves when they join. A good way around this is by assigning roles by asking onboarding questions. We will see how to do that in a bit.

Also, not every community member might have the same interests, roles can be used as a filtering system to direct the right people to the appropriate channels.

On the Glasskube Discord server, all members have access to all channels but in the intermediate steps, I’ll show you how to unlock channels based on different roles.

Glasskube roles

💡 Each Discord server has the default @everyone role. Use the principle of least privilege when configuring this role. Allow @everyone to view and interact in text channels and voice channels, but make sure no actions can be taken upon other members nor any management permission given either. To add permissions to users, create roles and attach the roles to the user directly.

4. Enable the Community Feature ✅

If you’ve set up Discord servers in the past you more than likely used bots like “carl” bot for onboarding, role assignments, and moderation. No need for that now, let the Community feature take care of that for you. This feature does 80% of the heavy lifting for you as a Discord Community Manager by combining security, member verification, and onboarding all in one. Just follow the instructions to set up:

1️⃣ Onboarding questions 2️⃣ Server guide 3️⃣ Safety guidelines

💡 To enable the community server feature, click on your Server name at the top right > Server settings > Community Overview > Activate.

By enabling the Community feature you unblock additional channel types such as forums, stages, and announcements.

5. Have a Short but Effective Onboarding Process 👋

An onboarding process should serve two major functions, first of all, to get to know new members better, and second to let members know what they can find on your server. Customize the onboarding questions and answers to your liking, and assign roles or even channels to the user depending on the answer given. Here are the two questions we ask new Glasskube community members.

Onboarding questions

6. Structured Help and Support Forums 🆘

Don’t let questions asked in your community go to waste. Persist them in a centralized place so newcomers can learn from others’ past questions. The best way to do so is by using channel Forums.

Forum channel

They act as a useful supplement to the official project documentation. Many OSS software projects struggle to keep their documentation up to date and here is where the forums can lend a hand, by documenting and persisting conversations revolving around troubleshooting efforts. If new members pose questions that have already been answered in a forum, send the forum thread instead of resolving the same issue twice.

Check out the questions forum on the Wasp discord server, they are a great example of neatly, well-tagged questions that are a huge help to community members old and new.

Wasp Discord help forum

💡 When setting up your forum section create useful and relevant tags and enforce their usage on each question so they can be easily filtered and contextualized when needed.

7. Keep the Announcements Coming 🎉

As a vibrant OSS project, you are probably releasing as much as possible and sharing community-relevant topics regularly. Make sure to have at least one Announcement channel and keep it up to date.

💡 Announcement channels, different from other channels can be subscribed to and viewed from outside your server. If you want to push updates to your channel followers make sure to click the “Share with followers! Publish” button once an announcement is shared.

Announcement channels accept webhook integrations making YouTube videos, live Twitch streams or Canny roadmap updates appear automatically.

8. How to Avoid Raiding, Spam, and Nukes ⚠️

We have all seen spam and sometimes inappropriate messages and links to crypto scams on Discord servers before. Hopefully none of you will ever have to see a fully wiped server that suffered from a nuke attack. In the past, you would lean on the healthy ecosystem of Discord bots which many of them had a generous free tier that would secure your server to a pretty high level. Now, those third-party safety bots are just not needed, since Discord add many layers of Raid and Spam protection as well as some AutoModerator functions and easy to congure setting which you can set once and forget. Once configured, Discord in the background with scan and vet each message, attachment, and new member as they join.

Safety setup

💡 In DM and Spam protection, you can choose the verification level. I like to set it to Medium which will only verify a member once they are part of the server for over 5 minutes. Therefore, weeding out potential bot traffic.

9. Adding Fun with Emojis and Stickers 🤣

It’s important to not be so serious and enjoy yourself too. Make sure to provide some inbuilt stickers and emojis that your community can relate to and use to express themselves.

Find some cool stickers here: https://stickers.gg/ Download enojis here: https://emoji.gg/

You can find the emoji and sticker settings in the Server settings section also.

Sticker settings

What the Glasskube server looks like now, join us! 🧊

Having put all the tips mentioned above in practice this is what our Discord server looks like. If you feel like checking it out or becoming part of the community join us here.

Current server

10. Let’s Talk Intermediate and Advanced features 🤓

All of that seemed pretty straightforward, right? In case you are looking to get fancy, let’s explore a couple of intermediate and advanced features.

💡 Discord has a subscription plan which uses Nitro as currency, Nitro can be bought with fiat currency. By buying boosts you can unlock many features and add-ons, mainly cosmetic and image quality-related, but feel free to check them out.

Discord boosts

Intermediate

It might be the case that over time your server grows and so do the number of channels. Since a large number of available channels can be disorientating for new members you can allow members to opt-in through additional onboarding questions.

💡 Note that even if you don’t answer the questions during onboarding you can always click on Channels and Roles in the top left-hand corner of the server to answer any onboarding questions to gain access to any locked channels.

To get started, navigate to Server Settings> Community Onboarding > Default channels, and only select the channels you want all members to see.

Intermediate onboarding

Then edit the onboarding questions and unlock channels depending on the answer by adding the channel to part 2 Assign channels and/or roles

Unlock channels

Advanced

Similarly, if you have a growing server with multiple announcement channels that you want to give granular access to. For example, if a user with the @contributor role only wants Glasskubee updates and not general Kubernetes updates you can gain this level of granularity by switching to Advanced mode in the Onboarding section of the Server settings page.

Slowmode

You can also be granular about the amount of time is needed for a new member to send a message in a particular channel by editing the Slowmode setting, under channel settings.

Let’s Wrap It Up

A community platform is a place that should be conducive to creativity, comradery, and collaboration. Of course, some rules and guidelines should be in place to keep the place welcoming and inclusive to all, but all in all the key takeaway is to not overthink or over-engineer your server. Decide on some key roles, and key channels and resolve people's issues in a centralized way with answers to questions easy to find and hopefully don’t always depend on your input.

A community is made up of individual connections to try to focus more on initiatives that will lead to open conversation and always try to acknowledge key community members when they deserve it.

Get involved

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated. Let us know what you think, we would love to hear from you or support us by leaving a star on GitHub:

glasskube/glasskube

Glasskube v0.1.0 — Introducing Dependency Management

· 3 min read
Jake Page
Developer Relations Engineer

Glasskube v0.1.0 was released on March 21st, introducing new features like Dependency Management and Dark Mode as well as many useful features for an improved CLI and GUI experience.

Glasskube is fully open-source. Support us by leaving a star: glasskube/glasskube

🙏 Special thanks to all our contributors 🥰

Once again, we can't thank our community enough for their valuable input and exciting contributions to Glasskube. We are happy you choose to be part of our journey in making Kubernetes package management easier for everyone.

This release includes:

  • 👥 a total of 10 contributors
  • 🛠️ 53 commits
  • 💥 no breaking changes

Watch our release video to get an overview of what has changed:

Most notable changes

Dependency management 🔗

Building on the package installation features shipped in the previous weeks, we now offer an in-built way of managing and installing the dependencies used by your desired package. Now package maintainers can define the appropriate dependencies, for each Glasskube supported package as well as recommending the range of suitable dependency versions, this way ensuring that packages are always compatible to accompanying dependency.

Package dependencies will show on the installation drop down in the GUI. They will also be shown when installing a package via the CLI.

Dark Mode 🕶️

Great news, we shipped the "must-have" feature any OSS project can't survive without, Dark Mode. Glasskube's dark mode is linked to the display mode defined on your local system. Access your system preferences menu and try it out!

Dark Mode

Further improvements

We also worked hard on improving existing commands and our GUI. Here's a list of further notable changes:

  • The --latest flag was added to the glasskube bootstrap command to ensure the latest version of the package controller is being used.
  • The GUI now reflects the available dependencies for selected packages.
  • We expanded the describe command to include the installed dependencies.
  • You will now be greeted by a notification pop-up if "open" fails.
  • Version mismatch detection was added to the package controller.

BREAKING changes

This release does not contain any breaking changes.

All Release Notes

The release notes can be found here: v0.1.0 release on GitHub

All changes can be found here: Comparing v0.0.4 to v0.1.0

How to upgrade

Follow the installation instructions below to download the latest version of the Glasskube client. After that you need to upgrade the server component (Package Operator) by bootstrapping Glasskube again:

glasskube bootstrap --latest

Getting started

Follow our Getting Started guide if you want to try Glasskube for yourself and install your first package.

On macOS, you can use Homebrew to install and update Glasskube.

brew install glasskube/tap/glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Get involved

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated. Let us know what you think, we would love to hear from you or support us by leaving a star on GitHub:

glasskube/glasskube

Glasskube v0.0.3 — Introducing Package Updates

· 4 min read
Philip Miglinci
Co-Founder

Glasskube v0.0.3 was released on February 27th, introducing package updates and many useful features for improved CLI and GUI experience.

Glasskube is fully open-source. Support us by leaving a star: glasskube/glasskube

🙏 Special thanks to all our contributors 🥰

Once again, we can't thank our community enough for their valuable input and exciting contributions to Glasskube. We are happy you choose to be part of our journey in making Kubernetes package management easier for everyone.

This release includes:

  • 👥 a total of 10 contributors
  • 🛠️ 64 commits
  • 💥 no breaking changes

Watch our release video to get an overview of what has changed:

Most notable changes

Package Updates

Updating packages is one of the most essential features of any package manager. That's why most of our efforts in the past two weeks have gone into the support for such updates via CLI and GUI. It's as easy as typing glasskube update into the command line, or a button click in the GUI.

During package installation you now can decide whether you want automatic updates for the package, in which case the Glasskube package operator will take care of keeping you up to date at all times. You can of course opt out of this feature if you prefer to handle updates manually. Apart from that, with the --version flag you can choose which version of a package is to be installed, if your use case requires a specific version.

Package Updates

For technical details, please have a look at the package operator documentation.

Further improvements

We also worked hard on improving existing commands and our GUI. Here's a list of further notable changes:

  • The glasskube describe command – and its GUI-complement, the package detail page – have been implemented for you to have a more detailed view on each of the packages available in Glasskube.
  • glasskube list has been extended with the new flags --outdated – listing only outdated packages, and --show-latest – showing the latest available version for each package.
  • All commands check for a newer version of Glasskube, and notify you if you are not up to date anymore.
  • Glasskube is now even easier to set up: The GUI comes with handy pages for selecting a kubeconfig and for bootstrapping Glasskube in a cluster. All CLI commands will also support you in setting up Glasskube in your cluster.
  • Streaming any kind of package status change directly into the GUI, making it easier for you to recognize when something is happening in the background.

BREAKING changes

This release does not contain any breaking changes.

All Release Notes

The release notes can be found here: v0.0.3 release on GitHub

All changes can be found here: Comparing v0.0.2 to v0.0.3

How to upgrade

Follow the installation instructions below to download the latest version of the Glasskube client. After that you need to upgrade the server component (Package Operator) by bootstrapping Glasskube again:

glasskube bootstrap

Getting started

Follow our Getting Started guide if you want to try Glasskube for yourself and install your first package.

On macOS, you can use Homebrew to install and update Glasskube.

brew install glasskube/tap/glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Get involved

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated. Let us know what you think, we would love to hear from you or support us by leaving a star on GitHub:

glasskube/glasskube

The Inner Workings of Kubernetes Management Frontends — A Software Engineer’s Perspective

· 11 min read
Christoph Enne
Software Engineer

In this blogpost we are reviewing Kubernetes Management Frontends and discuss how these tools are being built.

The rise of Kubernetes in recent years has led to an astonishing number of open-source Kubernetes management tools seemingly appearing out of nowhere. The goal of the research leading to this article was to merely understand the architecture of some of these tools and to subsequently provide a brief overview and options for developers trying to get started with their own Kubernetes frontend. We will not dive deep into the actual tools and what problems they are trying to solve, but instead focus on the software engineering aspect. We are also exclusively exploring open-source and self-hosted tools and leaving the PaaS/IaaS platforms of cloud providers aside — that would be a whole different article.

Setting up and interacting with your first cluster can be overwhelming. Just like me, you might have come across the infamous kubernetes/dashboard, followed the installation instructions, and asked yourself: "What did I just do and why exactly does this work the way it works?" And after some tinkering with your cluster, you might have installed even more external tools that help you with some specific aspects of cluster management, providing you with either a CLI or a Web UI.

As a software engineer mostly engaged in web development in recent years, I was curious about how these kinds of tools are built and deployed.

Let's first clarify some of the basics needed for the following exploration of different Kubernetes UIs. After that, we will see what they have in common and what makes this kind of software special, to finally form a recommendation of how one could build a Kubernetes Web UI themselves.

Kubernetes Basics

The official documentation is more than helpful anyway; there is just one important thing to remember: Whenever and wherever you interact with your cluster, you do it via the Kubernetes API — this holds true at least for the scope of this article, though there might be other use cases.

As a consumer of this API, one needs to know where it is hosted and how to authenticate against it. The Kubernetes API can be accessed both from inside a cluster (i.e., from an application running on a pod) and outside a cluster (e.g., from your command line). In some cases however, the API is only available from within a VPN.

Since we are looking at tools with a web UI, this UI and its backend need to be exposed such that a user can access it. The options are:

Alternatively, the web server could be running on the local machine of a user as well, in which case one doesn't need to worry about these options. However, a user needs to have a valid kube config on their machine for any of these approaches to work.

Management Frontends

Now, let's take a look at some commonly used frontends and how they are built.

kubernetes-dashboard

The Kubernetes Dashboard is a popular Web UI used to view and manage all kinds of Kubernetes resources within a cluster. In the latest stable version 2.7, both the backend and frontend are part of the same container. The Go backend serves both the API and the Angular UI assets. This deployment strategy requires users to use kubectl proxy to access the web application.

In the newer 3.0 version, which is still in alpha, the deployment strategy has changed: both the backend and frontend are each running in a dedicated container. Therefore, accessing it via kubectl proxy no longer works because the UI needs to access the backend, which is running on a different pod and port. The port-forwarding approach described here should be used instead.

ArgoCD

ArgoCD is a GitOps continuous delivery tool for Kubernetes. It comes with several components, including its own API server and a web UI. All the backend components are written in Go, and the UI is a React application.

As with the Kubernetes Dashboard, the server (including the UI assets) is deployed inside the cluster, making it necessary for the user to perform port-forwarding or use a LoadBalancer. This is described in their documentation.

Lens

Lens is a Desktop UI, but still interesting for our exploration. It is being developed with Electron, React, and Typescript. The Lens App uses the Typescript Kubernetes client to connect to a cluster, and since the Desktop app is clearly running outside a cluster, it uses a locally provided kubeconfig to connect to it.

glasskube

Yes, a pretty shameless plug (I work there), but it's also an interesting alternative to consider. For the UI of the Glasskube package manager, we spin up the web server locally via a CLI command and serve the UI assets from there. We decided to go this route because it simply makes more sense in our use case. Whenever the user needs the Glasskube UI, they host it themselves for as long or as short as they want — there is no need to have it running 24/7 inside the cluster.

Findings

Many open-source Kubernetes management UIs are coded in a similar way — with a Go backend utilizing the powerful Kubernetes-go client, and a Single Page Application in JavaScript as the frontend. In most cases, the web assets (e.g., JS files) are served together with the backend, meaning one container serves both the backend and frontend. It was actually difficult to find something that is not built like that.

Inside cluster vs. Out of cluster

When it comes to deploying such a web tool, there are only two options:

  • The webserver is deployed on a pod inside the cluster and is accessible either via proxy, port-forwarding, or ingress.
  • The webserver is deployed outside the cluster, directly (locally) on the users' machine.

The Kubernetes clients (e.g., Go client) support developers with both methods to connect to a cluster, as we can see in the following examples.

The piece of code it all comes down to:

These simplified examples are heavily based on the official examples seen here and here.

Let's have a look at how to connect to the Kubernetes API when running the application inside the cluster:

import (
"context"

metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/client-go/kubernetes"
"k8s.io/client-go/rest"
)

func main() {
// retreive the config for the cluster we are currently in:
config, err := rest.InClusterConfig()
if err != nil {
panic(err.Error())
}

// create the clientset for this config:
clientset, err := kubernetes.NewForConfig(config)
if err != nil {
panic(err.Error())
}

// do something with the clientset, e.g. getting all pods in the cluster:
// pods, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{})
}

The Go client implementation uses the pod's service account and the environment variables KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT to identify which cluster it is placed in. Subsequently, it creates the REST config object, with which the clientset can be obtained.

Similarly, when running outside the cluster, one needs to create the config object, but this config is read from the local kube config:

import (
"context"
"flag"
"path/filepath"

metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/client-go/kubernetes"
"k8s.io/client-go/tools/clientcmd"
"k8s.io/client-go/util/homedir"
)

func main() {
// get the passed (or default) kube config file path
var kubeconfig *string
if home := homedir.HomeDir(); home != "" {
kubeconfig = flag.String("kubeconfig", filepath.Join(home, ".kube", "config"), "(optional) absolute path to the kubeconfig file")
} else {
kubeconfig = flag.String("kubeconfig", "", "absolute path to the kubeconfig file")
}
flag.Parse()

config, err := clientcmd.BuildConfigFromFlags("", *kubeconfig)
if err != nil {
panic(err.Error())
}

clientset, err := kubernetes.NewForConfig(config)
if err != nil {
panic(err.Error())
}

// do something with the clientset, e.g. getting all pods in the cluster:
// pods, err := clientset.CoreV1().Pods("").List(context.TODO(), metav1.ListOptions{})
}

Again, the Kubernetes Go client has us covered with a simple function to parse a kubeconfig file to get a config, which can then be used to create a clientset.

When trying to run these simple examples, you will also come across one difference between these two approaches: Running the local tool is easier because you don't need to build an image, push it to a registry, and then pull it into the cluster.

Which one to choose?

Say you were to build your own Kubernetes UI in a similar fashion. When it comes to the decision of where the webserver of your tool should run, there are several things to consider:

  • Distribution: Running your tool inside the cluster means you have to build and distribute a docker image. On the contrary, you will have to distribute a native binary if you want users to install it on their machines. For both cases, there are lots of tools and resources online.
  • Availability: When your cluster is down for whatever reason, users might not be able to reach the tool hosted inside the cluster. This leads us to the next point:
  • Onboarding User Experience: This might be an edge case, but a locally hosted web tool is available before all of its components are installed in the cluster. This means you could implement some sort of UI onboarding flow for new users, making the tool easier to install and set up.
  • Compatibility: Multiple users of the same cluster could have different versions of your (locally hosted) tool installed. This can not happen if there is just one webserver running inside the cluster.
  • Persistence: When needing to store tool-specific data (i.e., non-Kubernetes resources), you could store it inside the cluster (e.g., in a ConfigMap). For the locally deployed variant, you could additionally store user-specific data like settings on the users' machine. This decision is highly use case dependent.
  • Developer Experience: There seems to be no significant difference, but it is worth noting that when developing an in-cluster webserver, during development this server still needs to support the out-of-cluster config approach somehow. Otherwise, one would have to build and deploy an image into the cluster after every change.

Eventually, whether the tool is deployed inside or outside of the cluster is completely up to you, but it's always important to consider the use cases and be aware of the context in which it is used. You can also opt for providing both options to your users.

For us at Glasskube, it was clear that we want to provide an easy-to-use interface for new users (especially those new to the Kubernetes world), who might not have yet set up all the Glasskube cluster components. These users can be supported by having a CLI command hosting the local webserver with a supportive Web UI.

Conclusion

In this article, we have explored a few Kubernetes tools offering a web UI and analyzed the web aspect of those tools from a software engineer's point of view. There is clearly no ultimate one-size-fits-all solution for how to design and develop such tools, but the list above hopefully gives some hints in the right direction. As always in software engineering: It depends.

One more plug: I work at Glasskube, where we are building the missing Kubernetes package manager. If you are interested in our work, make sure to star us: glasskube/glasskube. We are also working on an article shedding some light on different CLI frameworks, if you are more of a command line person. And if that's not enough, we might write about using htmx soon because it's trending, and we need your attention. I can already see the headline: "How we reduce our codebase by 95% by using seemingly old-school technology" — I think this has not been done before ;)

Glasskube v0.0.2 — Open Command

· 3 min read
Philip Miglinci
Co-Founder

Glasskube v0.0.2 was released on February 9th, just 9 days after initial technical preview release.

Glasskube is fully open-source. Support us by leaving a star: glasskube/glasskube

🙏 Special thanks to all our contributors 🥰

We didn't anticipate rolling out our second preview release just one week after the initial one, but thanks to the remarkable contributions from our community, that's exactly what we've done.

This release includes:

  • 👥 a total of 14 (mostly new) contributors
  • 🛠️ 58 commits
  • 💥 no breaking changes

Watch our release video to get an overview of what has changed:

Most notable changes

Of all changes, bugfixes and improvements, two new features stand out in the second release:

The open command

Introducing Glasskube's newest feature: the open command! Gone are the days of laboriously setting up multiple TCP tunnels with kubectl port-forward just to access specific services. With Glasskube, accessing your desired services is now as easy as a click or a simple command. Say goodbye to unnecessary complexity and hello to effortless convenience.

Realtime updates with htmx

The second-biggest achievement of this release: The integration of htmx for real-time updates. This advanced feature enables automatic and instantaneous updates to your graphical user interface, eliminating the need for manual page refreshes. With htmx, your application stays dynamically synchronized with backend changes, ensuring a seamless and responsive user experience.

BREAKING changes

This release does not contain any breaking changes.

All Release Notes

The release notes can be found here: v0.0.2 release on GitHub

All changes can be found here: Comparing v0.0.1 to v0.0.2

How to upgrade

Follow the installation instructions below to download the latest version of the Glasskube client. After that you need to upgrade the server component (Package Operator) by bootstrapping Glasskube again:

glasskube bootstrap

Getting started

Follow our Getting Started guide if you want to try Glasskube for yourself and install your first package.

On macOS, you can use Homebrew to install and update Glasskube.

brew install glasskube/tap/glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Get involved

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated. Let us know what you think, we would love to hear from you or support us by leaving a star on GitHub:

glasskube/glasskube

Glasskube is now part of the CNCF Landscape

· 3 min read
Philip Miglinci
Co-Founder

🧊 Glasskube is the next generation Package Manager for Kubernetes 📦

Featuring a GUI and a CLI. Glasskube packages are dependency aware, GitOps ready and can get automatic updates via a central public package repository.

Support us by leaving a star on GitHub: glasskube/glasskube

We got accepted into the CNCF Landscape

Glasskube is now visible next other relevant projects in the cloud native ecosystem landscape like Helm or Backstage.

Glasskube CNCF Landscape

The goal of the cloud-native landscape is to gather and categorize projects that are relevant to the cloud native developers, offering a comprehensive overview of the existing ecosystem.

By exploring this landscape, project teams can make informed decisions about tooling, technology stack selection, and best practices. Moreover, it facilitates access to emerging innovations, fosters community collaboration, and ensures compatibility and interoperability, all of which are critical for the success of Kubernetes deployments.

Glasskube is part of the Application Definition & Image Build category

Application definition and image build tools encompass developer-focused and operations-focused functionalities, aiming to simplify Kubernetes deployment and app management. They address challenges of complexity in containerized environments, offering solutions for reproducible image creation, standardized app deployment, and simplifying developer and operator experiences. Tools include Helm for deploying third-party apps, the Operator Framework for building and deploying operators, and Cloud Native Buildpacks for containerizing application code. These tools help streamline Kubernetes development and operations, offering diverse solutions for various use cases.

Accepted in just 7 days after the launch

The pull request #3735 got accepted just 7 days after the released of our first technical preview of Glasskube.

Glasskube was accepted into the CNCF landscape category due to its ability to effectively address the critical challenges within application definition and image build, underscoring its importance in streamlining Package Management on Kubernetes.

View Glasskube in the CNCF Landscape

Glasskubes entry in the CNCF landscape

Try out Glasskube yourself

You can already get your hands on Glasskube and install the first available packages. You can find the correct installation instruction for your operating system:

On macOS, you can use Homebrew to install and update Glasskube.

brew install glasskube/tap/glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Get involved

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated.

Let us know what you think, we would love to hear from you or support us by leaving a star:

glasskube/glasskube

Glasskube v0.0.1 — Technical Preview

· 5 min read
Philip Miglinci
Co-Founder
Louis Weston
Co-Founder

The aim of this post is to share our technical preview of how a cloud native package manager could work and what challenges need to be solved.

Glasskube is fully open-source. Support us by leaving a star: glasskube/glasskube

Introducing Glasskube — The next generation Package Manager For Kubernetes

Glasskube GUI Mockup

Package Management on Kubernetes is one of the most pressing issues in the Cloud Native community. A concept which is widely known from other ecosystems like desktop and mobile computing has yet not been realized for cloud computing. For example on Android and iOS, millions of developers publish their packages in the Play Store or App Store to reach their users. The package manager also makes sure all users receive the latest version published by the developer and the developer receives crash reports and user feedback as a return to improve their applications, but as a cloud native developer there is no package manager you can rely on — yet.

Our first release (v0.0.1) already features a working prototype that can install basic packages, but a lot of challenges still need to be solved.

A cloud native architecture

Glasskube itself is designed as a cloud native application. Featuring an easy to install client that comes with a graphical user interface and autocompletion for your favorite shell.

At the heart of the Glasskube package ecosystem lies our central package registry which holds the package manifests. In a future version we also plan to support 3rd party registries and the possibility to use multiple registries in a cluster.

The Glasskube package operator syncs the latest manifest into the cluster and makes sure it will be updated as soon as a new manifest is available.

Challenges that need to be solved

We already covered some our upcoming features in our public roadmap, but I would also like to take this opportunity to shortly speak about broader challenges.

Kubernetes version compatibility

Kubernetes releases minor versions every 4 months, which often come with new API versions. Package authors need to adapt their packages to these changes. In Kubernetes, a particular release might include more than one API version of a resource, so that packages can be compatible with a broader range of Kubernetes versions. These compatible versions are often only documented in the package distributors' changelog. Glasskube aims to incorporate this kind of metadata in combination with automatic checks from tools like kube-no-trouble or Pluto.

The user should not be required to drudgingly check all packages for compatibility and package developers should get feedback if their package is not compatible with the latest API versions.

Package dependencies

Cloud native applications often interoperate and there are some packages that can be found in almost every Kubernetes cluster. For example: cert-manager, Ingress controllers or database operators. Due to the lack of a package manager and ecosystem these dependencies are still often only documented in the Getting started section of an application.

In an ideal world a package author could simply specify a dependency of their package and the package manager ensures that all these prerequisites are fulfilled.

Testing

In order to support multiple Kubernetes versions, dependencies and packages Glasskube needs to build massive automated testing infrastructure for all packages in its central package registry.

Feedback and package quality

As seen in other package managers like the arch user repository or the Play Store and App Store users' feedback and reviews help other users to decide between different packages. Also, application developer will incorporate users' feedback to gain popularity and better ratings in the package manager.

Glasskube and Helm

Glasskube is no replacement for Helm. Helm has its strengths in configuring releases through templating and having the ability to perform upgrades and rollbacks.

Glasskube is laser focused on the administrator who needs to only install and kustomize (pun intended 😉) a single application, but who also needs to make sure multiple packages are kept up-to-date and secure throughout multiple Kubernetes version upgrades and adapting to inevitable breaking changes.

Getting started

Follow our Getting Started guide if you want to try Glasskube for yourself and install your first package.

On macOS, you can use Homebrew to install and update Glasskube.

brew install glasskube/tap/glasskube

After installing Glasskube on your local machine, make sure to install the necessary components in your Kubernetes cluster by running glasskube bootstrap. For more information, check out our bootstrap guide.

Release Notes

All release notes can be found on GitHub: https://github.com/glasskube/glasskube/releases/tag/v0.0.1

Release Video

Get involved

The easiest way to get involved is to tackle one of our open issues. You are also welcome to join our Discord.

If you are a cloud native developer, please submit your package.

As Glasskube is still in its very early days, your feedback is highly appreciated.

Let us know what you think, we would love to hear from you or support us by leaving a star: glasskube/glasskube