We are currently working on an app that will store IoT data in a database ( process it like average etc...) and make it available through Rest API. Our first though is of course to build one app (good old monolithic) that will get the data (over MQTT Endpoint mainly) and make them available with the rest API.
We were considering microservices (our use case would suit it I guess), but, we are not ready for that. We are two developers trying to build an app and I think, it is something that we could consider as soon as our monolith architecture will be not efficient anymore... We have worked on some project that use it and we understand the concept but there is some DevOps skill that we clearly do not have yet, and we are not Netflix, Google...
One of my workmate told me to split the app:
The MQTT endpoint will send the telemetries to a event-bus the data processor will get it and proceed it (calc average, store it...)
But it sounds like a distributed monolithic app and as far as I know, it's kind of terrible to manage (shared db model in a lib, everything is basically related to everything).
I still guess that the simple monolith app is more than enough for starting (we could run multiple replicas of the app), the microservices can come afterward and the distributed monolith described above is... original...
I know that this question could be "opinion based", but we are more looking at a pattern that could solve our technical problem.
It's actually OK to develop a monolith (even a distributed monolith: the pejorative sense of that term really describes the situation where one thinks they're developing microservices but they end up coupling them so deeply that they get many of the worst aspects of both monolithic and microservice style architectures) if the need to do microservices hasn't presented itself; you arguably don't really need microservices until you have a big enough dev team for coordination and coherency delays* are dramatically impacting your ability to deliver value. There's not really ever a strong technical reason to do microservices, though it's possible to paint oneself into a corner via earlier technology choices where microservices will sound like the way out.
It is possible to design a monolithically-developed and -deployed system which is, effectively, a microservice architecture. If doing that, you'll want to be rigorous about enforcing modularity and that crossing a module boundary imposes an asynchronous boundary. If doing that, the modules are fairly easy to pull out into independently-developed and -deployed microservices with only a small amount of changes to glue code needed. If the modules communicate with each other via MQTT versus shared local state or sharing a DB, there might not even be any changes required. The actor model (as found in, e.g. Erlang, Akka, Akka.Net, Thespian) may be helpful in enforcing that (disclaimer: My employer maintains and sells support/consulting services for one of those projects) modularity and asynchronicity while location-transparency allows the "same-OS-process" case to use a faster local messaging transport than MQTT.
*: Gunther's Universal Scalability Law applies as much to the (human) system that builds the system as it does to the system being built (of course, the human system that builds the system is also building itself as it goes along...)