In October 2022, we’ve decided to create a unique brand and website for Enabler that aligns with our values. At that time, we've been using Squarespace for just a basic website with information about the company.  So in October we’ve got in contact with absolutely brilliant designers that helped us create new brand for Enabler.

So, to create a brand new website design, we've collaborated with great designers from Poland: 

, specialised in Design Systems and Artur is 

. Both of them have many years of experience, and after the first meeting, we were sure that they are the ones that we want to work with for the next few months. 

So we started having workshops led by Matt to find out what our values, goals, and purpose are behind what we do. After a couple of workshops, conversations, and feedback, Matt provided us with the Brand Guidelines and Brand Elements that were ready for us to use. The Brand Guidelines provide information about colors, typography, and logo while the Brand Elements consist of social media profile pictures, cover images, email footers, resume templates, desktop background images, and more.

And once our brand was ready the next step was to create a new website for Enabler. After a few meetings with Artur, he understood the kind of website we wanted and created a beautiful design that incorporated our new fonts, colors and logo. 

The entire branding process took about three months. Our developer, Dominika, then took over and began implementing the new design on the website.

It was important for us to create a responsive and fast website using modern technologies. Here are the technologies we used to create the website:

 is powerful framework for building performant, scalable and maintainable web applications. It allows us to generate static HTML files at build time, which improves our site's performance and reduce hosting costs. It makes the website much quicker, comparing to other solutions.

It has a great solution for optimizing images for different devices and screen sizes, it provides lazy loading to improve page load times, priority image loading to prioritise the loading of important images on the page, ensuring that they load as quick as possible and provide better user experience.

Another important solution is font loading optimization library, next/fonts, that improves the performance and usability of webpage by optimizing the way fonts are loaded and rendered.

, because it helped us develop our webpage faster, using pre-defined utility classes, that we used to quickly apply styles to HTML. We can easily customize these classes by adding our own colors, fonts, and other to the Tailwind config. This allowed us to create a unique design for our website.

Tailwind CSS also supports styling any vanilla HTML that we cannot control, such as content from articles pulled from CMS. We used the @tailwindcss/typography plugin, which provides a set of prose classes that we can use to add default styles for headings, blockquotes, links, etc.

Tailwind CSS makes it easy to maintain a consistent, responsive design and user experience throughout website.

 is a headless CMS (Content Management System) that we used on our website. It allows us to define custom data models, so our data is organized the way we want, making it easy to work with. One of the dependencies we used is @sanity/image-url, which we used to obtain any crops or hotspots used in the Sanity content. We can specify the width and height to get a cropped and resized image according to the wishes of the content editor. We can also specify the format or quality to obtain the most optimized images.

Next/image combined with @sanity/image-url:

 to create unique images on our website. 

 is a generative artificial intelligence program and service created and hosted by Midjourney, Inc., an independent research lab based in San Francisco. Midjourney generates images from natural language descriptions, which are called "prompts."

We are very pleased with the outcome. Hopefully, you will like our new webpages and profile as much as we do!

Process of creating enabler.no and the technology we used.

How did we create enabler.no?

Venturing into the world of deploying an MQTT broker in Kubernetes can lead you to some intriguing challenges, especially when compared to the more traditional tasks of serving webpages or APIs

Unlike HTTP-based services, MQTT is served over TCP. Consequently, some common ingress solutions, such as ingress-nginx, do not natively support serving TCP traffic. We'll explore how we could bypass this limitation.


Ensuring secure communication between the MQTT broker and clients is crucial. However, manually creating and managing SSL certificates can be a tedious process. We'll demonstrate an automated method for managing SSL certificates, making your MQTT communication secure and worry-free

First things first, let's generate the certificate we want to use. The "de facto standard" for this task is cert-manager, and we'll use a cert-manager-generated certificate in the same way we do with other ingress-generated certificates. This ensures the certificate stays up-to-date.

As long as your DNS points to the Ingress controller's load balancer for the specified host making it possible for cert-manager to validate your host, you should have a secret containing the certificate in your cluster.

Now, it's time to deploy an MQTT broker. Although we often prefer cloud-native brokers like EMQX, we've opted for Mosquitto in this example due to its simplicity.

We'll refer to the generated secret when specifying the certificate location in the config. 


Keep in mind that the example above allows anonymous access to the broker. In a production environment, you'll need to secure your endpoint with an ACL, password list, or similar method and disable anonymous access.

After deploying the components mentioned above, you should have a working MQTT broker with a certificate securing it. However, it's not yet accessible from outside since TCP traffic isn't routed by ingress-nginx.

To overcome this, we can leverage a lesser-known feature in ingress-nginx that allows routing specific ports to TCP services within the cluster. Note that we're not using any host headers here, so any request to any host pointing to the ingress service will be routed on the specified port.

https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/

To do this we will use a configmap called tcp-services to keep track of routed ports.

The last part is to tell ingess-nginx to read the configmap and allow port 8883 into to load balancer. 


Add port 8883 to the ingress load balancer ports. 

Assuming you have a service named "mosquitto-mqtts" in the "mosquitto" namespace, this should route the port to the broker. Now, you're all set with a fully functioning Mosquitto MQTT broker with encrypted communication in Kubernetes. Enjoy!

Secured with TLS

Mosquitto MQTT broker in Kubernetes

Is it necessary for your Kubernetes API to be publicly exposed to the internet? From our observations, the Kubernetes API is frequently accessible online due to using default settings when creating a cluster or because there were limited options at for making it private at the time the cluster was created. While you still need the appropriate credentials to access it, it's important to evaluate if public availability is truly required.


I recently discovered that this topic is also covered in OWASP's Kubernetes Security Cheat Sheet. The cheat sheet provides valuable insights and guidelines for enhancing the security of your Kubernetes environment. 

At the moment there are two primary methods for restricting access to the Kubernetes API server in Azure Kubernetes Services:

https://learn.microsoft.com/en-us/azure/aks/api-server-authorized-ip-ranges

Microsoft recommends this approach as a simple solution for limiting access to the API.

https://learn.microsoft.com/en-us/azure/aks/private-clusters

This option involves creating a private network in Azure, where your cluster is placed. Although it introduces additional complexity, it also offers benefits such as allowing Kubernetes to communicate internally with other resources within the same private network.

It is crucial to assess the available alternatives and make an informed decision.

Each use case is unique, and a publicly accessible cluster might be entirely acceptable. However, it is crucial to assess the available alternatives and make an informed decision.

Evaluating AKS Public Exposure

Securing Your Kubernetes API

Her ønsker vi å dykke ned i teamer som vi brenner for, som for eksempel DevOps, cloud native teknologier og bedriftsutvikling.