Free online consultation available. Please feel free to contact us.

Microservices

  • Glossary

"Microservices"

This glossary explains various keywords that will help you understand the mindset necessary for data utilization and successful DX.
This time, we will explain "microservices," a new concept in IT system development that has been gaining attention in the cloud era, and through it, we will consider what we should keep in mind when realizing IT systems and businesses in today's world where rapid change is required in both IT and business.

What are Microservices?

"Microservices" or "microservice architecture" is a software development technique that refers to a software architecture approach in which applications and IT systems are created as many small, independent parts, which are then combined to create the entire IT system.
This concept was proposed in the 2010s to resolve problems with traditional software development methods. It is increasingly being adopted in IT system development as a concept suited to new IT circumstances, such as the spread of agile development methods and cloud-native system development on cloud services.

Microservices are a way of combining small, independent parts

Put simply, microservices are a concept that realizes IT systems and applications as a combination of "small, autonomous parts." It is also a type of specific system architecture that realizes the development and operation of IT systems based on the concept of "loose coupling" (see link below).

⇒Loose coupling | Glossary

The above is a very basic explanation, but I think that most people find it hard to imagine, and find it difficult to imagine why it is done that way.

A new approach proposed because traditional development methods were not working

The reason why microservices are becoming a hot topic is because "traditional system development methods are starting to cause problems" in the new cloud era. In other words, problems are occurring and microservices are gaining support as a "means to solve those problems."

One of the advantages of microservices that is often cited is that they offer a solution to the problems that traditional methods often have when developing IT systems in new situations, such as smoothly developing and operating huge cloud services that are constantly evolving.

Traditional system development thinking: "Monolithic"

So, what is the "traditional way of thinking" that microservices are proposing to change? It is the "way of developing the entire IT system as a whole," which was taken for granted until then. In contrast to the fact that the entire system is "integrated," traditional system architecture is sometimes called "monolithic" (like a single rock).

Incidentally, it was not intentional to create a monolithic system. For example, if you were to develop a business system, you would first conduct a "requirements analysis" to determine what you need, then define the requirements, create the "external design" of the IT system based on the results of that analysis, then create the internal design of the system based on the results of that design, and then carry out software development. If you use traditional methods, you would normally end up with a monolithic system.

Just as people like the phrase "total optimization" and "one team," the world often encourages the idea of aligning the "whole" with a common goal. When you create something with that mindset, you often end up with something "monolithic."

The proposal for microservices also suggests that there is a different way of thinking that is suited to the new era, in contrast to this common way of thinking.

What exactly does it mean to "divide into smaller pieces"?

Some people may find it hard to imagine "divided into small parts." Some may think that it's not unusual to divide things into parts and organize them.

For example, when you run an application on your PC, you click on the executable file to run it. In most cases, there is only one executable file, and even when you check the Task Manager, there is often only one process. However, imagine if, for example, you launched Excel, and over 100 different processes were running simultaneously (for example, many EXE files were running and terminating repeatedly), all working together in unison. Wouldn't that be a bit surprising?

Microservices actually employ such an amazing architecture. Instead of a monolithic architecture, there are "many small parts that run independently," and while each operates independently, they work together as a whole to create a whole system. I hope you can see the feeling that this is "unprecedented."

The benefits of microservices

So what are the benefits of "dividing development into many small units"?

System development and modifications can be accelerated

Because each small part is independent, the impact of the change work is small, and the work of checking the impact of the change and making adjustments (which was often difficult with conventional methods) is minimized. As a result, it becomes more likely that requests for function changes or additions can be responded to flexibly and quickly.

It becomes easier to mix different technologies

It becomes possible to use different technologies (such as different programming languages) for each part, which was not easy with conventional methods. It becomes possible to develop each part using the means appropriate to its purpose, for example, even to use different programming languages based on the best fit for each part (sometimes called "polyglot programming"). It also becomes easier to adopt different technologies to suit the skills of each team, or to mix new and old technologies.

A method that makes it easier to handle high loads

It also becomes easy to distribute the load by launching multiple heavy processes in parallel.

Be more prepared for failures

If the entire system were a single executable file, the entire system could crash at once if something were to happen. However, if a problem occurs and execution stops, the impact can be localized, and it is relatively easy to prepare by running only the parts you want to increase fault tolerance in duplicate.

Increased reusability

Because each part is independent, it is easier to reuse it on a microservice basis.

Accelerating software releases

It allows small parts to be developed independently and released (providing software in a runnable state) independently. With traditional release methods, adjustments across the entire system were required each time, which could be a major undertaking.

Compatibility with agile development methods

Because release work is no longer difficult, agile development methods that release software frequently can be implemented smoothly. In the development of cloud services, it is not uncommon for release work to be carried out multiple times a day, but if this were done using traditional development methods, it would be too time-consuming and would become impractical.

Alternatively, microservices have been adopted because traditional methods cannot keep up with the current situation in which software improvements are required at such a rapid pace.

Streamlining software development

Because it becomes possible for each team to carry out development work in small units, they can proceed with development, testing, and release work in parallel at their own pace. The knowledge required for development is also limited to a deep understanding of the small area that each team is responsible for, which reduces waiting time for coordination and confirmation between teams, making development more efficient.

The problem with microservices

Of course, adopting a microservices architecture isn't all good.

Overall it can get complicated

While each individual service can be small and simple, the relationships between a large number of microservices tend to become complex. Communication between microservices, parallel processing within each, and the timing of when microservices start and stop are all important considerations, and a large number of microservices are launched. Even if the microservices themselves can be simple, new challenges tend to arise between the microservices.

The person designing the whole project may need to have high skills.

This is an architecture that can become complex overall if not designed well, so the person designing the overall structure will need advanced skills and know-how.

Can be difficult to operate

Because the system's operation can be complex, operating it can be more difficult than with a monolithic system, and the engineers responsible for operation will need to have advanced skills and know-how.

Troubleshooting and debugging can be difficult

Because operations across multiple microservices can become complex, it can be difficult to determine the cause of a system failure, and even during development, it can be difficult to perform testing and debugging beyond checking the operation of individual microservices.

Performance may be reduced

They may not perform as well at runtime as monolithic systems because they run in separate pieces and have communication overhead compared to the efficient cohesion of a monolithic architecture.

Logs can be difficult to manage

How to acquire and manage logs for processes that are distributed across many microservices can be a problem.

Ensuring data consistency can be difficult

This can be a difficult problem for microservices. In a monolithic system, data can be collected in one place, but in microservices, the concept of data must be distributed. As a result, problems can easily arise regarding how to ensure data consistency and integrity, or how to realize transactions, among the distributed data.

If data is centrally managed in one of the microservices, the design becomes more complex, and a failure there can have a wide-ranging impact. If each microservice replicates the data it needs, the design and implementation may be natural, but data inconsistencies may easily occur between the replicated data.

Are microservices an idea that actually works?

You may be thinking, "I understand the concept, but can it really be applied in practice?" In reality, adopting microservices is not easy and there are problems, but it has already been used in the development of actual products all over the world for some time now.

Already has a proven track record in global cloud services

For example, it is known that Amazon and Netflix are both developed using microservices, and there are already many examples of their adoption. These cloud services operate and provide services by running a large number of microservices internally.

Furthermore, Amazon and Netflix didn't adopt microservices because they were trendy. When developing and providing their own massive cloud services, they ran into the limitations of traditional methods, and as a solution they adopted a concept equivalent to microservices, which became a pioneering example. It is certainly a concept born out of the needs of the times.

Options to choose from depending on the situation

Of course, microservices aren't suitable for everything, and just because something is trendy doesn't mean it's right for your project.

There are cases where a monolithic architecture is more appropriate, and there is also a compromise approach where the development is divided into parts like microservices during the programming stage, but when it comes to running it in a live environment, it is released as a monolithic application (such as a modular monolith).Some people argue that in many cases, a modular monolith is the most realistic and optimal solution.

Organizational structure also needs to adapt to microservices

Microservices development may not work well unless the organizational structure and culture are suited to it. The benefits may be lost if development teams are forced to proceed with development on a service-by-service basis at their own discretion and are not able to release work quickly at their own discretion.

For example, adopting microservices may not work well in an organization with a traditional corporate culture. Keeping up with the new trends of the digital age may require fundamental changes to the organization itself.

Technology that realizes microservices architecture

Although the concept of microservices architecture has many benefits, there are also technical hurdles to overcome when it comes to actually implementing it as an IT system. In actual system development, the following technologies are used as implementation means:

  • Containers (allowing for independent small parts)
    Generally, microservices are often realized using container technology, and the independence of each service is often provided by separating the execution environment using containers. The term "microservices" itself was born from the emergence and use of container technology.
    ⇒Container | Glossary
  • API (communication between microservices)
    Since each service has its own independent execution environment, communication between other external microservices is similar to collaboration with external applications, and is generally done via APIs.
    ⇒ API｜Glossary
  • Container orchestration (management and operation of large numbers of containers)
    When microservices are implemented using containers and many microservices run as containers, traditional manual IT infrastructure operations can become difficult. There is a need for a means to understand the overall situation, such as the execution status of a large number of containers, as well as to manage and operate containers by monitoring their status and starting and stopping them according to load conditions.
    ⇒Container Orchestration | Glossary
  • APIinfrastructure/service mesh (controlling large volumes of communication)
    You may need an underlying technology that allows for successful communication between many microservices.

Considering the value of microservices from the business side

Up to this point, we have been talking about IT systems from the perspective of those who create them. However, the same "loose coupling" concept​ ​can be applied to the "business side" that usesIT in a similar way. From a business perspective, instead of treating IT systems as monolithic systems, we can approach the utilization of IT by composing them from small parts.

The following also explains that if you can properly decide what to extract as microservices, this in itself will bring various benefits to the business, and should also serve as an example of how to divide the whole into parts.

SOA (Service-Oriented Architecture)

A while ago, the idea of SOA was gaining attention. Like microservices, it is a concept of composing a system from small parts, but SOA was proposed from a business perspective.

Rather than building IT systems as huge, inflexible monolithic systems, the idea is to develop them as "services," which are ITcomponentsfor individual business functions, and then combine these services (components) to create the systems that actually handle business operations.

In other words, it is a concept in which a company's business functions are organized as components, and then combined as necessary as assets to be used as a business system. This concept also has the characteristic of increasing reusability, and allows for rapid development and flexible changes.

Not as good as SOA

Instead of using huge business package software, there is a way of thinking that involves selecting and combining the best applications for your company for each business area (e.g. accounting system). The idea of selecting and combining the best in each area is called "best of breed."

The multi-cloud approach of combining and utilizing various cloud services, and the approach of retaining the good parts of an old system that has been used for many years while introducing a new system based on new technology, are similarly based on the idea of selecting the "good parts" (focusing on the merits of each part) and combining them.

Technology that supports the same mindset on the business side

Just like microservices, there are technologies that can help make this happen.

  • Connection functions to each system and each cloud service (means of "connecting" from outside)
    You will need some way to connect to the system, such as integrating via API or file integration using a specified format.
  • APIimplementation (means of enabling external "connection")
    Alternatively, in order to turn existing IT assets into services and make them usable, a means will be needed, such as API conversion, that allows them to be called from outside as resources.
  • "Connecting" technology (means of freely combining and using a wide variety of resources)
    It is necessary to have a means to flexibly and quickly link and utilize a wide variety of systems and cloud services, and to effectively utilize the company's IT assets to create the information systems required for business. It is desirable that utilization can be achieved at the initiative of the business site, and that it can be used without the need for full-scale programming.

In situations like these, there are already methods that can effectively connect data and systems and create APIs: "connecting" technologies such as "EAI," "ETL," and "iPaaS."

  • Without writing any code, you can achieve integrated processing of a wide variety of systems and data simply by placing icons on the GUI and configuring various settings.
  • It is possible to efficiently connect a wide variety of IT systems, cloud services, and data, or automate the necessary conversion processes to create the IT systems needed for business operations from your company's IT assets.

In this way, efforts to "loosely couple" the whole from small parts can be started even with small efforts from a business perspective, not as part of full-scale IT development. If efforts are made to construct a system from the appropriate perspective from "each part" and utilize them by "connecting" them, it will not only be convenient for the development and operation of IT systems, but it will also lead to increased convenience in utilizing IT for the business side.

Related keywords (for further understanding)

  • Loose coupling
    • Loose coupling refers to a state in which a system is made up of a combination of components, with little dependency between each component and a high degree of independence between them. This is a useful perspective when considering "how various systems should be," from IT systems to organizational structures.
  • EAI
    • It is a concept of "connecting" systems by data integration, and is a means of freely connecting various data and systems. It is a concept that has been used since long before the cloud era as a way to effectively utilize IT.
  • ETL
    • In the recent trend of actively working on data utilization, the majority of the work is not the data analysis itself, but rather the collection and preprocessing of data scattered in various places, from on-premise to cloud.
  • iPaaS
    • A cloud service that "connects" various clouds with external systems and data simply by operating on a GUI.
  • container
    • Containers are a technology that creates an execution environment for multiple independent application systems within a single OS execution environment. Containers perform OS-level virtualization, as opposed to the hardware-level virtualization that has been used up until now.
  • Container Orchestration
    • It is an automation technology that manages, operates, and controls a large number of containers in system development and operation using container technology.

Are you interested in "iPaaS" and "connecting" technologies?

Try out our products that allow you to freely connect various data and systems, from on-premise IT systems to cloud services, and make successful use of IT.

The ultimate "connecting" tool: data integration software "DataSpider" and data integration platform "HULFT Square"

"DataSpider," data integration tool developed and sold by our company, is a "connecting" tool with a long history of success. "HULFT Square," a data integration platform, is a "connecting" cloud service developed using DataSpider technology.

Another feature is that development can be done using only the GUI (no code) without writing code like in regular programming, so business staff who have a good understanding of their company's business can take the initiative to use it.


Try outDataSpider/ HULFT Square 's "connecting" technology:

There are many simple collaboration tools on the market, but this tool can be used with just a GUI, is easy enough for even non-programmers to use, and has "high development productivity" and "full-fledged performance that can serve as the foundation for business (professional use)."

It can smoothly solve the problem of "connecting disparate systems and data" that hinders successful IT utilization. We offer a free trial version and online seminars where you can try it out for free, so we hope you will give it a try.


Why not try a PoC to see if "HULFT Square" can transform your business?

Why not try verifying how "connecting" can be utilized in your business, the feasibility of solving problems using data integration, and the benefits that can be obtained?

  • I want to automate data integration with SaaS, but I want to confirm the feasibility of doing so.
  • We want to move forward with data utilization, but we have issues with system integration
  • I want to consider data integration platform to achieve DX.

Glossary Column List

Alphanumeric characters and symbols

A row

Ka row

Sa row

Ta row

Na row

Ha row

Ma row

Ya row

Ra row

Wa row

»Data Utilization Column List

Recommended Content

Related Content

Return to column list