sebastianpfischer328756These are indeed two different words when it comes to software programming.
The evolution
It is important, first, to consider what software engineering is and what it tries to fulfil.
As software engineer, we thrive building solutions that can be commercialised while constantly resolving problems.
Cloud developer
It is tight to the general evolution of software. First stones regarding the concept of virtualisation started in the 1960th with the question of "How do I share resources (SW and HW) between users".
It resulted in the creation of VM softwares around the 2000th. (e.g., VirtualBox, Hyper-V, ...)
Parallel to the VMs, Internet also started having a very high adoption rate in the 2000th which meant services, application running over the internet became more and more important. The load supported by the services also increased and needed to be handled.
A big group of developers specialized themselves into this field. Trying to abstract themselves from the HW underneath, developing application that run over the internet, developing methodologies (DevOps, Agile, ...), developing languages (Java, golang, ...), developing tools (PostgressSQL, OracleDB, ...) to improve their lives.
The group is carried through the booming and success of the economic of internet..
Unfortunately, the creation of services over the internet are still complex, therefor google started in the 2000th to work on Borg that later became known as Kubernetes (2014) which created one additional abstraction over the nodes and allowed, in an easy way to create, deploy, revert services. It is now broadly adopted in the field. All this concepts allows the creation of new business models like AWS, Azure or Google Cloud.
A part of this group try to mainstream what cloud engineering means for them with the creation of the Cloud Native Computing Foundation or Open Container Initiative.
The dream of expending out of the internet came shortly after 2014. One more point came into question, with the booming of Machine Learning, is there a possibility to extend all this capabilities into the real world? And what if we could interact with our surrounding through services or services change my surrounding?
The idea of "Internet Of Things" got spread around 2014 as the next big thing.
Embedded developer
It kind of had the same start as above but tried to apply software directly on the real physical world. The biggest issues usually contain size/capabilities factor for the MCU, bigger it is, more visible it is, less convenient it is. Transportation or/and military were very good candidates. Performance usually matter, therefore, knowledge of the target system (MCU & in/out) is critical for a good software.
It is standard to request the implementation of features that usually do not fit on the device itself. When the requirements are running, there is no need of updating it. Actually, you may never be able to access the device when it is in production!
Thanks to the law of Moore, the MCUs are becoming smaller and allow the implementation of more and more complex functionalities. IoT feels like a logical new field of application.
The conflict
Cloud developer inherited from an evolution that push the following quality goals:
- Reliability - Service online should continuously work. Service Level Agreements (SLAs) and SLOs needs to be defined. If a services goes offline, we lose revenue.
- Maintainability - Tight with feature scale, we want, best case, a logarithm (or even smaller) scale between the number of features and the number of engineers to hire to develop and maintain the code.
- Scalability - No machine is powerful enough to scale exponentially, therefore, you need to scale horizontally, provide services that can be shared between many different machines. A service usually running on one machine, is usually a simple system.
Embedded developers inherited from its own evolution that push other quality goals. It is important to notice that the set of quality goals that can be found here are way broader than for cloud services. Let us take a look at the most common one.
- Performance - The MCU is usually under-dimensioned for the set of features it needs to contain. HW capabilities need to be well understood to make everything fit.
- Safety - This is a field of its own. You do not want your car to crash or the doors to not unlock after a crash. You do not want the plane to crash if a system breaks down.
- Reliability - You do not want to lose connection to your satellite if the modem crashes. It also cannot reboot right 🙂 You do not want its orbit to change while it reboots.
Embedded developers need to control any aspect of the running sw on the device. What runs, when, how to react to what,...
I did not mention all the intermediate fields, from embedded linux or mobile phones, I must say, I do not really consider them as embedded. The MCU is usually over dimensioned and timing is usually not that relevant.
So where are the conflicts:
Cloud reliability vs Embedded performance
Cloud reliability is usually very tight to availability.
When you communicate with a satellite, the communication is delayed, due to the cycle day/night, you always want to have enough power to maintain your course, therefore, the system may decide to put the communication to idle to save power. Depending where the satellite flies, the bandwidth may be limited, therefor the download of content like pictures may occur only once a day.
Therefore, you cannot have a cloud reliable service for taking pictures. It could take to several hours until the satellite reply. Higher expectations does not make any sense when so many physical constraints exist, it is unrealistic. The solution, on the cloud side, is usually to dump the device until it comes back. This issue is that a "dump" is usually very easy to handle on the cloud side, but not at all on the embedded side. It impacts embedded performance because the used stacks need to be reseted and a new registration to the cloud need to occur. This requires many CPU resources. Even more if security is involved.
This is just one example. There are unfortunately many similar cases around.
Cloud reliability vs Embedded reliability
When we talk about reliability, we talk about 2 different things.
Like for the point above, cloud reliability cover availability by reducing and dealing with humain and machine errors.
On the other hand, Embedded reliability means that the device need to fulfil its functionality independent of how many factors may prohibit it to do so. Communication is one of them but often not the core functionality.
so when engineers discuss about reliability, they may bypass each other.
Cost and expense saving factors
Revenu stream tight with cloud reliability. Services that fail is synonym of lack of revenue. Cost saving is part of Scalability, if the costs grow as logarithm, tremendous amounts are saved when the service scale.
For embedded systems, it is connected to performance. If I save $1 per MCU, I save 10M$ if I produce 10M devices. Reliability will support customer happiness which will impact sells and safety will ensure we do not harm a person.
Developing an IoT project usually mean both parts are involved. Engineering costs may be high. Costs optimisation on engineering will always impact one of the quality goals above. It may cost headaches to find a compromise.
Data-driven vs HW driven (bonus)
Now that I participate more in developing cloud solutions, I was relative surprised how data is everywhere in the cloud. Requests are data to handle, between steps are data to handle, the result is also a data that need to be sent out or stored somewhere. Building solutions request a deep understanding of how the data are used and processed. It is a conscious decision.
On the embedded side, data is almost irrelevant. Rarely are they stored. We usually just find 2 types of data: configuration data (usually stored as EEPROM) and other data. The data in second category are almost just dumped in the internal or external flash. Worst case, we use fatfs and need to live with the overhead. So embedded engineers never really understand when a cloud engineer has issues with data.
On the other side, embedded engineers are always thinking about the HW they are using. It goes from the basic one like CPU capability and Architecture to memory and RAM but it also includes the different port, available peripherals, how interruption service routine works that would allow us to control and optimise any aspects of the developed software.
So when a cloud engineer comes to an embedded engineers and ask why he does not want to send him a json file cross LoRa, it is an instant headache in the head of the embedded engineer: how do I create the necessary RAM space to store a json, how do I transport it to the peripheral to send it out via LoRa, LoRa is very LPWAN, how do I transfer any other information from the system after sending the message, which features are impacted here...
The solution
You need engineers that can bridge the gap and/or engineers that are willing to understand the other side and make compromises. They are some hard constraints but also some soft one. Before implementing the solution, the interface between the two worlds need to be heavily discussed.
In my journey, a better understanding of how to build cloud solutions helped me to understand each side and also understand what are valid compromises that can be taken.
Ultimately, software architecture and software engineering is applicable on any fields, just slightly differently due to the different quality goals that impacts the solution.
References
- https://en.wikipedia.org/wiki/Virtual_machine
- https://en.wikipedia.org/wiki/VirtualBox
- https://en.wikipedia.org/wiki/History_of_the_Internet
- https://www.computer.org/publications/tech-news/trends/50-years-of-software
- https://en.wikipedia.org/wiki/Engineering
- https://blog.risingstack.com/the-history-of-kubernetes/
- https://www.linkedin.com/feed/update/urn:li:activity:6920381842244169728/
- https://ptolemy.berkeley.edu/publications/papers/02/embsoft/embsoftwre.pdf