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."

We are dedicated to embracing cloud native principles in both our development processes and platform architecture. By leveraging these principles, we aim to build and manage applications that are scalable, resilient, and highly efficient.

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 is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications.

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.

An effective platform not only facilitates DevOps operations but also ensures that developers can concentrate on delivering business value.

Platforms

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

Smartpanel

Spacio

Tekna

Below are some examples of areas we invest a lot of effort into. 

We belive that by leveraging modern technologies and methodologies we can accellerate the speed of development teams.