Jour of Adv Research in Dynamical & Control Systems, 04-Special Issue, June 2017
Microservice Design for Container based Multi-cloud Deployment Baskaran Jambunathan, Research Scholar, Vels University, Chennai, India. E-mail:
[email protected] Dr. Kalpana Yoganathan, Asst. Professor, Vels University, Chennai, India. E-mail:
[email protected]
Abstract--- Micro services are increasingly getting popular in today’s world as it provides flexibility for the developers and Architects to build an application for distributed environments. Microservice design has its own advantages and challenges and has a definite need to bring some standardization in design. Design patterns, in general, help developers to adopt this stands and enable them to bring some uniformity in their application design. Design patterns are traditionally used to bring standardization in the development process and follow best practices to avoid redundancy, improve productivity and minimize errors in the development process and help developers to create quality applications to bring uniformity across various system developments. We attempted to bring standardization in microservices design and build application for distributed systems to collaborate and scale efficiently and address the business needs. We would like to understand and analyze these design patterns for microservices and how it helps in modern deployment needs on multi cloud environments and its challenges. Keywords--- Microservices, Dockers, Design Patterns, Cluster Management, Kubernetes.
I.
Introduction
Over the years, architects and developers are used to design and build large monolithic applications for any application development. Evolution happened in making these applications as more modular, scalable and reusable with service oriented architecture (SOA) and design. While SOA has improved the design better, it also had lots of issues and challenges in terms of build and deployment when the size of the application becomes large and distributed. Every change in the components demand complete rebuilds and deployment and it also impacted the dependent components when we make changes in the application. Micro services are the new evolution in software design, address the above problem statement to a large extends. Micro service is an isolated, loosely-coupled unit of development that works on a single concern. Micro services are independent and are attractive to development teams because of independent in nature. One can develop micro service in their own language of comfort and can integrate and communicate with each service seamlessly. The merits and demerits of micro services are discussed in our earlier article. Containers[1] are the light weight component in nature as against virtual machines. It is light weight because the Operating system isshared across containers and only the runtime libraries, binaries and dependencies are part of containers. Containers are designed to contain the complete deployment unit for an application to allow for automation, version tracking and rapid deployment. There are many types of containers available but Docker [1] container is the most popular and widely accepted in the industry. Docker image has these application dependencies in this container along with the application.Docker makes application portability and deployment easier and easy to move across multi cloud deployment.
Figure 1: Container Architecture
ISSN 1943-023X
1
Jour of Adv Research in Dynamical & Control Systems, 04-Special Issue, June 2017
Today everyone is looking for deploying applications with different cloud service provider and do not want to get struck with one vendor to avoid vendor lock-in. Industries are looking for flexibility in moving applications across cloud services and minimize the language dependencies, increase portability with ease, deploy and manage applications with less effort across multiple cloud platforms. In this article we would like to discuss on how to design micro services in modularizing the application, deploy services acrosscontainersand logically group them in the form of cluster of containers. These cluster in a distributed multicloud environment are effectively managed through using kubernetes[1].
II.
Monolithic to Microservice
Over the past decades, developers are used to writing application on monolithic fashion. Developers are used to write the application in multi-tier architecture and with SOA, services are extracted and implemented at the most. As the size of the application grows, monolith applications are difficult to understand, impacted developer productivity and scaling of application becomes difficult. There are lots of challenges for the developers in accepting changes in application as the entire application has to be rebuilt and deployed, continuous integration and deployment becomes more difficult and time consuming. Moreover, developers are married to a single technology stack, finding difficult to adopt incremental technology changes.
Figure 2: Monolithic to Microservice Microservices are designed for distributed systems where scalability and reliability are the key aspects to be considered. These systems needs finely grained services with their own lifecycles management, which in turn collaborate together to accomplish a particular task or functionality. In general, microservices are modeled around business domains; they avoid the problems of traditional multi-tiered architectures. Microservices also adaptive, flexible and can easily be integrated with any new technologies and techniques that have emerged over the period of time, which helps them, addressing key risks and issues of many service-oriented architecture implementations. Following are the key benefits of microservices: • • • •
Everyapplication is kind of decomposed into a set of collaborating services and itimplements a set of closely associated functions addressing a particular business domain. Each servicecommunicates with one another, either in synchronous or asynchronous protocols. Services are developed and deployed independently and each services can be developed in different programming languages and can be integrated Every one of the service has its own database which enables them to be decoupled from each other.
Figure 3: Complexity VS Productivity Analysis for Microservices
ISSN 1943-023X
2
Jour of Adv Research in Dynamical & Control Systems, 04-Special Issue, June 2017
While there are many advantages with micro services, there are challenges as well in design and implementation • Developers has to deal with additional complexity of dealing with distributed system • Deployment complexity – deploy and manage different service types and testing becomes difficult • Increased memory consumption with N x M service instances (N services and M instance ) Designing microservices is the key challenge and is an emerging area in software industry. There are many approaches are being evolved and are available in industry. Some of the design principles are discussed below. Characteristics of Micro Services • Domain driven design:Functional decomposition of application based on the domain and the team responsible for building functions for that domain are responsible for building services for the domain with single technology stack. • Single Responsibility Principle: Every service in the system should address single part of the functionality and should have responsibility to address it completely. • Explicitly Published Interface:Every service will have its own published interface, which is exposed to outside world. The consuming service only have the view of those interfaces to interact and does not have any runtime dependency with consumed service. • Every service ideally can be deployed independently and does not have any dependency with overall system and have no impact. • Every serviceimplementation details are hidden and do not get exposed much to the outside world. This allows them to be decoupled completely from each other and help the team in building the services to decide on their own languages, tools, data persistence etc. • Each service will always communicate with another service using REST and HTTP which are a light-weight communication protocols.
III.
Microservice Design Consideration
Microservices are small services with independent lifecycles that work together. The challenge is how independent can you be when you have to be part of a whole and where to find the balance? Sam Newman – designed seven principles around designing micro services. Those are • • •
Microservices are modelled around Business domain to provide a more stable APIs, Uses more of Automation to manage lot more deployable units. It is more of independent and hide implementation details - to allow one service evolve independent of another. • It decentralizes all the details as much as possible to avoid any overlap. • Services are deployed independently so that any change to one service will not impact others. • Problem can be easily isolated and replaceable without impacting others in the system and avoid isolation failure. • It is easy to understand and how they behave and hence easy to observe its behaviours. Designing micro services is an evolving area in industry. Different researchers have identified methodologies, approach, patterns around micro services and have come out with their own techniques on design principles. The key considerations are identify and group the services, provide interface for effective communication between services, create service catalog and integration mechanism between services, Each services identified should have a complete domain context, bounded functionality and can be isolated and independent. We want related behavior to sit together and unrelated behavior to sit elsewhere. Services should be loosely coupled so that change in one service should not impact another. The whole point of a micro service is being able to make a change to one service and deploy it, without needing to change any other part of the system. This is really quite important. In order to design the effective micro service, one need to consider the subsystem & its dependencies, service discovery & wiring, service orchestration, effective communication between services, decentralized governance, and data management, strong in modularization, independence in deployment, design for failure, and technological diversity, Services should not share any state and also shouldn’t be any inter process communication. Communication should be asynchronous in nature using publish/subscribe mechanism.
ISSN 1943-023X
3
Jour of Adv Research in Dynamical & Control Systems, 04-Special Issue, June 2017
IV.
Design Pattern in Microservice
A pattern is a completely proven solution to a problem of a given context. Design patterns provide common solutions to most of the problems that arise when developing software within a particular context.It means that Patterns represents problems and solution in combination to address within a given context. Patterns also represent expert solutions to repetitive problems in a context and thus have been addressed at many levels of abstractions and in various domains. Design of micro services[7][8] should involve service discovery, service binding, service connection, service aggregation, failover, and exception handling. We would like to discuss the following in our approach on how do we identify, design integrate and communicate between services and how the deployment of services would be effective. Service Locator: Micro services as we discussed, are identified and designed based on the domain and context. Each service has their own data storage as well most of the time. These services are to be created and registered in service Registry and once can have their own service catalog. Consumer looking for any service can look for this pattern to locate the service, bind it and consume it in their application. This is similar to J2EE or SOA design pattern where request will be delegated to the service of interest, bound and consumed as per the requirement. Service Proxy: We can use this pattern is when multiple service requests are spawned from a single proxy. The proxy can behave like totally dump or a fully active one. In case of complete dumb proxy, it delegates the request to one of the services. In case of smart proxy, data transformation is applied before the response is served to the client at the proxy level. For example, in the smart proxy, one can encapsulate different services of the presentation layer leading to different backend devices effectively.
Figure 4: Service Proxy Pattern Service Aggregator: Aggregator services are normally used in two differentforms. One – it totally delegate the request to multiple microservices to achieve the desired functionality of the given application. For example, every web page can pull the data and process it accordingly, because of each service (Service A, Service B, and Service C) is exposed using a lightweight REST mechanism to the backend application. In another case, where there is no need to display at the front end, and instead a higher level composite microservice is to be consumed by other services. In such case, the aggregator would just collect the data from each of the individual microservice, apply business logic to it, and further publish it as a REST endpoint. This can then be consumed by other services that really needed it. In both the cases, each individual microservice has its own (optional) caching and database. If Aggregator is a composite microservice, then it may have its own caching and database layer within itself.
Figure 5: Service Aggregator Pattern
ISSN 1943-023X
4
Jour of Adv Research in Dynamical & Control Systems, 04-Special Issue, June 2017
Service Chain: Microservices can be made as a chain to produce a single consolidated response to the request. A chain with a single microservice is called singleton chain. This may allow the chain to be expanded at a later point. For example, Service A receives the request from the client, and is then callingwith Service B, which in turn may be communicating with Service C and so on. All the services are likely using a synchronous HTTP request/response messaging.
Figure 6: Service Chain Pattern Service Sharing: Some microservices in the form of a connected chain, might share caching and database stores. This kind of situation arises when there is a strong coupling between the two services. Some might consider this an anti-pattern although many business situations might require following this at times. For much green filed application that isdesigned to be developed with micro services needs these anti-patterns for sure.
Figure 7: Service Sharing Pattern Service Branching:Thisdesign pattern is the extension of Aggregator design pattern and allows simultaneous response processing from two, likely mutually exclusive, chains of micro services. This pattern can be applied to call either a single chain or multiple chains based on their business needs. For example, Service A, either a web page or a composite microservice, can invoke two different chains simultaneously in which case this will resemble the Aggregator design pattern. Alternatively, Service A can invoke only one chain based upon the request received from the client as well.
Figure 8: Service Branching Pattern
ISSN 1943-023X
5
Jour of Adv Research in Dynamical & Control Systems, 04-Special Issue, June 2017
Recursive Services: In this pattern, service A calling service B based on the event and subsequently service B calls service A and is recursive in nature. Such pattern or sparsely used and some limes leading to deadlock. We need to be careful in designing such services.
Figure 9: Recursive Service Pattern Coupling Service: This has two components a) request response and b) publish-subscribe. •
•
Request-Reply In this case, service A invokes another services B and look for information (or to take some action) and expects a response from Service B . The requesting service (ServiceA) needs to know what to asks and where to ask it and needs to be implemented asynchronously and can add some abstraction in place as well. Publish-subscribe: In this case, a service registers itself as being interested in certain information or events or being able to handle certain requests. The requested information or requests will then be delivered to it and it can decide what to do with it later.
Figure 10: Coupling Service Pattern Asynchronous Service: In some situation we may need to use both synchronous and asynchronous services together based on the business needs In such cases, Service A may call Service C synchronously which is then communicating with Service B and D asynchronously using a shared message queue. Service A -> Service C communication may be asynchronous; possibly using WebSockets, to achieve the desired scalability. A combination of REST request/response and pub/sub messaging may be used to accomplish the business need.
Figure 11: Asynchronous Service Pattern
ISSN 1943-023X
6
Jour of Adv Research in Dynamical & Control Systems, 04-Special Issue, June 2017
There are other patterns are under consideration and deliberation in terms of service validation which is the combination of interception filter and value object of J2EE design pattern. Service integration, service communication and service deployment are being discussed and will have defined patterns in future research. Since micro service design is under evolution more and more developer uses micro services would lead to more such pattern in days to come.
V.
Deployment of Service in Containers
Containers are the best fit to manage the microservices. Each container can hold a service or a group of services and are isolated. One can deploy a service in multiple containers and group them in a cluster. For example, the database can be in one container and the functionality can be in another container. The grouping of containers into a single logical unit is called Pods [2]. Docker [1] is ideally suited deployment model for microservices, as it isolates containers to one process or service. This intentional containerization of single services or processes makes it very simple to manage and update these services.
Figure 12: Container Management in Pods Design pattern can help in design these micro services, and can be deployed and grouped based on the pattern design so that they can be isolated and grouped separately as a group of containers in a Pod. The logical grouping of containers having a set of micro services, designed based on a particular design pattern, is grouped together and can function independently in a cluster. The ideal challenge in most of the situationis to find a way to manage a single service in a cluster. Or multiple instances in a service across hosts, or way to coordinate between multiple services on a deployment and management level.
VI.
Cluster Management Using Kubernetes
Kubernetes is a key cluster management tool, mainly designed for managing a cluster of Docker containers grouped together to address a particular tasks. Kubernetes are designed to do orchestration of services includes scheduling, distributing workload, and scaling at different level. Kubernetes are mostly lightweight, portable and modular in nature. Kubernetes, with help of Pods[1], takes the software encapsulation provided by Docker further. A Pod is a collection of one or more Docker containers with single interface features such as providing networking and file system at the Pod level rather than at the container level. Kubernetes has the concept called “labels” using which services and replication controllers (replication controller is used to scale a cluster) identify or select the containers or pods they manage. Following are the high level steps to be adopted in planning and designing microservice deployment in cluster of containers, deploy and manage using Kubernetes. • Containerize an application by creating Dockerconfig files. • Used to buildideal processes to produce all the necessary Docker images that can be stored and managed. • Configure and launch an auto-scaling, self-healing Kubernetes cluster. • Use Kubernetes to manage deploying, scaling, and updating your applications • Employ best practices for using containers when architecting and developing new microservices. In general, Containers provides options to isolate and package the applications along with their dependencies. Dockers provide a simplified deployment model for our micro services. Wercker is another tool for building, testing and deploying in the modern world of microservices, containers and clouds. One can choose the best tool for packaging and containerizing based on the business needs.
ISSN 1943-023X
7
Jour of Adv Research in Dynamical & Control Systems, 04-Special Issue, June 2017
VII.
Deploy and Manage in Multicloud
Grouping of containers in the form of pods and in a kubernetes one or more such pods can be deployed. The cluster of containers can be deployed across different zones of a sing cloud services or different zones of the same cloud service or different cloud services as well – one cluster in AWS and another in Azure and so on.
Figure 13(a): Cluster Management with Single Kubernetes Cluster
Figure 13(b): Multiple Kubernetes Cluster Based on microservice design and functionality, they are Grouped and deployed in different zones. Kubernetes supports single cluster or multiple clusters in the same or different zone. Federation allows combining of kubernetes cluster running across different region or cloud. Multizone support is deliberately limited: a single Kubernetes cluster can run in multiple zones, but only within the same region (and cloud provider). Only Google and AWS are currently supported automatically. Following are the cluster management in single zone and multizone using kubernetes.
Figure 14: Multicloud Deployment of Microservice with Pods
ISSN 1943-023X
8
Jour of Adv Research in Dynamical & Control Systems, 04-Special Issue, June 2017
VIII.
Key Challenges in Design
The key reasons for people to go for multi cloud are mainly-capacity overflow, sensitive workloads management, avoid vendor lock-in and make it high-availability. Key challenges across multi cloud location affinity of certain application/services, cross cluster service discovery, cross cluster scheduling, cross cluster migration and kuberneters address all. Kubernetes does not manage state by them, when the micro service itself is composed of multiple pieces - such as a database or a messaging queue. Kubernetes has an implicit assumption that all the state that is shared between service instances is managed outside of Kubernetes. When we design microservices and use containers and deploy in cluster to be managed by Kubernetes, developers have to take care of the state management of the cluster outside the scope of kubernetes. This is the major challenge to be addressed in our research. We continue our future work in addressing the concerns on auto-scaling, monitoring, auto-healing etc in a multi-cloud clustered environment using some standards like TOSCA[1] and bring some standards and governance structure.
References [1] [2]
[3]
[4] [5] [6] [7]
Baskaran, J and Kalpana, Y. Multi Cloud Deployment with Containers. International Journal of Engineering and Technology (IJET) 8 (1) (2016) 421-428. Savchenko, D. and Radchenko, G. Microservices validation: Methodology and implementation. In Proceedings of the 1st Ural Workshop on Parallel CEUR Workshop, Distributed, and Cloud Computing for Young Scientists, 2015. Krylovskiy, A. and Jahn Mand Patti, E. Designing a smart city internet of things platform with microservice architecture. In 3rd International Conference on Future Internet of Things and Cloud (FiCloud), 2015, 25-30. Sneps-Sneppe, M. and Namiot, D. Micro-service Architecture for Emerging Telecom Applications. International Journal of Open Information Technologies 2 (11) (2014). Kukade, P.P. and Kale, G. Auto-Scaling of Micro-Services Using Containerization. International Journal of Science and Research (IJSR) 4 (9) (2015) 1960-1963. Thönes J. Microservices. IEEE Software 32 (1) (2015). Newman, S. Building microservices. O'Reilly Media, Inc, 2015.
ISSN 1943-023X
9
