226
F. Firouzi and B. Farahani
services written in different frameworks and languages. Individual microservices
are mini applications with their own monitoring, resource, and scaling needs. In
addition, each service must have the appropriate memory, CPU, and I/O resources.
Below you will find different approaches used to upload and run services [30].
• Multiple Service Instances Per Host – A more traditional application deployment
approach, requiring the developer to provide one or more hosts (either virtual
or physical) and then run several service instances on each host. Benefits of
this approach include quick deployment and efficient resource usage because
the server and OS are shared among multiple service instances. This approach
provides little to no service instance isolation unless a service instance is
designated as a separate process, which is a large drawback for this approach.
• Single Service Instance Per Host – Each service instance is run separately on its
individual host. Two variations of this approach include:
– Service Instance Per Virtual Machine – Each service is bundled as a virtual
machine (VM) image and then initiated via VM. The details of VMs will be
discussed in Sect. 4.10.
• Benefits – Because the service instance is isolated, it uses only an isolated
set amount of memory and CPU and does not rob resources from other
services. Each microservice can also be monitored, maintained, managed,
and scaled separately.
• Drawbacks – Deployment new service versions can be slow, resources
are used less efficiently, and each service instance requires an entire VM
increasing the overhead of the system. Note that each VM has its own
operating system (guest operating system), and thus its overhead is high
(see Fig. 4.36).
– Service Instance Per Container – Individual services run in separate containers. The details of the containers will be addressed in Sect. 4.10.
• Benefits – Service instances in containers are isolated from each other. Similar to VM the underlying technology is encapsulated; container resource
usage can be monitored. Each microservice can also be monitored, maintained, managed, and scaled separately. Since containers do not need to
have an operating system, they can be built and started quicker than VM
(see Fig. 4.36).
• Drawbacks – Infrastructure lacks the maturity of VM infrastructure, and
the level of container security is lower because host OS is shared among
containers.
• Serverless Deployment – The terms of serverless and Functions as a Service
(FaaS) are usually used interchangeably, although this distinction is still being
defined by the tech community. The idea of FaaS is dividing the microservices
into fine-grained functions and then deploying those functions to a third-party
company which charges the application owner only based on the amount of time
each function runs (i.e., serverless deployment). In other words, in serverless
F. Firouzi and B. Farahani
services written in different frameworks and languages. Individual microservices
are mini applications with their own monitoring, resource, and scaling needs. In
addition, each service must have the appropriate memory, CPU, and I/O resources.
Below you will find different approaches used to upload and run services [30].
• Multiple Service Instances Per Host – A more traditional application deployment
approach, requiring the developer to provide one or more hosts (either virtual
or physical) and then run several service instances on each host. Benefits of
this approach include quick deployment and efficient resource usage because
the server and OS are shared among multiple service instances. This approach
provides little to no service instance isolation unless a service instance is
designated as a separate process, which is a large drawback for this approach.
• Single Service Instance Per Host – Each service instance is run separately on its
individual host. Two variations of this approach include:
– Service Instance Per Virtual Machine – Each service is bundled as a virtual
machine (VM) image and then initiated via VM. The details of VMs will be
discussed in Sect. 4.10.
• Benefits – Because the service instance is isolated, it uses only an isolated
set amount of memory and CPU and does not rob resources from other
services. Each microservice can also be monitored, maintained, managed,
and scaled separately.
• Drawbacks – Deployment new service versions can be slow, resources
are used less efficiently, and each service instance requires an entire VM
increasing the overhead of the system. Note that each VM has its own
operating system (guest operating system), and thus its overhead is high
(see Fig. 4.36).
– Service Instance Per Container – Individual services run in separate containers. The details of the containers will be addressed in Sect. 4.10.
• Benefits – Service instances in containers are isolated from each other. Similar to VM the underlying technology is encapsulated; container resource
usage can be monitored. Each microservice can also be monitored, maintained, managed, and scaled separately. Since containers do not need to
have an operating system, they can be built and started quicker than VM
(see Fig. 4.36).
• Drawbacks – Infrastructure lacks the maturity of VM infrastructure, and
the level of container security is lower because host OS is shared among
containers.
• Serverless Deployment – The terms of serverless and Functions as a Service
(FaaS) are usually used interchangeably, although this distinction is still being
defined by the tech community. The idea of FaaS is dividing the microservices
into fine-grained functions and then deploying those functions to a third-party
company which charges the application owner only based on the amount of time
each function runs (i.e., serverless deployment). In other words, in serverless