Solution Architect là gì? Vì sao cụm từ này lại rất phổ biến trong giới công nghệ, vậy làm thế nào để phát triển theo huớng Architect, đâu là những kiến thức cần bổ sung và chú trọng.
Solution Architect là gì?
Vai trò của một Solution Architect khá rộng và mang tính bao quát, họ sẽ tham gia trực tiếp với đội ngũ kinh doanh ( ngay từ khi giai đoạn dự án chưa được hình thành). Từ đó Họ sẽ nắm được các vấn đề kinh doanh của khách hàng và đề xuất các giải pháp thiết kế hệ thống để tối ưu hóa lại các hoạt động kinh doanh. Những đặc điểm nhận dạng một solution architect:
- Họ sẽ thường không trực tiếp thiết kế phần mềm, Solution Architect sẽ tập trung vào làm những việc trên tính năng lớn kết hợp với các giải pháp công nghệ. Từ đó họ sẽ đề xuất các giải pháp thiết kế, dựa trên những hiểu biết về kinh doanh của doanh nghiệp và khách hàng.
- Nắm được những xu hướng công nghệ mới, hiểu được các giới hạn của giải pháp, khả năng mở rộng, khả năng bảo trì trong tương lai.
- Họ còn có trách nhiệm đưa ra độ ưu tiên cho giải pháp cần được triển khai. Điều này cũng tùy thuộc vào nhiều yếu tố mà công việc của vai trò này được đảm nhận một phần bởi các vai trò Product Manager hoặc Senior Business Analyst.
Trong mục Chuyên gia nói, hãy cùng TopDev trò chuyện cùng anh Võ Duy Tuấn – CEO | Teamcrop – chuyên cung cấp giải pháp quản lý bán hàng, quản lý nhân sự.
Theo anh một Solution Architect có vai trò như thế nào ở một công ty về quản lý chuỗi bán lẻ ERP? Anh có thể giới thiệu một cách khái quát về công việc của mình ở thời điểm hiện tại?
Theo tôi, Solution Architect đóng vai trò quan trọng ở hầu hết ở những công ty công nghệ. Bởi vì họ giúp thiết kế một kiến trúc tốt, ổn định cho hệ thống đang vận hành. Đặc biệt về bảo mật, khả năng mở rộng, tiết kiệm chi phí.
Để trở thành một Solution Architect giỏi thì chúng ta cần phải chú ý phát triển những kỹ năng gì?
Để trở thành một Solution Architect giỏi thì cần nắm vững kiến thức về mạng (networking), lập trình và cách một hệ thống vận hành thì mới có thể thiết kế một hệ thống tốt cho khách hàng.
Anh có thể miêu tả một career path cụ thể cho một Solution Architect được không?
Theo kinh nghiệm của tôi, một Solution Architect cần phải nắm được kiến trúc mình đang chạy gồm những gì như: server như thế nào; database, web server,… chạy như thế nào và sau đó setup cho để chạy, đồng thời tiến hành theo dõi (monitor) thường xuyên. Khi thấy performance giảm, hệ thống bị tấn công thì kịp thời đưa ra những kiến trúc mới. Đó có thể là ngắn hạn để giải quyết vấn đề ngay tại thời điểm đó hoặc những kiến trúc để giải quyết vấn đề dài hạn và để có thể scale lên.
Chia sẻ thêm về career path, theo bản thân tôi, tôi xuất thân là lập trình viên và chọn môi trường web, lập trình web. Sau đó, tôi nhận thấy những vấn đề như quá nhiều người truy cập thì hệ thống bị chậm. Tôi bắt đầu tìm hiểu và thấy trên internet có nhiều kiến trúc hay được chia sẻ. Mỗi kiến trúc đều có những lợi thế, bất lợi riêng và tôi bắt đầu tìm hiểu những kiến trúc ấy rồi dần áp dụng vào hệ thống của mình. Cứ như thế, dần hình thành nên những “phản xạ về kiến trúc”. Đó là khi bản thân phát hiện rằng: áp dụng kiến trúc này sẽ được tối ưu bao nhiêu phần trăm, áp dụng kiến trúc kia sẽ có những vấn đề gì.
Về lộ trình học nên học về lập trình, mạng máy tính (networking), web và bảo mật .
Phần mềm quản lí chuỗi bán hàng (ERP) có nhiều service khác nhau. Vậy đối với một hệ thống phức tạp như vậy thì cần chuẩn bị phần logging thế nào cho tốt nhất?
Log trong micro service khá phức tạp. Bởi khi xây dựng hệ thống lớn, có rất nhiều vấn đề phát sinh. Khi có vấn đề phát sinh sẽ rất khó khăn cho việc tìm ra nguyên nhân. Hệ thống logging giúp tìm ra và phát hiện nguyên nhân lỗi. Ví dụ như log request, access log, error log, SQL log,…
Bây giờ đặt một bài toán: Có service A gọi service B và C đồng thời. Trong trường hợp B hoặc C bị lỗi thì A sẽ không chạy được và bạn sẽ phải đọc log của B và C để phát hiện lỗi, Tuy nhiên, nếu A gọi tới rất nhiều service khá (D,E,F,…) thì liệu có giải pháp nào để đỡ phải đọc nhiều phần khác nhau để tìm ra lỗi?
Đây là vấn đề nổi lên gần đây trong kiến trúc microservice. Đối với kiến trúc monolithic như trước, khi mình muốn coi log thì mình chỉ cần coi 1 request là đủ. Trong microservice, việc những service gọi liên đới nhau (chiều sâu 3-4 tầng), việc nhìn 1 service sẽ rất khó đoán để debug được lỗi ở đâu. Tuy nhiên, một kỹ thuật mới xuất hiện để giải quyết bài toán này, đó chính là Distributed Tracing. Đây là một kỹ thuật giúp bạn nhìn tổng thể một request từ đầu đến cuối, trải qua những request khác, đi sâu và kết nối những log ấy lại thành 1 log duy nhất.
Anh hãy chia sẻ vài tips để viết content cho log?
Nội dung của log phụ thuộc chính vào nội dung, nhu cầu bạn muốn log. Vd log request thì log IP; log database thì log kiểu khác. Lời khuyên của tôi là bạn nên quy định một format tiết kiệm nhất cho một record log. Vì về dài hạn, log dữ liệu lớn sẽ ảnh hưởng đến thời gian truy vấn nên khó để monitor sự cố. Chính vì vậy size của log record rất quan trọng.
Anh có thể chia sẻ một số khó khăn kỹ thuật khi mở rộng mô hình?
Trong việc mở rộng mô hình, đôi khi các Solution Architect sẽ gặp phải một số khó khăn kỹ thuật. Chẳng hạn như khi làm việc, database sẽ rất khó khăn về phần size, quan trọng là bạn phải lựa chọn những data storage phù hợp.
Ví dụ: Teamcrop kết hợp sử dụng Memory cùng Clickhouse để lưu dữ liệu lớn và một số database tùy theo nhu cầu sử dụng.
Theo anh nền tảng Data và Devops đang đóng vai trò như thế nào cho những doanh nghiệp thương mại tại thị trường Việt Nam?
Theo tôi quan sát cách đây khoảng 3-4 năm, React JS hoặc React Native trở nên thịnh hành. Đến năm 2018, Flutter nổi lên và trở nên phổ biến. Và Teamcrop quyết định chuyển kiến trúc làm app sang Flutter. Trải nghiệm ở Flutter khá tốt, cả team lẫn khách hàng đều hài lòng. Theo tôi, trong khoảng 3 đến 4 năm tới Flutter sẽ chiếm lĩnh mảng mobile app.
Và khó khăn khi chuyển từ cái cũ sang cái mới chính là bạn sẽ phải học cách tiếp cận, ví dụ như là SDK của Flutter, ngôn ngữ mới Dart của Google, State management mới. Tuy nhiên đây chỉ là những việc nhỏ, so với kết quả mà quá trình mang lại.
Hiện nay đâu là 3 công nghệ là thế mạnh của anh nhất, và 3 công nghệ mà anh hứng thú mà mình sẽ học trong tương lai.
Đối với tôi thì PHP, Javascript và Dart chính là 3 ngôn ngữ mà tôi quan tâm cũng như là thế mạnh của mình. Chia sẻ thêm, trong tương lai theo xu hướng thì tôi muốn tìm hiểu Python để phục vụ Machine Learning, tôi cũng muốn học thêm các ngôn ngữ Functional Program Learning.
Anh có thể chia sẻ process tuyển dụng của TeamCrop, và anh quan tâm đến điều gì ở ứng viên?
Nhu cầu tuyển dụng của team tôi không quá cao, tuy nhiên vẫn khá rõ ràng. Ở Teamcrop, tôi muốn tuyển những bạn: Thích khám phá những công nghệ mới, do công nghệ chỉ khoảng 5 năm sẽ trở nên lạc hậu. Trình độ không quan trọng trong quá trình phỏng vấn, vì chỉ trong quá trình làm việc mới có thể đánh giá liệu họ có tư duy logic, tư duy lập trình, teamwork,… hay không. Quan trọng nhất vẫn là tính cách, thích giải quyết vấn đề. Ngoài ra còn có vòng thử việc để hiểu nhau hơn.
Công việc hàng ngày của anh và team như thế nào?
Ngoài là Solution Architect, tôi còn quản lý công ty. Công việc hàng ngày của tôi bao gồm những việc như monitor hệ thống, họp với team, tìm hiểu về sản phẩm của Teamcrop, đôi khi lập trình do task hấp dẫn nên xắn tay áo tham gia cùng anh em.
Những điểm mạnh hoặc lợi ích, phát triển bản thân hoặc điều gì thú vị nhất khi trở thành thành viên của tech team nói chung và team của anh nói riêng?
Khi vào Teamcrop, Thứ nhất , bạn sẽ không phải làm “quá nhiều”. Công ty tôi không theo trường phái “đầu tắt mặt tối” và làm quần quật. Suốt năm qua, cả team nói không với OT bởi vì tasks chỉ cần làm tại công ty là đủ. Công việc liên quan tới nhiều là sales, marketing support là chính. Ngoài ra, các benefit cơ bản như lương thưởng tháng 13 là điều hiển nhiên, công ty nào cũng có. Đối với những sản phẩm được đón nhận tất nhiên sẽ có benefits riêng.
Anh có thể chia sẻ về một kỷ niệm đáng nhớ cũng như kinh nghiệm xương máu về việc ứng dụng một công nghệ mới vào sản phẩm của công ty?
Kỷ niệm đáng nhớ của tôi chính là khi teamcrop áp dụng công nghệ service worker, đây là chức năng lưu file trên trình duyệt giúp mình đỡ mất công request vào server. Trong một lần kiểm tra không kỹ, cấu hình nhầm và kết quả là sketch cả file index.html, thường sẽ dẫn link tới javascript, khiến việc vào đường dẫn domain vẫn không ra content mới nên phải đổi domain do domain cũ không thể sử dụng được. Từ đó rút kinh nghiệm không sketch file index nữa.
Xin cảm ơn phần chia sẻ vừa rồi từ anh Tuấn. Hy vọng bài viết này đã cung cấp những câu chuyện về nghề Solution Architect cũng như giúp bạn hiểu hơn những kiến thức cần đạt được trong lĩnh vực này. Đừng quên theo dõi phần tiếp theo trong Chuyên gia nói để biết thêm những vai trò khác trong lĩnh vực Công nghệ nhé!
Nguồn: TopDev Blog
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?