EdgeX Foundry on K3s - the Inception

This blog post is part 1 of a series of articles about how to deploy and operate EdgeX Foundry - an open source software framework for IoT Edge on K3s - a lightweight, highly available, and secured orchestrator.

In this post, we will see:

  • How the Edge is necessary for upcoming technologies?
  • How Linux Foundation is contributing to Open Source Edge and Networking?
  • What is EdgeX Foundry?
  • How K3s is complementary for the Edge?

What is GEEK

Buddha Community

EdgeX Foundry on K3s - the Inception

EdgeX Foundry on K3s - the Inception

This blog post is part 1 of a series of articles about how to deploy and operate EdgeX Foundry - an open source software framework for IoT Edge on K3s - a lightweight, highly available, and secured orchestrator.

In this post, we will see:

  • How the Edge is necessary for upcoming technologies?
  • How Linux Foundation is contributing to Open Source Edge and Networking?
  • What is EdgeX Foundry?
  • How K3s is complementary for the Edge?

EdgeX Foundry on K3s - the Initiation

This blog post is part 2 of a series of articles about how to deploy and operate EdgeX Foundry - an open source software framework for IoT Edge on K3s - a lightweight, highly available, and secured orchestrator.

In the first part of this series, we have seen all the pre-requisites that are needed to proceed with the hands-on. We will extend the EdgeX Foundry tutorial by Jonas Werner and deploy the EdgeX Foundry services on K3s. We have already learned that K3s will be a good lightweight solution to manage and orchestrate the EdgeX microservices. We will use the Geneva version of EdgeX Foundry. The scope of this post is to demonstrate an Edge use case that will consume the sensor data e.g. ambient temperature. 

In this post, we have seen the following:

  • How to deploy K3s?
  • How to convert docker-compose manifest to Kubernetes manifest?
  • How to deploy EdgeX Foundry on K3s?
  • How to send sensor data from Raspberry Pi to EdgeX Foundry?

Deploying LOGIQ on K3s using a Helm Chart

We’re huge fans of Helm Charts and the simplicity they bring to complex application deployments on Kubernetes and MicroK8s. We showed you how you could use Helm Charts to deploy LOGIQ on MicroK8s in a previous post. As a follow-up to that article, we’d like to show you how Helm Charts are equally helpful in deploying complex applications on other certified Kubernetes distributions such as K3s. In this article, you’ll learn how we use Helm Charts to deploy the LOGIQ observability platform on K3s. If you’ve never used K3s or Helm Charts before, you can use this article to get acquainted with both.

What is K3s?

K3s is a highly available, lightweight, and fully compliant Kubernetes distribution. K3s is packaged as a single binary, thereby reducing dependencies and minimizing installation, run, and auto-update steps that you’d typically have to take while managing a production Kubernetes cluster. As K3s is lightweight, you can run a cluster on machines with as little as 512 MB RAM and upwards.

K3s comes bundled with a local storage provider, a service load balancer, a Helm controller, and the Traefik ingress controller. A single binary and process encapsulate the operation of all Kubernetes control plane components, allowing K3s to automate and manage complex cluster operations like distributing certificates.

#aiops #cncf #devops #kubernetes #monitoring #observability #helm #helm charts #k3s #kubernetes health monitoring #monitoring for kubernetes

Linux Tutorial

1601692765

How to Install and Configure K3s on Ubuntu 18.04

K3s is a lightweight version of Kubernetes. It is a highly available Kubernetes certified distribution designed for production workloads in unattended, limited resource, remote locations, or inside an IoT appliance. The developers of K3s declare that K3s is capable of almost everything that K8s can do.

So, what makes it such a lightweight distribution?

The memory usage is reduced by running many components within a single process. This eliminates the significant overhead that would otherwise be duplicated for each component. The binary file size is smaller by removing third-party storage drivers and cloud service providers.

  • Running it requires less memory.
  • A small, 40Mb binary file that contains all the non-container components for starting a cluster.

#k3s #ubuntu

Foundry Vs Hardhat

In this article, we will be comparing two smart contract development frameworks. Hardhat, which is the most used framework for developing smart contracts and the most preferred one by devs, and Forge (Foundry), which is a new framework written in Rust.

If you are familiar with dapptools, you will find it easy to use Foundry as Foundry is a reimplementation of dapptools.

For the sake of this article, I created a Github repo which is a version of the lsp-smart-contracts repo but with Foundry instead of Hardhat, to compare a few things and try out the features provided by Foundry.

 

Main Differences:

Diff 1: Compile Time

Foundry provides a faster compile time than Hardhat and a comparison using the lsp-smart-contracts shows that the same contracts took ~39.33s to compile with Hardhat Vs ~26.22s with Foundry.

Diff 2: Testing Language

Tests in Hardhat are mainly written in Javascript/Typescript, but in Foundry, they are written in Solidity.
Some developers hate the fact that they have to master another language (JS) to test their Solidity contracts. Also, when writing Solidity tests there is less context switching between languages which helps to focus and gain more Solidity knowledge. + Running the tests in Solidity is much faster than JS.

Diff 3: Dependencies

Hardhat uses npm to manage dependencies and Foundry manages dependencies using git submodules by default.

Foundry Features:

Feat 1: Traces

Traces allows you to see what happens during a function call, and also show you which functions have been called, with which parameters, and what events have been emitted in a simple and nested way.
You can choose to increase/decrease the verbosity to check more/less traces.

How to Foundry with Brock ElmoreSpearbit

Feat #2: Fuzz Testing

Fuzz testing is a very important thing to do that many developers ignore. While writing tests, probably there are some scenarios that are not fully covered in the tests.
Foundry fuzzer will automatically generate random values for the function you specify, to check for edge cases.

After finding values that will make the function expect differently, Foundry will give you the calldata used to produce the behavior.

 

Foundry is super powerful but it’s still in an early development phase, users are expecting more from the devs in terms of documentation, tutorials, and features. 

This story was originally published at https://yamenmerhi.medium.com/foundry-vs-hardhat-918c55e47add

#foundry #hardhat