Cloud-Native

Dan — Sun, 27 Sep 2020 08:25:02 +0000

This article describes how a Cloud Native application should look like, it is based on the well known 12 Factors.

At the moment of writing this article, in my understanding, the Cloud Native is not only about code that developers write, but it is also a way of organizing engineering teams so that their work will be highly effective, flexible code, and at the end, you have fast time-to-market for your applications.

In articles that I read, Cloud Native is strongly related to software as a service, Continuous Integration, Continuous delivery, Zero-downtime deployments, and teams that are deploying daily.

Codebase

One codebase tracked in revision control, many deploys

This principle says that your codebase should produce one executable, you don’t produce multiple executables from one repository and you don’t maintain multiple repositories that and the end is used to produce one executable.

When you have one repository that produces multiple executables is not good because easily you may end up messing models and some of your application doing work that they are not responsible for.

Having multiple repositories that are used to produce one binary is hard to maintain and hard to evolve – after-all we are humans and we don’t have an infinite capacity to keep things in our memory, it is hard to work when multiple repositories are used to produce a single app.

Dependencies

Explicitly declare and isolate dependencies

Your application should not make the assumption that it will run in an environment where some libraries or dependencies are available, or any tool is available, or the database is available on the same host or even it has access to storage.

When writing applications for the cloud you make them stateless, they make zero assumptions about the env when they are going to run, storage/mail/database are external services that are pluggable using configurations.

The only assumption that you can make is that your application has access to CPU and memory.

The benefit of not having external dependencies is that it simplifies the application setup at different stages, developers setup the development-environment easily, the staging and production environments are easy to configure.

Configs

Store config in the environment

Configuration of an application are the things that vary between environments:

backing services like Memcached host, database resources
credentials to your cloud provider or Facebook app

Sometimes application store configurations in code as constants, some tools make this easy to do (example injecting a Value using Spring and providing a default value).

In the 12 Factors, an application should store the configurations in the environment variables, configurations are easy to change and they are not written in a single file and prefixed with dev., prod. etc.

There are tools like Spring Cloud Config or Netflix Archaius.

Read full article on my blog: Cloud Native

Remote invoke methods on your micro controller

Dan — Tue, 03 Oct 2017 08:42:00 +0000

Few months ago I started to create a small device that will turn on/off the lights in my room, I needed this feature because in the evening I like to read, but turning off lights is a little bit painful because I have to stand up of my bed.

I've been started with ESP8266 controller because of incorporated Wifi and low price. First version of code used HTTP requests and executed actions based on GET calls (ex: put HIGH value on pin 13 was /action?pin=13&output=1 ), after first version I understood that controlling lights in other rooms will not be possible using the same code, project wasn't extendable in a easy way, I had to tune code for each room, adding additional parameter in request wasn't a good solution because I had to write source code on micro-controller customized for each device/room), also I had to remember IP addresses for calling actions.

Imagine a mobile application where you have to add IP addresses for each device you want to control and you have to handle situation when your IP addresses changes - it's not that easy and UX will be a bad one.

Knowing drawbacks and writing new requirements, my decision was to rewrite the project from scratch using MQTT as data transfer protocol.

After reading some articles about MQTT, I've decided to write code that will allow to control unlimited devices and as additional requirement I wanted to use the same code to control other things from my house ( like reading temperature from sensors or writing/reading from analog pins ) with easy and minimal setup, without editing the source code for each micro controller.

I started with idea that a small "core" should execute any methods that it knows about and they should be callable over MQTT. At this moment you can use MetalIO, add your methods in /src/functions and just register them in /src/main.cpp:

//create new instance
auto digitalWriteFunction = new DigitalWriteFunction("digitalWrite");
//register to metalio core
metal->put(digitalWriteFunction);

Now you can call your method over MQTT as:
publish a message to your configured topic ( ex: /actions/room1 )

digitalWrite:13,1

One important thing is that MetalIO is fully configurable over Wifi, when you start device and click on BTN1 ( or any button that you can choose at compilation time, "TRIGGER_PIN" parameter in platformio.ini ), your device will create a named AP where you can connect and see config interface ( default address: 192.168.1.4 )

At this moment MetalIO software can be written on any ESPx, Arduino or Intel Galileo Board, configured over Wifi and any application/dashboard that supports MQTT can be used to communicate with hardware devices.

Project can be found on GitHub: https://github.com/daniftodi/metalio

Forem: Dan