Hmm.
Starting to write this post is surprisingly hard. Despite the fact that I’ve
already written one blog post earlier this year. Well, anyway… Now that
I’m finally graduating (more about that on a later post!11), I’ve had some
extra time to spend on productive things and re-evaluate my focus. And what an exciting turn of events
has it been!
I’ve
already spent one weekend on briefly investigating the state of serverless computing.
This netted me an instance of Node-Red, but also MQTT, NATS, MongoDB and Redis
(even though I already had one) to toy around a bit. All these are running on
top of Docker Compose on a new, previously under-utilized incarnation of Usva.
Docker Compose is actually a somewhat new tool for me. I’ve meant to look into
it (or Kubernetes) for quite a while, but never got around to it. That is,
until I made it a part of my thesis. Now this research already paid back –
setting up all those services using Compose was a breeze!
Testing out
Node-Red actually kicked off a larger process. It demonstrated that utilizing a
range of ready-made tools isn’t actually all that bad and that there actually
seems to be a lot of tools now that suit my way of doing things. And well, now
that I’ve somewhat reinvented all of the software involved at least once, I can
finally get to actually using existing ones properly :p I'll have to postpone Tracker once again while I discover this new brave world.
Node-Red
offers most of all a nice platform to host short pieces of code. There is a web
UI for coding and testing, and after that the code remains on the instance and
keeps on executing. No need to worry about setting up routing or cronjobs or
any of that! There are also some plugins for using stuff like databases and message
queues with minimal work. While Node-Red doesn’t seem very scalable on anything remotely
complicated (see a price tracker below), it did manage to verify the concept of
serverless for me. And tinkering with it was actually quite fun and easy!
* * *
While a bit
unrelated, as a part of this I also began experimenting on using events and message
queues for communication on a larger scale than before. This shouldn’t come as
a surprise though; in one iteration of Tracker I already began heading this
way. And this kind of indirect messaging actually also plays a role with IoT
devices – directly addressing them might not be possible due to how they have
been networked. But why is this important? For two somewhat equally important
reasons. The first is that for the longest time I’ve been in great pain due to
how hard service discovery can be. But if services subscribe to queues instead
of needing direct addressing, service discovery gets almost completely eliminated.
And second,
it is because IoT is relevant now! I backed Meadow F7 on Kickstarter during the
spring; it is a full .NET Standard 2.0 compatible embedded platform in Adafruit
Feather form-factor, with a possible battery life of about up to two years. C#
and low power in one small package!!! It even has integrated Wi-Fi and
Bluetooth. I should be getting it in just a few weeks. Finally! But I guess
more on that on a later post.
So, what
does this all mean? With service discovery being taken care of by a message
broker, and hosting solved by serverless and docker-compose (at least in theory),
there comes an unexpected ability to realistically develop microservices
and other lighter pieces of code. And possessing some easily programmable embedded
devices opens up a way for a whole new level of interactions. Though first I have to
replace Node-Red with a proper serverless solution… Well, not have to, but...
I already
have plenty of development ideas, but I guess they too will have to wait for another
post!
No comments:
Post a Comment