I am going to share a little secret with you. mimik’s idea to create a technology that centers around putting distinct, shareable microservices in edge devices such as telephones, mobile tablets, and industry-specific equipment just didn’t make sense to me at first. To my thinking, the benefit of edge computing, as with any rich client, is that it relegates a portion of computational activity to the device capturing the data and then forwards the results of that computation onto back-end data centers for archiving and subsequent processing. It’s an architectural style that’s been around since the first PC was connected to a back-end database. Putting more computing on the edge devices reduced the processing burden on the back end.

It turns out that the reason that I wasn’t “getting it” about mimik’s approach was because I was conceptualizing edge devices as just another data-gathering mechanism for centralized client-server applications.

Now don’t get me wrong, the client-server approach to edge computing isn’t incorrect. In fact, there are lots of examples of using edge devices for client-server data gathering: the red-light traffic camera down the street from me is a prime example. But it is limiting. There are other ways to think about edge computing, and mimik’s approach has forced me to think differently.

I struggled with mimik’s approach until I made a fundamental shift in my thinking, which is this: the key to understanding mimik’s approach to edge computing is to put the edge device at the center of it all, both in terms of processing activity and data boundary.

Allow me to elaborate.

Understanding device-centricity

When you think about it, edge computing is nothing new. As I stated above, rich client technology has been around for a while. And there’s an argument to be made that edge technology has been around since the introduction of the telephone.

Originally telephones were independent yet interconnected nodes on a network. You needed the telephone company to establish the connection between the callers, but once the callers were connected, each device was independent and the information context of each device was private.

In other words, I could use my telephone to call any other telephone of my choosing. Outside of the dependency on the telephone company to make the connection, my device was independent.

In terms of information context privacy, consider this: When I made a call to an older-style telephone on a landline, I had no access whatsoever to the information context of the party I was calling. I had no idea where the phone was in terms of physical location. That location was private to the caller. I had no idea if the phone was in an office, a house, or an apartment. All I knew was the number assigned to the phone I was calling.

Also, callers could not share anything but verbal information with me. They couldn’t send me a picture of their cat. They couldn’t send me their favorite recipe for apple pie. However, they could tell me the recipe over the phone, and then I’d have to write it down on my end.

Information exchange between telephones was voice-only and direct

Until the fax machine came along, no paper was exchanged. The piece of paper that had the pie recipe at one end of the conversation was private to that context and the piece of paper that had the pie recipe on my end was private to me. The person telling me the recipe might have a typed copy. I might have written the recipe down in an impromptu manner with a pencil. There was no way of knowing because paper and the information on each piece of paper were private to the information context.

These might seem like trivial distinctions, but they’re not. The reason that a telephone can be independent and the information context of a caller is private is because the system is device-centric. To put it another way, the telephone, not the telephone company, is at the center of interactivity. This is a distinctly different approach to the client-server paradigm which puts the server at the center of all interactions in the system. The implications are significant.

Thinking differently about device-centric microservices

mimik’s approach to microservice architecture is essentially device-centric. Users download an application that contains a microservice from a central repository onto their edge device. That device might be a cell phone or mobile tablet. It might be a set-top device connected to a television. It could even be a forklift running in a warehouse.

Once the microservice is downloaded, it’s installed on the device. When working with cell phones and mobile tablets, the download and installation process can be done using an application service such as Apple’s App Store or Google’s Play. Alternatively, download and deployment can be facilitated programmatically by getting the microservice directly from an artifact repository service such as GitHub or Maven Repository.

Putting a microservice directly on an edge device makes the microservice independent and private 

Regardless of the download and installation method, the important thing to understand is that once the microservice is installed on an edge device, it’s an independent entity and private to the device on which it is installed. This is fundamentally different from server-side distributed application scenarios in which the microservice is a discrete yet integrated part of the larger application. In the mimik paradigm, the microservice is meant to be a stand-alone asset.

The stand-alone nature of a microservice that runs with mimik requires those who create and use microservices to think differently. The best way to conceptualize this difference is to go back to the telephone analogy.

The emergence of device-centric microservices

As mentioned previously, up until the introduction of fax machines, land-line telephones were voice-only devices. Two callers connected and had a verbal conversation. That was the limit of data exchange. When cell phones first appeared, they too were voice-only.

Eventually, cell phone callers could exchange text messages via SMS. Early versions of SMS sent the text directly from caller to recipient. There was no server-side storage. After SMS came exchanging photos and pictures. There was no sending hyperlinks between parties. You sent the binary photographic data directly to the recipient. This is because early cell phones didn’t have direct access to the internet and didn’t have the computing power to support browsers.

Data exchange in early cell phone technology was based on peer-to-peer networking

Putting history aside, the important thing to understand about the early data exchange paradigm is that all data on the cell phone was private to the device. If I took a photo of a cat using my cell phone’s camera, that photo lived on my cell phone, not on some central server on the back end. Thus, I had a great deal of privacy. The ability to store cat photos in a central location was a technology that was yet to come.

But that technology did come. Cell phones also became a lot more powerful: so much so that today, a typical cell phone has more computing power than all the computers required to land a man on the moon in 1969. The amazing amount of computing power available in modern cell phones makes them well suited to being first-class, client-side devices in the ever-expanding universe of client-server architectures. It’s no surprise that cell phones are a predominant client device for applications such as Facebook, Twitter, and Instagram.

Sharing data from a common location on the network is typical of a client-server approach to distributed computing.

In order to handle all this client activity on the front end, things had to change on the back end to handle the enormous load, both in terms of computing capacity and the increased frequency in application release cycles. Thus, the emergence of microservice oriented applications (MOA) on the back end.

The result is that today we have two patterns unfolding on the technology landscape. The first pattern is the emergence of billions of powerful cell phones and other types of edge devices bound to centralized applications hosted in the cloud. The second pattern is the emergence of microservice oriented applications on the back end to handle the increasing burden placed on the ever-growing centralization.

But there is a third pattern emerging: independent edge devices running their own microservices. This is where mimik’s approach of device-centric microservices comes into play.

Creating device-centric microservices

Installing microservices as independent assets on a mobile device is not about turning that device into another node in a centralized microservice-oriented architecture. Instead, it’s about taking an entirely new approach to distributed architecture. It’s about putting the edge device at the forefront of computing activity. It’s also about creating device-centric microservices. To understand the concept, let’s go back to cat photos on a cell phone.

Imagine I have a cell phone full of cat photos. A friend of mine loves cat photos and has a cell phone. (I know, in this day and age, everyone has a cell phone. What’s to imagine?) Obviously, I want my friend to enjoy my latest cat photos.

Now, I could easily send my friend my most recent cat photos as an SMS attachment whenever I take new photos. That’s what I would have done decades ago. The drawback is that there’s a lot of communication overhead involved. I’d have to remember to SMS my friend a new photo when I took one. Or, my friend would need to keep contacting me to ask if any new cat photos were available. As you can see, it’s a pretty inefficient way to get the latest cat photos to my friend.

Most likely today, I’d post my most recent cat photos out on a social media site where my friend is a member. The site notifies my friend that I posted a new cat photo. My friend can simply download the photos from the site. This happens all the time. However, there’s a drawback: I’ve sacrificed my privacy by turning the photo over to the social media site.

However, taking the device-centric approach to microservices allows me to maintain my privacy. Imagine that I send my friend a hyperlink that’s bound to a microservice running on my cell phone, and only on my cell phone. This microservice allows my friend to get my most recent cat photos that are stored on my cell phone. The microservice notifies my friend that a new cat photo is available. It also provides a private link to get the recent photo.

Publishing such a microservice would allow my friend to get cat photos on demand while not forcing me to sacrifice my privacy. The only interactions in the photo exchange are between my cell phone and my friend’s cell phone.

Device-centric microservices are independent and private to the hosting device

This is what device-centric microservices are about. It’s the ability to publish services that are accessible only to qualified parties in a manner that is private and independent. Of course, I still need a network provider to connect my friend’s cell phone to mine, just as in the olden days when two landline telephones needed the telephone company to connect callers together. But that’s where it ends. My data is on my device only and not shared as an asset at a common location on the network. It’s an important distinction and one that will require developers to rethink how they approach application design in general and microservices in particular.

Putting the edge device in the center

So, how does one conceptualize a device-centric microservice? One of the easier use cases to imagine involves access to private data, such as sharing private medical data. Instead of granting permission for a third party to access my medical data from my health provider, I download a microservice that allows the third party to contact me directly for the information. In turn, the microservice gets the data from my health provider using my credentials. Then, the microservice sends the information on to the third party from my device.

While the use case above is simple, it’s emblematic of two ways I had to change my thinking in terms of device-centric microservices. The first change I made was that I had to realize that there are viable architectural patterns out there besides traditional client-server designs. Admittedly, I had become myopic in my technical thinking. My usual mindset is to imagine a multitude of clients bound to back-end applications in the cloud developed according to the principles of MOA architecture design. I was like the carpenter whose only tool was a hammer. My only solution to a problem was to bang nails, real or imagined.

The second change I needed to make was that once I accepted the viability of device-centric microservices, I had to imagine microservices that were indeed independent and device-centric. Again, my bias is to think of microservices as discrete parts that get aggregated together to create a larger server-side application. Device-centric microservices live outside the data center. As a result, they are not a discrete part of a larger application any more than the camera in my cell phone is a part of a larger piece of photographic machinery. The cell phone camera provides a specific service that is special to my needs. It’s the same with device-centric microservices. They stand alone and provide a service that is special to the needs of the user of the device.

It’s a different way of thinking.

Putting it all together

There’s a good argument to be made that edge computing is on its way to being the next Big Thing in IT.  According to a report from Grand View Research, the global edge computing market is forecast to expand at a compound annual growth rate (CAGR) of 38.4 percent from 2021 to 2028. That rate of growth means that within seven years, the edge computing market will be nearly ten times the size it is today. This is significant growth.

Edge devices will undoubtedly enhance traditional client-server applications. Transforming the household refrigerator into a rich client that can automatically order milk online when stock runs low is a pretty amazing technical feat.

Yet, for all the opportunity edge computing offers, there’s also a good argument to be made that if we’re not careful, it could become the latest flavor of the month on the IT landscape if we’re not careful. As I discovered, thinking of edge computing only in terms of traditional client-server architectures limits the potential of the technology.

Having one edge device engage in communication with another edge device directly and independently is nothing new. Telephones have been doing it for well over a century. But allowing an edge device to publish a microservice that can be used by other edge devices directly and independently is new. For me, it was a transformational way to understand microservices, which offered me new ways to think about systems design. It took me a while to get there, but I did.

I’ve come to make device-centric systems part of the way I think about enterprise architecture. Taking a device-centric approach to system design will not replace traditional client-server architectures—and it’s not meant to. Rather, the device-centric approach provides a way to create solutions for mobile computing systems in which independence and privacy are paramount concerns.

Did you know:

mimik’s hybrid edgeCloud platform comes with a run-time engine (edgeEngine) that enables developers to work with global functions in the central cloud while utilizing edge microservices for moving processing workloads to different edge devices such as smartphones or TVs.

Learn about Fundamentals of mimik edgeEgine Runtime