You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1번은 해당 서버를 유지하기 위한 금전적인 리소스이다.
새로운 도메인을 유지하는데에 필요한 인스턴스는 굉장히 많다.
DB, Application Instance, 부터 시작해서 로드밸런서, 로그관리시스템,
DB 는 Mongo, Mysql 등등 여러가지 데이터베이스를 사용할 수도 있다.
이러한 것들이 dev, stage, prod 각각의 환경마다 필요하다보니 꽤나 큰 금전적인 리소스가 필요하다.
2번은 서버를 관리하기 위한 개발자의 리소스이다.
서버가 여러개로 나눠져있으면 스타트업의 특성상 한명의 개발자가 1~2개 또는 그 이상으로 서버를 담당하게 된다.
즉, 온전히 해당 개발자의 의견에 따라 서버가 운영 및 구성된다.
그러다 보니 한명의 개발자가 퇴사를 하거나 휴가 및 퇴근을 하는 경우, 이슈가 났을 때 대응이 어렵다. 왜냐하면 한번도 보지 못했던 코드이기때문이다.
to-be
1번. 해당 서버를 유지하기 위한 금전적인 리소스이다.
새로운 도메인을 유지하는데에 필요한 인스턴스는 굉장히 많다.
DB, Application Instance, 부터 시작해서 로드밸런서, 로그관리시스템,
DB 는 Mongo, Mysql 등등 여러가지 데이터베이스를 사용할 수도 있다.
이러한 것들이 dev, stage, prod 각각의 환경마다 필요하다보니 꽤나 큰 금전적인 리소스가 필요하다.
2번. 서버를 관리하기 위한 개발자의 리소스이다.
서버가 여러개로 나눠져있으면 스타트업의 특성상 한명의 개발자가 1~2개 또는 그 이상으로 서버를 담당하게 된다.
즉, 온전히 해당 개발자의 의견에 따라 서버가 운영 및 구성된다.
그러다 보니 한명의 개발자가 퇴사를 하거나 휴가 및 퇴근을 하는 경우, 이슈가 났을 때 대응이 어렵다. 왜냐하면 한번도 보지 못했던 코드이기때문이다.
경험에서 우러나오는 글 재밌게 잘 읽었습니다. 적어주신 서버분리의 이점과 단점에 대해 공감이 많이 가네요.
이론적으로 생각하는 것과 실제 서비스를 개발하는 것의 이상과 현실같은 느낌...ㅎㅎ
MSA는 회사 규모가 커짐에 따라 선택적으로 따라오는 것 같아요. 한 2년전에 강남에서 지원님과 이 주제에 대하여 얘기 했던 것 같은데 추억이 돋네요.
회사마다 가용할 수 있는 리소스나 기타 상황이 다르지만 저는 개인적으로 서버당 책임자를 두명씩 두는 방안은 어떨까 생각이 듭니다.
글의 흐름에 대해서는 크게 문제가 없으나 개인적으로 "3번은 2번과 연결되어있다." 같은 문구가 위에
생명주기가 다르다.
다른 유저와 달리 주기적으로 관리 및 심사 지원프로세스가 존재한다.
정산 같은 선생님에 특화된 기능이 필요하다.
불필요하게 많은 통신 ( 유저 정보와 선생님 정보 함께 조회 및 관리되어야 하는 지점 생각보다 많음 )
Activity
lluke0 commentedon Aug 31, 2024
글 잘 읽었습니다. 글의 흐름이 잘 짜여져서 읽기 편했어요.
다만 소제목을 조금 더 활용하면 좋을 것 같습니다!
as-is
1번은 해당 서버를 유지하기 위한 금전적인 리소스이다.
새로운 도메인을 유지하는데에 필요한 인스턴스는 굉장히 많다.
DB, Application Instance, 부터 시작해서 로드밸런서, 로그관리시스템,
DB 는 Mongo, Mysql 등등 여러가지 데이터베이스를 사용할 수도 있다.
이러한 것들이 dev, stage, prod 각각의 환경마다 필요하다보니 꽤나 큰 금전적인 리소스가 필요하다.
2번은 서버를 관리하기 위한 개발자의 리소스이다.
서버가 여러개로 나눠져있으면 스타트업의 특성상 한명의 개발자가 1~2개 또는 그 이상으로 서버를 담당하게 된다.
즉, 온전히 해당 개발자의 의견에 따라 서버가 운영 및 구성된다.
그러다 보니 한명의 개발자가 퇴사를 하거나 휴가 및 퇴근을 하는 경우, 이슈가 났을 때 대응이 어렵다. 왜냐하면 한번도 보지 못했던 코드이기때문이다.
to-be
1번. 해당 서버를 유지하기 위한 금전적인 리소스이다.
새로운 도메인을 유지하는데에 필요한 인스턴스는 굉장히 많다.
DB, Application Instance, 부터 시작해서 로드밸런서, 로그관리시스템,
DB 는 Mongo, Mysql 등등 여러가지 데이터베이스를 사용할 수도 있다.
이러한 것들이 dev, stage, prod 각각의 환경마다 필요하다보니 꽤나 큰 금전적인 리소스가 필요하다.
2번. 서버를 관리하기 위한 개발자의 리소스이다.
서버가 여러개로 나눠져있으면 스타트업의 특성상 한명의 개발자가 1~2개 또는 그 이상으로 서버를 담당하게 된다.
즉, 온전히 해당 개발자의 의견에 따라 서버가 운영 및 구성된다.
그러다 보니 한명의 개발자가 퇴사를 하거나 휴가 및 퇴근을 하는 경우, 이슈가 났을 때 대응이 어렵다. 왜냐하면 한번도 보지 못했던 코드이기때문이다.
gyumong commentedon Aug 31, 2024
경험에서 우러나오는 글 재밌게 잘 읽었습니다. 적어주신 서버분리의 이점과 단점에 대해 공감이 많이 가네요.
이론적으로 생각하는 것과 실제 서비스를 개발하는 것의 이상과 현실같은 느낌...ㅎㅎ
MSA는 회사 규모가 커짐에 따라 선택적으로 따라오는 것 같아요. 한 2년전에 강남에서 지원님과 이 주제에 대하여 얘기 했던 것 같은데 추억이 돋네요.
회사마다 가용할 수 있는 리소스나 기타 상황이 다르지만 저는 개인적으로 서버당 책임자를 두명씩 두는 방안은 어떨까 생각이 듭니다.
글의 흐름에 대해서는 크게 문제가 없으나 개인적으로 "3번은 2번과 연결되어있다." 같은 문구가 위에
생명주기가 다르다.
다른 유저와 달리 주기적으로 관리 및 심사 지원프로세스가 존재한다.
정산 같은 선생님에 특화된 기능이 필요하다.
불필요하게 많은 통신 ( 유저 정보와 선생님 정보 함께 조회 및 관리되어야 하는 지점 생각보다 많음 )
유지보수 및 코드 품질 관리 ( 가장 큰 이유 )
들과 약간 햇갈리네용.
진욱님 말처럼 소제목 분리하면 좀 더 좋을 것 같아요