We appreciate the Cloud Native Computing Foundation's definition of cloud native:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

https://github.com/cncf/toc/blob/main/DEFINITION.md

Crucially, cloud native doesn't exclusively force you to running applications on Azure, AWS, or Google Cloud. It can be implemented using private infrastructure or, more commonly, a hybrid solution combining private and public cloud resources.

As your partner, we can ensure that the applications you develop and the infrastructure you deploy are "cloud native compliant."

Vi omfavner prinsippene for cloud native teknologi i både våre utviklingsprosesser og plattformarkitektur. Ved å ta i bruk disse prinsippene, har vi som mål å bygge og administrere applikasjoner som er skalerbare, robuste og svært effektive.

Vi verdsetter Cloud Native Computing Foundation sin definisjon av cloud native:

Viktigst av alt tvinger ikke cloud native deg til å utelukkende kjøre applikasjoner på Azure, AWS eller Google Cloud. Det kan implementeres ved hjelp av privat infrastruktur eller, mer vanlig, en hybrid løsning som kombinerer private og offentlige skyressurser.

Som din partner kan vi sørge for at applikasjonene du utvikler og infrastrukturen du bygger er "cloud native-kompatible."

Cloud native

At Enabler, we view Kubernetes as a great platform for running and deploying workloads at scale.

However, we also recognize that Kubernetes may not be the best solution for every situation. Before deciding to adopt Kubernetes, you should resonate with at least some of the following statements:

How many elements are required for the deployment of your application infrastructure?

How many developers does your team consist of?

Do you need to orchestrate external dependencies, such as DNS, databases or storage?

Is your team prepared to adopt new methodologies and tools within the development process?

We firmly believe that containers have revolutionized the way software is built and run

We firmly believe that containers have revolutionized the way software is built and run. However, it's crucial to acknowledge that there are numerous other, simpler alternatives to Kubernetes for orchestrating your containers.

Establishing a Kubernetes cluster is just one aspect of the process. Before setting up the cluster, you must consider network design and hosting options. Once the cluster is in place, you'll need to assemble the components required to create an exceptional platform for developers.

Our preferred technology stack currently includes:

FluxCD: For GitOps-based continuous delivery and deployment

Cert-manager: To generate and renew TLS certificates from providers like Letsencrypt

Prometheus: For collecting and processing metrics

If you're uncertain whether Kubernetes is the right fit or if you've already embarked on the Kubernetes journey, Enablers can help determine and implement the most suitable solution for your needs.

Kubernetes er en open-source plattform for konteinerorkestrering som automatiserer utrulling, skalering og administrasjon av konteinerbaserte applikasjoner.

I Enabler anser vi Kubernetes som en utmerket plattform for å kjøre og distribuere workloads i stor skala.

Imidlertid erkjenner vi også at Kubernetes kanskje ikke er den beste løsningen for enhver situasjon. Før du bestemmer deg for å adoptere Kubernetes, bør du kunne identifisere deg med enkelte av uttalelsene under:

Hvor mange elementer kreves for utrullingen av din applikasjonsinfrastruktur?

Hvor mange utviklere består teamet ditt av?

Trenger du å orkestrere eksterne avhengigheter, som DNS, databaser eller lagring?

Er teamet ditt forberedt på å ta i bruk nye metoder og verktøy i utviklingsprosessen?

Vi er overbevist om at konteinere har revolusjonert måten programvare bygges og kjøres på.

Vi er overbevist om at konteinere har revolusjonert måten programvare bygges og kjøres på. Imidlertid er det avgjørende å erkjenne at det er mange andre, enklere alternativer til Kubernetes for å orkestrere kontainerne dine.

Å etablere et Kubernetes-kluster er bare ett aspekt av prosessen. Før du setter opp klusteret, må du vurdere nettverksdesign og hostingalternativer. Når klusteret er på plass, må du samle komponentene som kreves for å skape en velfungernde og brukervennlig plattform for utviklere.

Våre foretrukne teknologier for dette inkluderer for øyeblikket:

FluxCD: For GitOps-basert kontinuerlig levering og distribusjon.

Cert-manager: For å generere og fornye TLS-sertifikater fra leverandører som Letsencrypt.

Prometheus: For innsamling og bearbeiding av metrikker.

Hvis du er usikker på om Kubernetes er riktig for deg, eller hvis du allerede har begitt deg ut på Kubernetes-reisen, kan Enabler hjelpe deg med å fastslå og etablere en passende løsningen for dine behov.

Kubernetes

A common misinterpretation within the DevOps community is the belief that developers should handle everything, from the initial stages of development to the final hosting of the application. This perception, however, does not reflect efficient workflows. Instead, we lean towards the establishment of a  platform that facilitates and enables DevOps.

In the world of technology, the term 'platform' has become somewhat of an overused buzzword, often leaving its precise definition blurred and misinterpreted. Different people may attribute different meanings to it, making its context in software development slightly convoluted.


To dispel any ambiguity surrounding our use of 'platforms,' the Cloud Native Computing Foundation (CNCF) has published an insightful whitepaper that  outlines what 'platforms' means in the realm of software development organizations.

Reduce the cognitive load on product teams and thereby accelerate product development and delivery.

https://tag-app-delivery.cncf.io/whitepapers/platforms/


What we mean by 'platform' in this context is an inclusive system, incorporating all the essential components a developer needs to deploy, monitor, and scale a deployment. The beauty of such a platform lies in its ability to abstract the intricate details of the underlying system, enabling developers to focus on their core tasks of creating and innovating, without needing to delve into the technical complexities.


In essence, the concept of platforms enables DevOps by simplifying processes, thus ensuring a more streamlined, efficient, and collaborative software development environment. It's not just about providing tools; it's about facilitating an ecosystem that allows DevOps to thrive.

En effektiv plattform understøtter ikke bare DevOps, men sørger også for at utviklere kan fokusere på å levere forretningsverdi.

En vanlig misforståelse av termen DevOps er tanken om at utviklere bør håndtere alt, fra de første utviklingsstadiene til den endelige hostingen av applikasjonen. Denne oppfatningen reflekterer imidlertid ikke en effektiv arbeidsflyt. Vi lener oss i stedet mot ideen om å etablere av plattformer som letter og understøtter DevOps. 

I teknologiverden har begrepet "plattform" blitt en noe overbrukt klisjé som ofte gjør at definisjonen blir uskarpt og feiltolket. Forskjellige mennesker kan tilskrive ulike betydninger til den, noe som gjør konteksten i programvareutvikling litt forvirrende. 

For å avklare enhver tvetydighet rundt bruken av ordet "plattform" har Cloud Native Computing Foundation (CNCF) publisert en innsiktsfull whitepaper som beskriver hva "plattform" betyr innen programvareutvikling.

Det vi mener med termen "plattform" i denne sammenhengen er et system som inneholder de nødvendige komponentene en utvikler trenger for å distribuere, overvåke og skalere en tjeneste. Skjønnheten ved en slik plattform ligger i muligheten til å abstrahere vekk de intrikate detaljene i det underliggende systemet, slik at utviklere kan fokusere på sine kjerneoppgaver; å skape og innovere, uten å måtte dykke ned i de tekniske kompleksitetene.

I korte trekk støtter konseptet med plattformer en DevOps tankegang ved å forenkle prosesser, og sikrer dermed et mer strømlinjeformet, effektivt og samarbeidsorientert miljø for programvareutvikling. Det handler ikke bare om å tilby verktøy; det handler om å skape et økosystem som tillater DevOps å komme til sin rett.

Plattformer

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

Greenerway

Smartpanel

Spacio

Tekna

Våre fokusområder

Enabler er en teknologipartner som gir bedrifter muligheten til å hente frem sitt fulle potensiale ved å tilby tilpassede digitale løsninger og effektivisere leveranser i utviklingsprosjekter.

Vår ekspertise innen cloud native strategier, DevEx og DevOps driver innovasjon og suksess på tvers av ulike bransjer.

Enable suksess

Les bloggen vår

 Kunnskap og innsikt

Mer om oss

Kenneth Nordum

Harald Svendberg

Dominika Kaźmierczak

Eva Hauk Fritzell

Er du lidenskapelig opptatt av å forme fremtiden for programvareutvikling med cloud native teknologier? Isåfall vil vi gjerne ha deg med på laget!

Team

Er du engasjert og ønsker å gjøre en forskjell? Bli med i teamet vårt og legg ut på en spennende reise sammen med oss.

Kontakt oss

Vi ansetter!

I Enabler er vår oppdrag å styrke bedrifter ved å levere innovative og effektive digitale løsninger som transformerer måten de navigerer i det stadig skiftende teknologiske landskapet. Vi er dedikerte til å drive vekst, fremme innovasjon og muliggjøre fremgang på tvers av en mangfoldig rekke bransjer, samtidig som vi skaper varige partnerskap og overstiger kundenes forventninger.

Vårt oppdrag

Se mer

Ekspertise

Vi deler gjerne vår kunnskap og hjelper med å bygge gode, skreddersydde plattformer 

Se hva vi tilbyr

La oss samarbeide

Hva de sier om oss

Våre kunder

Ta kontakt

Klar for å transformere virksomheten din?

Carl-Henrik Wolf Lund

NGI har over flere år hatt gleden av å samarbeide med Enabler i utviklingen av nye bransjeledende løsninger. Harald og Kenneth har vært sentrale ressurser byggingen av et sterkt team og en robust plattform, og deres arbeid har ført til etablering av nye og innovative løsninger innen GeoData. De har blant annet vært med på å etablere en ny IoT-plattform (NGI Live), ny digital plattform for grunnundersøkelser (Field Manager) og en driftsplatform basert på Azure og Kubernetes, som alle bidrar til å sette nye standarder for bransjen.

Director of ICT and digital services

Håvard Angen Rye

Enabler er en nøkkelpartner for Tekna i vårt kontinuerlige arbeid med å tilby våre medlemmer de beste digitale løsningene. Deres bistand strekker seg fra strategisk teknologirådgivning til en ledende rolle i utviklingen av vår hybrid sky- og dataplattform.

Med omfattende erfaring innen arkitektur, sikkerhet, nettverk og utvikling, samt en god forståelse av våre interne systemer, spiller Enabler en viktig rolle i å forme og optimalisere plattformen vår, både lokalt og i skyen. Dette har vært med på å bidra til at Tekna de siste årene har opplevd en rekordvekst i antall medlemmer.

Enabler støtter også vår interne utviklingsavdeling tett, og arbeider sammen med teamet for å sikre at våre løsninger er robuste, skalerbare og fremtidsrettede. Vi verdsetter deres kompetanse og ser frem til videre samarbeid for å forbedre og utvide våre tjenestetilbud.