- Bernd Zuther
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
Martin Fowler - http://martinfowler.com/articles/microservices.html
bz@cc:~/$ ar t cart_0.6.20.deb debian-binary control.tar.gz data.tar.gz bz@cc:~/$ tar tzf data.tar.gz ./etc/default/cart ./etc/init.d/cart ./usr/share/shop/cart/bin/cart ./usr/share/shop/cart/bin/cart.bat ./usr/share/shop/cart/lib/cart-microservice-0.6.20.jar bz@cc:~/$ tar tzf control.tar.gz ./postinst ./control ./md5sums bz@cc:~/$ cat debian-binary 2.0
Source: shop-cart-service Section: web Priority: optional Version: 4.2.42 Maintainer: Bernd ZutherHomepage: http://www.bernd-zuther.de/ Vcs-Git: https://github.com/zutherb/AppStash.git Vcs-Browser: https://github.com/zutherb/AppStash Package: shop-cart-service Architecture: amd64 Depends: redis-server (>= 2.8.13) Description: Cart Service
reprepro -Vb /var/packages/debian includedeb shop /tmp/*.deb reprepro -b /var/packages/debian/ export reprepro -b /var/packages/debian/ list shop
--- - apt_repository: repo='deb http://ci-repo/debian/ shop main' state=present - apt: update_cache=yes force=yes - apt: pkg={{item}} state=present force=yes with_items: - shop-cart-service
Pro | Contra |
---|---|
Service Repository | No Service Discovery |
Dependency Management | Runtime enviroment must be created on every single node |
Technologies are battle-tested | Depends on the linux distribution |
FROM relateiq/oracle-java8 MAINTAINER Bernd Zuther <bernd.zuther@codecentric.de> EXPOSE 18080 ADD product-0.6.tar / ENTRYPOINT ["/product-0.6/bin/product"]
bz@cc1 $ docker build -t zutherb/product-service . bz@cc1 $ docker push zutherb/product-service bz@cc2 $ docker pull zutherb/product-service bz@cc2 $ docker run zutherb/product-service bz@cc2 $ docker ps CONTAINER ID IMAGE COMMAND CREATED 87bb5524067d zutherb/product-service:latest "/product-0.6/bin/pr 14 seconds
bz@cc ~$ docker run -d --name mongodb mongo 705084daa3f852ec796c8d6b13bac882d56d95c261b4a4f8993b43c5fb2f846c bz@cc ~$ docker run -d --name redis redis 784ebde0e867adb18663e3011b3c1cabe990a0c906396fc306eac669345628cf bz@cc ~$ docker run -d -P --name cart --link redis:redis zutherb/cart-service 438b2657c7a5c733787fb32b7d28e1a0b84ba9e10d19a8a015c6f24085455011 bz@cc ~$ docker run -d -P -p 8080:8080 --name shop --link cart:cart \ --link mongodb:mongodb zutherb/monolithic-shop 9926e187faa215ac9044603d51adbd8d679d8076b4a349ebbc9917dade6d560e bz@cc $ docker exec 9926e187faa215ac9044603d51adbd8d679d8076b4a349ebbc9917dade6d560e env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=87bb5524067d MONGODB_PORT_27017_TCP=tcp://172.17.0.28:27017 MONGODB_PORT_27017_TCP_ADDR=172.17.0.28 MONGODB_PORT_27017_TCP_PORT=27017 MONGODB_PORT_27017_TCP_PROTO=tcp
redis: image: redis ports: - "6379:6379" cart: image: eshop/cart-service ports: - "18100:18100" links: - redis catalog: image: eshop/catalog-frontend ports: - "80:80" links: - product - cart
Pro | Contra |
---|---|
Applications are isolated | Daemon runs as root on host |
Images are built once and run anywhere | No Process Supervisor |
Docker Repository | No Service Discovery |
Big ecosystem (Kubernetes, Mesos, Vamp) |
Pro | Contra |
---|---|
Only using Docker API | No Process Supervisor |
Description of the whole application | No Service discovery (Hosted Discovery is not recommended for production use) |
You needn't care where work is executed | Failure analysis will get harder |
You needn't care about dependencies | Routing must be implemented by hand |
apiVersion: v1 kind: Pod metadata: labels: name: cart role: backend name: cart spec: containers: - name: cart image: zutherb/cart-service ports: - containerPort: 18100
apiVersion: v1 kind: ReplicationController metadata: ... (labels) spec: replicas: 2 selector: name: cart template: metadata: ... (labels) spec: containers: - name: cart image: zutherb/cart-service ports: - containerPort: 18100
kind: Service apiVersion: v1 metadata: labels: name: cart role: backend name: cart spec: ports: - name: cart port: 18100 selector: name: cart
Pro | Contra |
---|---|
You needn't care where work is executed | No description of the whole application |
You needn't care about dependencies | Failure analysis will get harder |
Service discovery | Master is a single point of failure |
Process Supervisor | Routing must be implemented by hand |
{"id": "basic-3", "cmd": "python3 -m http.server 8080", "cpus": 0.5, "mem": 32.0, "container": { "type": "DOCKER", "docker": { "image": "python:3", "network": "BRIDGE", "portMappings": [ { "containerPort": 8080, "hostPort": 0 }]}}}
curl -X POST http://10.141.141.10:8080/v2/apps -d @basic-3.json \ -H "Content-type: application/json"
Pro | Contra |
---|---|
You needn't care where work is executed | No description of the whole application and for deployment scenario |
High Availability | No Service Discovery |
Process Supervisor | Failure analysis will get harder |
Many tools and documentation are available |
Pro | Contra |
---|---|
Description of the whole application and for routing scenario | Many components have to be understood |
You needn't care where work is executed | Failure analysis will get harder |
High Availability | |
Process Supervisor | |
Service Discovery |
Docker Daemon | Docker Swarm | Kubernetes | Mesos | |
---|---|---|---|---|
Service Repository | ||||
Orchestration |
(< 100) |
|||
Scheduler | - | Docker Compose | API Server | (Vamp+) Marathon/Chronos |
Ressource Allocation | - | Swarm Master | Kublet Info Service | Mesos Master |
Executor | - | Swarm Agent | Kublet | Mesos Slave |
High Availability | ||||
Routing Definition | ||||
Use Cases |
Single Application Microservice Application Web Application |
Distributed Microservice Application | Distributed Microservice Application |
Distributed Microservice Application Big Data Kubernetes / Docker Swarm |