마이크로서비스 아키텍처

(작성중 - 다양한 접근법, 핵심, 어려움)

거슬러 올라가면 CBD / SOA , OSGi , UPnP 같은 것들

기슬적으로 보면 가장 레거시 친화적인 접근방법. 결국 기술이 문제가 아니었던 것, 기술로 해결할 수 있는 문제가 아니었던 것

핵심은 단순히 시스템 구조의 문제가 아니라 조직 구성, 운용 방법과 함께 묶여진 개념이라는 것

도입/변경을 하는데 있어서는 데이터베이스 관련 수정이 가장 까따롭고 어려운 도전

실용적으로 클라우드 네이티브한 시스템에서 더 효율적이 될 것

궁금한 것은 그래서, 이러한 전격적인 변화없이 부분적인 도입 전략은?

There is no single definition for microservices. A consensus view has evolved over time in the industry. Some of the defining characteristics that are frequently cited include:
Services in a microservice architecture (MSA) are often processes that communicate over a network to fulfil a goal using technology-agnostic protocols such as HTTP.[1][2][3]
Services are organized around business capabilities.[4]
Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best.[5]
Services are small in size, messaging-enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and built and .
A microservice is not a layer within a monolithic application (example, the web controller, or the backend-for-frontend). Rather it is a self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture. From a strategy perspective, microservices architecture essentially follows the of "Do one thing and do it well". describes a microservices-based architecture as having the following properties:
Lends itself to a software development process. A change to a small part of the application only requires rebuilding and redeploying only one or a small number of services.
Adheres to principles such as (to independently deployable services), business-driven development (e.g. ).
It is common for microservices architectures to be adopted for , computing, and applications using lightweight deployment. According to Fowler, because of the large number (when compared to monolithic application implementations) of services, decentralized continuous delivery and with holistic service monitoring are necessary to effectively develop, maintain, and operate such applications. A consequence of (and rationale for) following this approach is that the individual microservices can be individually scaled. In the monolithic approach, an application supporting three functions would have to be scaled in its entirety even if only one of these functions had a resource constraint. With microservices, only the microservice supporting the function with resource constraints needs to be scaled out, thus providing resource and cost optimization benefits.
<https://en.wikipedia.org/wiki/Microservices>

PreviousPAGE NextSHACL

Last updated 10 months ago

Was this helpful?

마이크로서비스 아키텍처

(작성중 - 다양한 접근법, 핵심, 어려움)

거슬러 올라가면 CBD / SOA , OSGi , UPnP 같은 것들

기슬적으로 보면 가장 레거시 친화적인 접근방법. 결국 기술이 문제가 아니었던 것, 기술로 해결할 수 있는 문제가 아니었던 것

핵심은 단순히 시스템 구조의 문제가 아니라 조직 구성, 운용 방법과 함께 묶여진 개념이라는 것

도입/변경을 하는데 있어서는 데이터베이스 관련 수정이 가장 까따롭고 어려운 도전

실용적으로 클라우드 네이티브한 시스템에서 더 효율적이 될 것

궁금한 것은 그래서, 이러한 전격적인 변화없이 부분적인 도입 전략은?

There is no single definition for microservices. A consensus view has evolved over time in the industry. Some of the defining characteristics that are frequently cited include:
Services in a microservice architecture (MSA) are often processes that communicate over a network to fulfil a goal using technology-agnostic protocols such as HTTP.[1][2][3]
Services are organized around business capabilities.[4]
Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best.[5]
Services are small in size, messaging-enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and built and .
A microservice is not a layer within a monolithic application (example, the web controller, or the backend-for-frontend). Rather it is a self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture. From a strategy perspective, microservices architecture essentially follows the of "Do one thing and do it well". describes a microservices-based architecture as having the following properties:
Lends itself to a software development process. A change to a small part of the application only requires rebuilding and redeploying only one or a small number of services.
Adheres to principles such as (to independently deployable services), business-driven development (e.g. ).
It is common for microservices architectures to be adopted for , computing, and applications using lightweight deployment. According to Fowler, because of the large number (when compared to monolithic application implementations) of services, decentralized continuous delivery and with holistic service monitoring are necessary to effectively develop, maintain, and operate such applications. A consequence of (and rationale for) following this approach is that the individual microservices can be individually scaled. In the monolithic approach, an application supporting three functions would have to be scaled in its entirety even if only one of these functions had a resource constraint. With microservices, only the microservice supporting the function with resource constraints needs to be scaled out, thus providing resource and cost optimization benefits.
<https://en.wikipedia.org/wiki/Microservices>

PreviousPAGE NextSHACL

Last updated 10 months ago

Was this helpful?