#94_spike_microservice_and_docker
Andrew Davis
11/4/19
Report (this document) on
- What a microservice is in comparison to a monolithic service.
- What problem they try to solve/what benefits do they provide
- What a container is
- How containers are relevant to microservices
- What is Docker
A monolithic service is a collection of tightly coupled components joined to create a greater product or system.
A microservice is a software development architecture related to a service oriented design. The concept is we greater a greater product or system by composing it of many individual loosely coupled services that are able to communicate and serve each other. In a microservice architecture it captures the Unix Philosophy of each program should do one thing and do it well, not add extra features. The output of a program should be designed to be the input of another.
Take for example this diagram for an online shopping service.
In a monolithic structure, the shopping service would encompass all the yellow blocks internally. Often with monolithic database with individual tables.
In the microservice approach there is a single gateway, which then relies on 4 different services to perform different functions including querying and updating databases.
From the perspective of our project. In a monolithic architecture, the Fetcher would be created a single program, using a single programming language all compiled together. With components at best being made into libraries for the overarching program to call. Instead our fetcher will resemble the online shopping service example as a gateway, relying on different services to function.
Services typically communicate with each other over a network. If they aren't meant to be accessible to the public internet directly they can be mapped to private IP addresses.
Problems facing a team credit microservices.io
There is a team of developers working on the application New team members must quickly become productive The application must be easy to understand and modify You want to practice continuous deployment of the application You must run multiple instances of the application on multiple machines in order to satisfy scalability and availability requirements You want to take advantage of emerging technologies (frameworks, programming languages, etc)
New Developer Benefits:
By using microservices, if the service has well defined inputs and outputs, a new developer can grok its purpose quickly, the code base is smaller so it can be understood faster, it is more easily testible because the inputs and outputs are well defined, this allows for rapid development and deployment with confidence it won't break the overarching system.
Scalability Benefits:
Because each service is independent in can be run on a separate machine allowing for performance scaling, or if that isn't sufficient because it is used via a network multiple instances of a service can be instantiated across different machines and placed behind a load balancer.
New Technology Benefits:
Because a microservice is utilized over a network they become programming language and framework agnostic. For example if the service uses a REST API, almost all mainstream programming languages will have libraries available with REST APIs. Therefore it becomes possible for each microservice to be developed using a different language. This can create benefits based on team experience with certain languages, libraries available to solve problems or a languages performance characteristics.
For example imagine a monolithic service written in Python so it can be rapidly developed. One component has a hot path that generates a lot of objects and garbage. The performance characteristics of Python in this hot path are not acceptable and creating a problem. Calling out to other languages is often fraught with peril, requiring complex glue code cutting again the performance benefits.
If the above project were created with a microservice architecture, after identifying the slow component the team can investigate alternatives. If the team discovers Rust is a better language because of its high performance, memory safety without a garbage collector and thread safety guarantees etc then the component can be re-written in Rust, and then slotted into the system as a replacement.
Assumption. Those reading this document know what a (hardware) virtual machine is.
When deciding to virtualise, you must first decide where in the stack of abstraction to virtualise. In the case of VMWare, KVM, Hyper-V the decision is to virtualise the hardware, allowing a single machine to run multiple different operating systems on a virtual (fake) CPU, memory disk etc as a process on a host operating system.
A container is a virtual machine, only instead of virtualising the hardware instead the operating system is virtualised. The benefit of this is it removes the abstraction of physical hardware. See diagram:
In the hardware VM, when a program wants to perform disk I/O it has to make a system call to write to a file, the guest operating system then writes filesystem on a virtual disk, create a supercall to the hypervisor, which then writes to a file backing the the guest hard drive by making a system call, where the host operating system writes to the filesystem sending the write to the physical device.
In OS level virtualisation the virtualised system can perform I/O with the same level of abstraction as any process running on a machine that isn't virtualised reducing the overhead. There are other performance benefits to do with resource allocation but are out of scope here.
Containers can also provide isolation (and typically do). For example if a service were compromised, an attacker would find themselves inside a jail cell, only able to infect or take over a small part of the system.
For our project the benefit of the virtualisation happening at the OS level is if we are limited to X number of hardware virtual machines (ie through Nectar) we can deploy numerous containers on the one instance.
Example. A startup company designs their product using microservices, their initial funding only affords them servers (or perhaps only 2 hardware virtual machines on a cloud provider) until they can attract customers, which will provide financial resources to scale. With a microservice architecture they can run each of these services inside a container, and up to as many as the hardware available can run on a single hardware virtual machine. Enabling their microservice architecture design while running them all on a single system like a monolithic service. Then when under the demand to scale, they can move these containers to independent instances.
Docker is a container based deployment and development system using Linux namespacing primitives to create a secure virtual machine. Docker has taken the world by storm, heavily utilised by companies like Google, promoted by Red Hat, Canonnical (Ubuntu creators), IBM, and all major cloud providers supporting Docker deployment (AWS, Azure, Joyent, etc). And according to numerous articles published on cloud statistics, Docker is the faster growing DevOps tool..
In terms of providing a secure container runtime, Docker doesn't do isolation any different or better than the container technologies that came before it (see FreeeBSD jails, Solaris Zones, etc). So what does Docker add to the equation.
Docker isn't just about virtual machines at a different layer of abstraction. It is targeted as much as developers as is it system administrators. Docker is a new packaging format that can be deployed directly. When packaging up applications, a developer will have to provide instructions for deployment, what dependencies are required, it needs library foo v2, but it breaks with v2.2. And the developer could be using CentOS, but a client might want to use Ubuntu. Which led to conflicts with how the dependencies are packages, what build flags are on etc. Then system administrators were then left to install the software and resolve DLL hell.
What Docker does differently is a developer specifies all the dependencies, including their version numbers, build flags, configurations etc. When building the application it is bundled into a filesystem image along with ALL its dependencies. The image is immutable, therefore when an administrator deploys the application it will be deployed as the developer intended in the environment it was developed against. I firmly believe Docker will to do apt (Debina/Ubuntu package manager) and RPM (Red Hat packages) what they did to source tarballs.
Docker images can then be uploaded to repositories for users to then pull. For example a hello world container
#docker run hello-world
Docker will look locally if the image has already been download. If it hasn't it looks in the configured repositories (Docker Incs public repo is configured by default) and search for an image with that name then downloads it. Finally it instantiates it.
Docker pairs with Microservices. Each Docker container is started by running ONE binary within the container, this can be a script to run multiple things but this is considered an anti-pattern. Notice how this pairs with microservices? A single image, to run a single binary, that does one thing well and one thing only.
Using microservices lowers the complexity for the developers reasons mentioned in section 1 and 2. However, when orchestrating many instances there is an additional load put on operations to deploy and coordinate them.
For a project of our size, the benefits of Docker versus other container systems such as FreeBSD jails or LXC, which are administered similar to traditional virtual machines. From a development standpoint we as a team need to learn how to deploy software to a *NIX server, whether this is Docker or targeting a RPM package will require time to up-skill ourselves. Docker makes sense as orchestration frameworks exist to help with Microservices, .net Core and Visual studio can target Docker.
And from a selfish perspective of team members, industry want graduates who know how to use Docker, AWS so becoming comfortable with these technologies will benefit our future careers.