Microapps vs Microservices

Gone are the days where we had computer units filling up entire rooms, needing dedicated staff just to ensure its continued operation, and vast amounts of energy just to keep the computer cool. As technology blossomed, we began pushing the boundaries of computing beyond what we thought was possible. Gradually, computers that filled up entire rooms slowly became things we could mount on a desk and work with, without any loss in computing efficiency. 

This emphasis on speed, size and efficiency, although more evident in computer hardware transition over time, is perfectly mirrored in modern software development methodology. You just might not have noticed this transition as much as you noticed the thickness of your iPhone diminish over time, but software developers are constantly looking for new ways to make software faster, lighter, easier to use, and more efficient with its available resources. This trend for faster, lighter, more engaging software is the reason why microapps and microservices are such a hot topic today.

The adoption of microapps and microservices causes issues when it comes to monitoring. No longer can we look at all the jobs running in one place, we need to collect metrics from all of the services running our job in order to evaluate how the job is doing. See how MetricFire handles distributed monitoring in our article Introduction to monitoring Kubernetes. But, first let’s cover the basics.

Microapps … What are they?

A microapp, simply put, is an application that does one thing, and does it really well. It has a single focus of operation, aimed at getting users in, optimizing their experience as they perform that task, and getting the task done quickly and efficiently. Before the microapp methodology was adopted, traditional business applications would usually consist of a large suite of functionalities, combined into a single interface. 

In-spite of how well such an application is designed, its sheer size can lead to quite a few problems, such as: slow load times when the apps are used on resource constrained devices, inability for users to quickly locate certain functionalities, or the sheer amount of time and business resources it takes to build such applications.

Although this may sound like a brand new concept, microapps have been around for a while and chances are you use one routinely without even knowing. Google set the trend in action when it started using artificial intelligence to display interactive cards in response to certain search queries, for example, weather based queries that display a card like the one below:

Microservices

Microservices or the microservice architectural style is a development methodology wherein a single application is built out as a suite of small services, each running in its own process independently and communicating with lightweight mechanisms, often an HTTP resource API. These services are built to meet specific business or application needs while ensuring they are independently deployable by fully automated deployment machinery.

Microservices are essentially the opposite of monoliths, which used to be the application architecture pattern of choice. A monolith application is built as a single, autonomous unit. As such, making changes to the application is slow as it affects the entire system, no matter how small the changes are. This is because modifications made to any section of code might require building and deploying an entirely new version of that application. Also, scaling specific functions of that application means you have to scale the entire application, not cool! 

On the other hand, the microservice architecture entails building an application as a suite of small services (microservices), with each service running in its own process and being independently deployable. They may be written in different programming languages or have different storage techniques which best optimizes the role they play in the grand scheme of things. This results in systems that are scalable and extremely flexible, easy to build and even easier to maintain. 

Monitoring microservices and apps compared to monolith apps requires a different monitoring approach. Check out one example of how Prometheus can be used to monitor a multiprocess multi-threaded web app here. Also, jump on to the MetricFire free trial, or book a demo to see how you can use MetricFire to monitor your microservices. 

Differences and Overlaps Between Microapps and Microservices

Judging from the above content, microapps and microservices sound very similar. They both seem to decouple complex functionalities into simple, more manageable pieces of software. So why are they referred to as different things? 

Microservices refers to services that run between the front end and the back end, communicating with each other by means of the REST API. They typically work under the hood of an application, performing tasks that aren’t immediately visible to the end user. They allow developers the freedom to quickly and independently develop and deploy services that achieve specific tasks, without disrupting other running services. It also allows for the development of services that are tailored for specific tasks, while ensuring fault toleration (when a single service fails, only that service needs to be fixed and redeployed without significant disruptions to the entire application). 

On the other hand, Microapps have a UI aspect to them. They are entire applications on their own, which interact with users to perform one task efficiently. This one application would more than often be made up of a number of services (possibly microservices) which work together to achieve the ultimate end goal. So it’s possible we can have a microapp, which focuses on a single user interaction task, and under the hood, multiple microservices working independently, but in sync, to ensure the efficient completion of this task. 

An easy way to differentiate between microapps and microservices is that a single microservice usually does not have a lot of meaning for an end user. An end user can not use a single service to perform a task. In order to interact with users, these services would have to be aggregated into an app, a microapp, working together to perform a unified goal, with that goal being the sole purpose of the app.

Microapps and microservices share common advantages in that they decouple applications into simple, manageable and independent parts, allowing developers to work on each of these parts in isolation. They allow developers to perform code fixes, updates and deployments very quickly, without affecting the health of the other parts of the application. 

This separation of concerns also results in an important feature, fault isolation. With such an architecture, a faulty service can easily be isolated, fixed and deployed without affecting any of the other running services, and without compromising the application as a whole. This means rapid turnaround between the identification and resolution of bugs. There are other amazing benefits to this architecture, feel free to check out this microservice article for more!

What’s Next

If you are running an app built on microservices and microapps, you need to take care to design your monitoring strategy appropriately. Take a look at this article on how to monitor distributed monitoring in a kubernetes environment for more insights on how to handle it. We also have resources on how to build optimal docker images, and monitoring microservice logs with Fluentd and Elasticsearch to help with your overall microservice/microapp design.

Sign up for the MetricFire free trial and experiment with monitoring your microservices and microapps. If you have any questions about how to design your monitoring strategy, book a demo and talk to us directly about what MetricFire can do for your company.