Even the monolithic “Thick Client” software applications have layers. You may need to look for them, but they are there. How well these layers are separated impacts the performance, maintainability, portability flexibility, and security of the end product. Let’s explore by walking up the hardware ladder.
Down to the metal
At the ASIC or FPGA level, we have very few layers as far as “software” is concerned. We are building applications based on the circuitry designed on the board or within the chip. The number of layers is fairly minimal. Developers typically use tools that build binary applications (you could say “firmware” in a sense) that are either stored in non-volatile memory or “burned in” at the factory.
Extreme performance comes at a cost. You are basically making a circuit for a single purpose. To reuse this for a different (even similar) task requires a large effort. In the case of an ASIC this includes modification at the manufacturing level. For typical software development, we simply do not get much of a chance to work at this level. It is often not practical for most projects
Task: Build a websocket client application for an FPGA that has an Ethernet connector
Assuming you do not have any CPU to do any of the typical stuff, you will have to handle every detail of what comes across that Ethernet connector. You will get bogged down in the details of the network layers and frames. It is not impossible, but you will have to be an expert in everything Ethernet and Internet protocols. If you are not, you will be by the end of your project.
- Performance: Extremely fast
- Maintainability: Poor
- Portability: Poor
Embedded Processors
This is one of my favorite playgrounds. In recent years (ok, lets say the last decade) it has become relatively inexpensive to acquire a development board and start hacking away. The tools get easier to use and the layers start building. Resources are limited, so you have constraints on the size and feature sets of the applications you build. But development efforts are less, and portability improves.
Task: Build a websocket client application for an Espressif ESP32
Compared to the FPGA task above, this task gets much easier. Although you are still fairly close to the hardware, there are available libraries to handle the complexities of Ethernet and websocket communication. Your focus turns to handling the information received and sending the desired results.
- Performance: Fast
- Maintainability: Better, but specialized knowledge required
- Portability: Poor
Specialized Hardware and Operating Systems
When you get a bigger package (i.e. an Android smartphone) you have an even bigger playground. You have a complete ecosystem for user interfaces, network connectivity, processing power, and a good chunk of storage space (volatile and non-volatile).
Task: Build a websocket client application for a Samsung S23 smartphone
You will probably be using a library that someone wrote that hides the complexity of the websocket protocol, which in turn uses the Java virtual machine that hides the complexity of talking to the operating system, whose kernel hides the complexity of talking to a network driver that hides the complexity of talking to the specific chip that makes the decision as to whether it should be talking to the WiFi network or Cellular network, and then makes the necessary calls and retrieves the desired results.
You can write an application for a Samsung S3 that will probably also work on any other Android device of a similar vintage, and probably newer ones for quite a while. And to build such an application will take a fraction of the time it would take to do so on the ESP32.
- Performance: Not as fast
- Maintainability: Even better
- Portability: Very good
You also have another choice here. You could reduce the layers by writing something specific to the Samsung S23. For example, you could write a C++ application that skips the Java VM. How does that affect our list?
- Performance: Much better than using Java, but not as fast as an FPGA. Probably better than the ESP32 due to processor speeds. And there is a cost to consider if you have to do something with the data (i.e. display to the user via a Java application).
- Maintainability: Better than the ESP32, but not as good as the Java version above, due to less C++ developers that know the Samsung S23
- Portability: Ok, but not as good as Java. Moving to another phone with a different chipset will require a recompile, but will probably work.
Containerized Cloud Application
Here we are far removed from the hardware layer. Software performance is at the mercy of the hardware vendor, the containerization techniques, and many other factors. But there are benefits.
Task: Build a websocket client application that can be deployed Amazon Web Services
Our choices get even wider. We could write this in most modern languages. We could make it as short or as long as we wanted. We can pick and choose libraries or build them ourselves. All with varying tradeoffs. Our list just became very hard to generate.
- Performance: Depends on where it is deployed
- Maintainability: Depends on the language and developers chosen
- Portability: If we stick with Amazon Web Services, we are fairly safe in knowing we can deploy it anywhere within Amazon and it will work. If we decide to switch cloud providers, it will depend on how we wrote and packaged our application.
Conclusion
This is a long-winded version of software layering. And I wrote this with 1 point in mind. Choices made at the architecture level affect the end result.
Some projects come to me with no preconceived notion of where the application will be run or how the results will be used. A view of the end product has to be somewhat well described if the choices at the beginning can be made with a great degree of accuracy. Unfortunately these projects have a low success rate (“You want me to pay you when you haven’t written any code?!?!?”)
Other projects arrive with a vision of how it will all work, and how it will tie into existing systems. They already have some of their system, or perhaps all of it. They may just be looking for an enhancement. I have very little say on the language, hardware, or tools. Such projects have a higher success rate, even if the architecture choices are not “ideal”.
A small number of projects dictate general parameters, sometimes because they are somewhat “techie” and heard the buzzword of the month and they imagine it is the answer to their problem (a.k.a. silver bullet). Or the opposite. They want to use this new tool/language/framework to solve a perceived problem that others have (a.k.a. hammer looking for a nail). These projects have a low success rate.
As a consultant, the hats I wear are varied. This is something I enjoy, although I often do not get to learn the intricacies of certain aspects as deeply I would like. But I take them as they come, and continue to learn what I can.
Now, let’s take this post and apply it to language wars. (coming soon)