Micro service separation

Posted by zo0ok on 2019/04/04 Leave a comment (0) Go to comments

Lets say we have a simple service that we can start:

$ ls
my-service my-data
$ ./my-service -d my-data -p 8080

As we interact with the service over HTTP on 8080 it stores data in the my-data folder. This may seem simplified but it is basically how any network (web, file, directory, database and so on) service works.

Micro Services

Lets say you have 4 different such services responsible for different things (like html/UI, storage, log and authentication) and they work together: well you basically have a Micro Service architecture.

All your different services can have a binary and a data folder. They can all exist in the same folder. You can start, stop and update them independently. If a service is “heavy” you can can run several instances of it. The services need to know about each other and listen to different ports, but that is just a matter of configuration and it can be automated.

Separation of micro services

While the simple approach above works (and it works surprisingly well), you may run into issues such as:

you want to be sure two services can’t mess with each others data
a service may be heavy and should run on separate hardware
the services have common dependencies but it must be possible to update them separately (dll hell)
the services may not even run on the same operating systems
two services may use some resource that would cause a conflict if they shared it (say both use the same windows registry keys)
different teams may be responsible for different services, and they shall neither be able to mess with each other, or blame each other

Clearly, running all services on the same computer, as the same user, in the same folder is not good enough in these scenarios. What options do we have?

Separate Hardware

Traditionally, especially in the Windows world, each service got its on computer (I refer to custom application services, clearly Windows itself comes with multiple standard services running).

In Windows, you typically install something with an install Wizard. It updates and stores stuff in different places in the system (Registry, Windows folder, Program Files and perhaps more). Multiple services may not coexist completely safely. So each get a Windows server that you backup entirely in case of disaster. This is expensive, wasteful and complicated.

Virtual Machines

VMWare was founded in 1998 and VMWare workstation was released in 1999. It changed everything, especially on Windows. Instead of having multiple computers you could have one physical computer running multiple virtual computers. Such a virtual computer “thought” it was a real computer. It needed special device drivers for the virtual hardware it ran on.

This is great. But you end up duplicating megabytes, perhaps gigabytes of system files. Installation and configuration of a computer is not trivial. Even if you automate it there are many details that need to get right. And a virtual computer may need to swap/page, and does so to what it thinks is a physical drive, but it is just a file on the host computer.

Just different users

You may run your different services in the home directories of different users. In theory that could work in Windows, but it is a quite unlikely setup.

In *NIX it would mostly work fine. You can have multiple terminals and log in as multiple users at the same time. If you are root you can easily write scripts to become any user you like, and execute whatever you want in their home directory.

Also, in *NIX most software can actually be built, installed and run in a regular user home directory. Often you just build and install as the regular user:

$ ./configure --prefix=/home/service01
$ make
$ make install

Basically, *NIX is already Micro Service-ready.

Chroot

For some purposes, running in a home directory may not be optimal. Instead, you may want to run the application in an environment where everything it needs, and nothing else, is in / (the root). There is a command called chroot that allows you to do this.

But chroot is not perfect. First it is not entirely safe (there are ways to break out of it). Second, you need to populate /bin, /lib, /etc with everything you need, and that may not be obvious. And you will only run the service in the chroot – the administrator or devops team need to access the computer normally, and they are not restricted to or don’t just see the chroot.

Containers

While all the above methods can be made to work for a microservice architecture, much effort has been made to come up with something even better, especially for deploying applications to the cloud: containers.

Containers and the tools around them focus much on development, deployment and automation. They are made for DevOps. It is cheap to configure, create, run and discard containers.

Application containers (Docker) are quite similar to a chroot, but they exist on Windows too. It is about putting everything an appliation needs, and nothing else, into the container so you can easily move, reconfigure it, duplicate it, and so on without touching your operating system itself. The issue of having exactly the right OS version, with the right patches, and the right versions of the right dependencies installed is much simplified when you can create a stable container that you can run on any machine capable of running containers.

System containers (LXC) are quite similar to a virtual machine. But while a virtual machine emulates hardware and runs a complete kernel, a system container just emulates a kernel (that may require some contemplation). It has all the advantages of a Linux virtual machine on Linux, but less of the costs.

Conclusion and Summary

Containers are popular, and for good reasons. But they are also a bit hyped. In the end of they day, you have your service code, and when you run it, it (perhaps) works on local data. That is it. You can separate, scale, isolate, secure, manage, deploy, monitor and automate this on different levels: