The Technology Behind Microservices: How It Works

Alex Tarasenko
Alex Tarasenko

In the previous article, we talked about microservices and the nuances of such product design from a general perspective. Now, it’s time to dive deeper and examine the actual technological component behind the revolutionary software architecture, in detail.  

Just like monolithic apps, modular software can be built with a wide range of coding languages and frameworks. Therefore, most of the rules for choosing the basic development technology apply here as well. That being the case, a microservices tech stack is effectively larger and much more versatile than that of traditional software. 

Loosely-coupled apps are very complex structure-wise. So, many aspects of the system’s cohesiveness have to be thought through before jumping into the whirlpool of the dev process. 

In our case, it is worthwhile to go over all of it gradually – one functionality at a time. So, let’s jump in!


First of all, any software has to run somewhere. 

There are three main hosting options to consider for microservices: 

  • Local server – a traditional enterprise computing model. Companies maintain equipment and software in a confined data center, having direct control over its operation. 
  • Public cloud – a rather modern approach. Here, shared computing resources are provided over the internet and are managed on the side of the cloud provider. We’ve already written about on-demand software recently. 
  • Private cloud – offers opportunities similar to the public cloud. In this case, though, companies own and manage remote server capacity in-house (for security or compliance reasons, mostly).
Hosting models

It should be noted that there are also hybrid cloud-hosting solutions, but that is a topic for another blog post…

In most cases, public cloud hardware is the go-to choice for running microservices. It offers virtually unlimited processing capabilities on rather flexible terms. 

And while there is an array of remote infrastructure providers, the most popular of them are represented by: 

  • AWS (Amazon Web Services) 
  • Microsoft Azure
  • Google Cloud Platform 
  • Oracle Cloud
  • Pivotal   

VMs & Container Management 

Now, there are two principal ways of using cloud resources – virtual machines and containers (each containing individual functionality). 

Both use remote hardware to perform tasks. Now, VMs emulate entire systems along with the operational systems. Whereas containers share the OS and therefore have a lot of common functionality that needs not be executed separately. 

This saves a ton of resources, providing a tenfold launch-time difference and a major cut in RAM and CPU usage, in favor of containers, of course. Having less overhead and close to zero weight, it is a much more favorable environment for complex applications. 

However, while it’s very convenient to have individual containers for each of the services, it is another challenge to successfully manage it all. Crucial tasks like automation of deployment, scaling, and networking, add up to the complexity of running loosely-coupled software. 

This is where container orchestration tools come in handy, effectively tackling these kinds of issues. 

In this regard, the most popular choices on the market are: 

  • Kubernetes
  • Docker 
  • Apache
  • Other solutions from major cloud providers like Amazon, Google, and Azure.   


We have already learned that microservices allow using different tech for individual software components. 

On one hand, this gives the flexibility to assign the best-fitting technology for tackling different tasks within the system. On the other, however, it requires establishing effective interaction between those app components. 

This is exactly what a service mesh is there for.

A dedicated infrastructure layer, it enables the services to interact with each other via local “sidecar” proxies instead of calling each other directly over the network. In essence, it is an interpreter between services that often “speak” different programming languages.

service mesh illustration

Service mesh facilitates horizontal (service to service) communication, as opposed to the API gateways that control vertical (client to server) networking. It is also different from container orchestration tools, which are responsible for resource management only. 

Some of the widely-applied service mesh solutions include: 

  • Istio
  • Linkerd
  • Consul
  • App Mesh

Moving on.


When designing modular apps, it is crucial to determine how clients (not to misunderstand with customers) will communicate with the system. 

Typically, this task is executed via APIs. 

API stands for Application Programming Interface. It enables the communication between two systems (for example – your laptop and an app), determining the data transfer protocol. Something like a moderator of the client to service conversation who ensures that the message “gets through”. 

APIs operate via ‘requests’ and ‘responses’. When a system receives a request it returns a response. The destination of that response represents an endpoint – essentially, one end of a communicational channel between a server and an external device. 

Now, what comes down to one communication channel in a monolithic app, may generate an array of those in microservices. This is because splitting software into multiple pieces implies that a single client request may call for separate responses from the services, resulting in multiple endpoints. An API gateway sorts it all up by providing a single point of entry into the system…

Ok, I know that just spilled over the sane limit of tech terms per paragraph. 

Let’s break it down. 

API Gateways made simple

Imagine a typical blog page. It contains a text field, a list of recommended articles, a comment section, a login form, a sharing functionality, etc.

In microservices, a separate module owns each of the described components’ data sets. So, when you open up that page you actually communicate with a set of micro-apps. 

If these calls were direct, your browser would have to send separate requests at all of those services (each with an individual web address) in order to assemble the page. For a number of reasons that furtherly exceed this article’s threshold for heavy terminology, such an option is inefficient. You may read about network latency here

Another option is to have a distributing entity to sort through multiple client requests and return a single, “comprehensive” response. Kind of like the packing assistant in a grocery store. You know, the one gathering your stuff while you talk to the cashier and check out – to save everyone time. 

That’s API getaways. 

API illustration

Some of the best API Gateway solutions are provided by Amazon, Ambassador, Kong, Microsoft, Akamai, Mulesoft, Google, and Express.


Privacy issues accompany any IT product development process. 

At that, the nature of microservices poses an elevated threat of security breach, putting additional pressure on software architects.

More so, securing the containers in which microservices run joined the list of industry’s main data-protection challenges in 2018. 

This is happening for two reasons. 

For first, it is a well-known fact that a system’s complexity is inversely proportional to its reliability. This is especially true when it comes to software vulnerabilities. Increased interaction between microservices comes hand in hand with additional communication channels – which means more points of potential penetration.  

To make things worse, microservice apps are often hosted along with third-party software, on the same physical server. Even the word combination “shared environments” does not sound too safe. Forget about the multitude of less obvious ways things can go wrong in a complex cloud infrastructure hosting disintegrated software.  

Luckily for IT enterprises, there are solutions for these issues, too: 

  • Twistlock
  • Tigeria
  • Aopreto
  • Aqua

Other Middleware

Last but not least on the list of the main technologies behind microservices is the so-called middleware. These tools are responsible for additional coherence-related tasks like load-balancing, proxies, caching, and routing. While somewhat similar to the already mentioned gateways, it doesn’t expose microservices as an API does. 

In terms of microservices middleware, these are the market leaders: 

  • NGINX 
  • Envoy
  • Zuul
  • HA Proxy 


To sum up the topic, the array of technologies backing microservices-based apps is stunningly huge, to say the least. From design and implementation to deployment and maintenance – versatile program tools are there at one’s aid on every step of the microservices development process. 

Looking at all this material, it should cease to impress the reader why, although considered advanced and convenient, this approach is highly resource-demanding and far more complex than traditional program development techniques.