Microservice
01
Microservice Architecture
Microservice architecture defines each component as service, and service means an independent component from data to business logic without any dependency between the service. Service provides functions to external standard interfaces such as REST API.
The services are defined and distributed following Syntax or Domain. The services are defined by each Domain such as User Configuration, Product Management, and Order Management. (For instance, we separate the service by task services are separated into each Domain and are defined individually such as User Configuration, Product Management, and Order Management.) Multiple tasks are not combined and defined as one service like "User/User Configuration." Major URI such as "/users", "/products" in Rest API can be a good example of a service defined-unit.
In terms of distribution structure, every service is independently distributed to the independent servers without dependence on other components. For instance, User Configuration Service is developed in an independent WAR(Web application ARchive) file which would be placed in an independent Tomcat Instance. Tomcat Instances where services are deployed for expansion can be scaled out (by adding more Instances) and load balancers are placed at the front-end to distribute the load between the services.
The key is to separate the application logic, divide it into multiple applications and define them as services, and to distribute the Tomcat for each service
02
Microservice & API Management
As mentioned above, each microservice module communicates with each other through APIs. API means “An application programming interface that is a set of requirements enabling one application to talk to another application.
API has been developed for last decades.
-
1960-1980
Basic interoperability enables the first programmatic exchanges of information. Simple interconnect between network protocols. Sessions established to exchange information.
Techniques : ARPANET, ATTP and TCP sessions.
-
1980-1990
Creation of interfaces with function and logic. Information is shared in meaningful ways. Object brokers, procedure calls, adprogram calls allow remote interaction across a network.
Techniques : Point-to-point interfaces, screen scraping, RFCs and EDI.
-
1990-2000
New platforms enhance exchanges through middleware, interfaces begin to be defined as services. Tools manage the sophistication and reliability of messaging.
Techniques : Message-oriented middle ware, enterprise service bus, and service oriented architecture.
-
2000-Today
Businesses build APIs to enable and accelerate new service development and offerings. API layers manage the OSS / BSS of integration.
Techniques : Integration as a service, RESTful services, API management and cloud orchestration.
From the 1960s to the 1980s, Systems were operated by simple Programmatic Information Exchange which was only capable. The protocols were also networking session-based protocols such as ARPANET, ATTP &, or TCP. From 1980 to 1990, Information Shared by Interfaces (Function & Logic) Object brokers, procedure calls, and program calls allow remote interaction across a network applying logics and techniques such as Point-to-point interfaces, screen scraping, RFCs and EDI.
From 1990 to 2000, Information Exchange was upgraded by Middleware and Interface which were defined as “services”. Along with the emergence of Middleware, the use of ESB(Enterprise Oriented Architecture) Technology was also increased. As the service was increased and widely applied, Enterprise Architecture was shifted from ESB to SOA(Service Oriented Architecture). Since 2000, APIs have evolved to the next level to support Rest Protocol, and products such as API Management Systems and Cloud API Management became popular, and since then, microservice has become more important and a big change for Information Exchange of the next-generation has begun.
As presented in the graph below, APIs have been constantly increased since 2005, and the REST APIs are the most popular Architectural Style. The key part of this graph is where Web APIs were highly increased in 2014 when Docker began to emerge.
03
Considerations When Implementing Microservice
As previously described, switching from monolithic architecture to microservice is required because monolithic architecture has very low agility, flexibility, and reusability making business inefficient.
This does not mean that it is easy to shift to the microservice. Before making changes, we should define problems and limits of monolithic and should not spend much energy to configure the “optimal size” when splitting monolithic into multiple independent services because the amount of code varies in accordance with the size of service. The more essential part is, each service should progress their task logics in a certain scope. Microservice developers and designers normally excessively care about the code size of the service block which was separated from monolithic source code. However, it is enough for each service to be sized adequately for handling its task logic. Excessive rejection of monolithic can cause too many microservices. When there are problems in the process of building and operating a new architecture, services may be further subdivided. Another important issue to keep in mind is that you should be able to expand and run your business in a monolithic way even after the transition is already started.
It is a good way to separate the team into two minor teams and to “split responsibilities” in the development period. One team should maintain the existing monolithic application, and the other team should develop a new application with another source code. A proper team arrangement is very important because there might be conflicts between the teams. To keep large-scale monolithic applications is not as interesting as working with new technologies. It is easier to resolve this issue when the team is large because the members can alternate in two tasks. By alternating members in two tasks, all members can learn new technologies which programmers prefer, and approach Monolithics with a new perspective. Now, the next thing you should consider is time.
The transition to microservice is not something can be done overnight. No matter how many plans there are, the transition cannot be done immediately. Transition to microservice requires a significant investment in engineering. However, if the application is larger than a certain scale, there should be benefits to the investors. Most corporates consider implementing microservice architecture because they desire to resolve a number of problems that were occurred as monolithic application and teams have been getting much larger. Shifting to microservices requires not only separating programs but also creating new teams which will lead to technological and organizational changes.
Long-term plans are critical for fundamental changes, and implementation would be successful only when preparation work and verification work are conducted. These cannot be done overnight, and there are some cases you may first create and use programs for implementation and remove them later. For example, a separated architecture is requireed to utilize the existing databases and to handle functions such as authentication and authorization. When the microservice transition becomes successful after overcoming all those chanllenges, your microservice architecture will make your business agile, and application development will become significantly faster.
