Mục lục

Không có vị trí nào thực sự an toàn

Platform không thành công vì được xây dựng hoàn hảo - mà thành công vì người dùng thực sự cần nó

Khi nghĩ đến “Innovation”, đừng quên bước “Migration” và “Maintenance”

Automation có thể là con dao hai lưỡi

Độ phức tạp và quy mô chính là những tín hiệu cơ bản cho sự thay đổi kiến trúc trong tương lai

Sau tất cả những thứ “cool”, compliance mới là điểm kết thúc

Một video về công nghệ, nhưng những điều đáng lưu tâm nhất lại… không phải công nghệ

Table of Contents

No Position Is Truly Safe

A Platform Succeeds Not Because It Exists, But Because People Actually Need It

When Thinking About Innovation, Do Not Forget Migration and Maintenance

Automation Can Be a Double-Edged Sword

Complexity and Scale Are Early Signals of Future Architectural Change

After All the “Cool” Things, Compliance Is Where the Journey Ends

A Technology Video, Yet the Most Important Lessons Were Not About Technology

Trong những năm gần đây, không còn lạ gì với những cuộc sa thải (layoff) tại các Big Tech. Mỗi lần lướt thấy tin này, dân IT lại tặc lưỡi: “Lại do AI à?”. Phần lớn sự chú ý của chúng ta thường tập trung vào những câu hỏi quen thuộc: ai bị ảnh hưởng, tại sao bị ảnh hưởng (bởi AI?) và liệu thị trường công nghệ có còn hấp dẫn như giai đoạn 2019-2022 hay không?

Không có câu trả lời nào thực sự rõ ràng. Mỗi cuộc sa thải xảy ra lại để lại cho những người trong cuộc những bài học đắt giá. Và những bài học đó đã được chia sẻ bởi một cựu nhân viên của Atlassian. Điều khiến tôi chú ý lại không phải là câu chuyện layoff: anh ấy gần như không dành thời gian để than phiền hay trách móc Atlassian. Hơn 40 phút của video được dùng để kể về những bài toán kỹ thuật, những hệ thống đã xây dựng, cũng như những vấn đề mà tổ chức từng gặp phải và cách đội ngũ của anh giải quyết chúng.

Điều đó vô tình tạo ra một câu hỏi làm bản thân mình băn khoăn hơn:

Sau nhiều năm làm việc tại một công ty công nghệ, thứ gì thực sự còn lại khi trong tay người kỹ sư khi rời khỏi công ty?

Không có vị trí nào thực sự an toàn

Một trong những điều đầu tiên có thể rút ra từ video là một thực tế khá đơn giản: không có vị trí nào thực sự an toàn.

Trong nhiều năm, ngành công nghệ thường tạo ra cảm giác rằng nếu một kỹ sư đủ giỏi, đủ kinh nghiệm hoặc làm việc tại những công ty lớn thì họ sẽ ít chịu tác động hơn trước các biến động của thị trường. Nhưng thực tế lại cho thấy điều ngược lại. Các đợt cắt giảm nhân sự gần đây không chỉ ảnh hưởng đến các kỹ sư mới vào nghề. Chúng ảnh hưởng đến senior engineers, staff engineers, principal engineers và cả những người đã dành nhiều năm xây dựng các nền tảng cốt lõi của doanh nghiệp.

Điều này không phản ánh năng lực của họ. Nó phản ánh rằng doanh nghiệp luôn tối ưu theo mục tiêu của doanh nghiệp.

Từ góc nhìn đó, giá trị dài hạn của một kỹ sư không nằm ở công ty mà họ đang làm việc, mà nằm ở khả năng giải quyết vấn đề và những kinh nghiệm có thể mang theo từ hệ thống này sang hệ thống khác.

Platform không thành công vì được xây dựng hoàn hảo - mà thành công vì người dùng thực sự cần nó

Một chủ đề xuất hiện xuyên suốt video là platform engineering. Khi nghe đến platform, nhiều người trong chúng ta, kể cả những người đã và đang cật lực ngồi gõ những dòng code “nền móng” của một platform, thường nghĩ đến một nền tảng nội bộ với hàng tá công cụ, dashboard, automation hoặc service mesh. Tuy nhiên, những gì được chia sẻ trong video lại gợi mở một góc nhìn khác:

Một platform không thành công vì nó được xây dựng hoàn hảo. Một platform chỉ thành công khi phần còn lại của tổ chức sử dụng nó.

Xây dựng platform thường là phần dễ hơn. Thuyết phục hàng chục hoặc hàng trăm đội ngũ sử dụng platform đó mới là phần khó hơn. Nếu một platform giúp giảm chi phí vận hành, chuẩn hóa quy trình triển khai và đơn giản hóa việc phát triển dịch vụ mới nhưng không có đội ngũ nào muốn sử dụng, thì về bản chất nó vẫn là một thất bại.

Bản thân mình khi làm việc tại FTEL đã từng tiếp xúc, sử dụng và góp phần xây dựng khá nhiều platform. Qua đó, mình nhận ra rằng một platform chỉ thực sự có giá trị khi nó được sử dụng rộng rãi trong tổ chức. Không chỉ FTEL mà nhiều công ty khác cũng vậy. Công ty càng lớn càng đối diện với sự “bão hòa” về ý tưởng. Hàng chục ý tưởng được đưa ra mỗi ngày, nhưng chỉ một số rất ít trong đó thực sự được triển khai và có người sử dụng.

Khi nghĩ đến “Innovation”, đừng quên bước “Migration” và “Maintenance”

(i). Mỗi dịch vụ cũ đều mang theo lịch sử riêng.

(ii). Mỗi đội ngũ đều có những ràng buộc riêng.

(iii). Mỗi ứng dụng đều có những ngoại lệ riêng.

Một ý khác xuất hiện trong video là câu chuyện chuyển đổi từ kiến trúc cũ sang nền tảng mới.

Trong ngành công nghiệp phần mềm, chúng ta thường đánh giá cao việc xây dựng hệ thống mới nhưng lại đánh giá thấp chi phí chuyển đổi. Thực tế, rất nhiều hệ thống không thất bại vì công nghệ kém. Chúng thất bại vì không thể migrate người dùng sang mô hình mới.

Kể cả bản thân mình, khi phát triển một “Centralized API Hub” trong khoảng ba tháng, mình đã không lường trước được rằng việc thuyết phục các đội ngũ khác chuyển sang sử dụng API Hub mới sẽ là một thử thách lớn hơn nhiều so với việc xây dựng nó. Và thực tế là quá trình migrate này đã mất hơn 18 tháng để hoàn thành.

Đôi khi, bài toán khó nhất không phải là xây dựng một thứ mới. Mà là giúp những người đang sử dụng hệ thống cũ chấp nhận thay đổi.

Automation có thể là con dao hai lưỡi

Một trong những ví dụ thú vị nhất trong video là câu chuyện về Envoy và việc quản lý một lượng lớn cấu hình proxy.

Nếu mỗi service tự quản lý route, tự quản lý networking policy hoặc tự quản lý proxy configuration thì số lượng cấu hình sẽ tăng theo quy mô tổ chức. Khi số lượng dịch vụ lên tới hàng trăm hoặc hàng nghìn, việc yêu cầu con người trực tiếp thao tác với từng cấu hình không còn khả thi. Bài toán lúc này mà tổ chức phải đối diện không phải là automation, mà là xây dựng một lớp trừu tượng hóa (abstraction layer) phù hợp.

Thực tế chỉ ra rằng hầu như ai trong quá trình phát triển phần mềm cũng từng trải qua giai đoạn muốn “automation” mọi thứ:

“Mấy cái thứ click click, điền điền này sao không tự động hóa đi cho nhanh?”

Nhưng khi đã tự động hóa xong, chúng ta lại nhận ra rằng việc tự động hóa một quy trình không phải là đích đến cuối cùng. Nó chỉ là một bước trong quá trình xây dựng một hệ thống lớn hơn. Và nếu không được thiết kế cẩn thận, automation có thể trở thành một con dao hai lưỡi, nơi các luồng xử lý chồng chéo lên nhau, việc bảo trì trở nên khó khăn hơn và việc debug cũng phức tạp hơn rất nhiều.

Độ phức tạp và quy mô chính là những tín hiệu cơ bản cho sự thay đổi kiến trúc trong tương lai

Đoạn gần cuối video có nhắc đến việc nếu mỗi backend service đều phải tự implement các tính năng như authentication, authorization, logging… thì theo thời gian nó sẽ trở thành một ma trận với hàng ngàn cấu hình khác nhau và việc quản lý sẽ ngày càng phức tạp.

Để giải quyết vấn đề này, đội ngũ Atlassian đã sử dụng Anti-DDoS chung ở phía trước Envoy proxy, access log được xử lý tập trung tại Envoy, đồng thời các tính năng như authentication và authorization được chạy dưới dạng sidecar cùng với Envoy.

Thực tế, trong giai đoạn đầu phát triển một phần mềm nào đó, cách thiết kế này nghe có vẻ hoàn toàn hợp lý:

• Một service chỉ cần vài dòng code để xác thực người dùng.
• Một service khác chỉ cần thêm middleware để ghi log.
• Một service thứ ba chỉ cần thêm một thư viện phân quyền.

Nhưng khi số lượng service tăng lên theo năm tháng, mọi thứ bắt đầu thay đổi. Hàng trăm service ghi log theo các format khác nhau, hàng trăm cơ chế bảo mật khác nhau và hàng trăm nơi cần vá lỗi. Đây là một dạng “smell” (mùi hôi) báo hiệu sự phình to và gia tăng độ phức tạp của hệ thống. Khi đó, việc nhận ra những tín hiệu như độ phức tạp và quy mô ngày càng tăng sẽ giúp chúng ta dự đoán được thời điểm cần thay đổi kiến trúc để giải quyết vấn đề trước khi nó trở thành khủng hoảng vận hành.

Sau tất cả những thứ “cool”, compliance mới là điểm kết thúc

Thật ra bản thân mình thường khá dị ứng với những bài viết hoặc video chỉ toàn các buzzword như “MiCrOsErViCe”, “cLoUd nAtIvE”, “aI-NaTiVe”… Có thể khi còn ngồi trên ghế nhà trường, những khái niệm này đủ hấp dẫn để chúng ta dành hàng năm trời theo đuổi. Nhưng khi bước chân vào thế giới thực, chúng ta sẽ nhận ra rằng sau tất cả những thứ “cool” đó, compliance mới là điểm kết thúc. Dù bạn có xây dựng một hệ thống với kiến trúc hiện đại, sử dụng những công nghệ mới nhất, nếu nó không đáp ứng được các yêu cầu về bảo mật, tuân thủ quy định hoặc các tiêu chuẩn ngành, thì cuối cùng nó vẫn sẽ thất bại.

Còn nhớ trend “Openclaw AI - Trợ lý ảo”, câu đầu tiên ở page giới thiệu:

“Install: One-liner; Works everywhere. Installs everything. You’re welcome”.

Nghe có vẻ rất tiện lợi và dễ dàng, nhưng nếu bạn có “một chút” kinh nghiệm trong ngành công nghiệp phần mềm, bạn sẽ biết rằng việc cài đặt một công cụ mới không chỉ đơn giản là chạy một dòng lệnh, nó còn liên quan đến vấn đề bảo mật và tuân thủ quy định.

Bản thân mình cũng từng trải qua những tình huống tương tự. Dù hệ thống được phát triển rất sát với business outcome, nhưng nếu không đáp ứng được các yêu cầu về compliance thì cuối cùng vẫn sẽ gặp phải những rắc rối không đáng có.

Đó là một lời nhắc nhở quan trọng rằng:

Phát triển phần mềm không chỉ là xây dựng thứ hoạt động được. Nó còn là xây dựng thứ có thể được vận hành, kiểm soát và quản trị trong môi trường doanh nghiệp thực tế.

Một video về công nghệ, nhưng những điều đáng lưu tâm nhất lại… không phải công nghệ

Sau khi xem hết video, điều đọng lại với tôi không phải là Atlassian, không phải cách họ xây dựng platform, cũng không phải những công nghệ họ sử dụng. Điều đọng lại là cách họ tiếp cận vấn đề, cách họ giải quyết vấn đề và cách họ nhìn nhận những thay đổi trong ngành công nghiệp phần mềm. Bản thân mình ngồi xem video gần như ngồi xem live một buổi system design interview kéo dài hơn ba mươi phút: không phải để liệt kê công nghệ đã sử dụng, cũng không phải để khoe thành tích, mà để mô tả những vấn đề thực tế, những quyết định kiến trúc đã được đưa ra, những giới hạn của hệ thống và những bài học rút ra từ quá trình đó. Và có lẽ đó mới là điều tạo nên giá trị dài hạn của một kỹ sư.

Sau tất cả, phát triển phần mềm không nằm ở việc sử dụng framework nào hay công nghệ gì. Điều quan trọng hơn là khả năng nhận diện vấn đề và giải quyết vấn đề. Và đó cũng chính là giá trị có thể theo một kỹ sư trong suốt sự nghiệp của mình.

Link video: I was laid off by Atlassian - Vasilios Syrakis

TP. Hồ Chí Minh, ngày 01 tháng 06 năm 2026. Threevien Lab Blog.

Over the past few years, layoffs at Big Tech companies have become anything but unusual. Every time news like this appears, people in the tech industry tend to react with a familiar sigh: “Was it AI again?”

Most of our attention is usually drawn to the same recurring questions: who was affected, why they were affected (was it because of AI?), and whether the technology market is still as attractive as it was during the 2019-2022 period.

There are no truly clear answers. Every layoff leaves behind hard-earned lessons for those who experience it firsthand. Some of those lessons were shared by a former Atlassian employee. What caught my attention, however, was not the layoff itself. He spent almost no time complaining about or blaming Atlassian. Instead, more than forty minutes of the video were dedicated to discussing technical challenges, systems that had been built, organizational problems they had encountered, and how his team addressed them.

That naturally led to a more thought-provoking question:

After spending years working at a major technology company, what truly remains once the company’s name is removed from our professional résumé?

No Position Is Truly Safe

One of the first takeaways from the video is a fairly simple reality: No position is truly safe.

For many years, the technology industry created the impression that if an engineer was skilled enough, experienced enough, or employed by a prestigious company, they would be less vulnerable to market fluctuations.

Reality has demonstrated the opposite.

Recent workforce reductions have not affected only junior engineers. They have impacted senior engineers, staff engineers, principal engineers, and even individuals who spent years building the core platforms of their organizations.

This is not a reflection of their capabilities. It reflects the fact that businesses continuously optimize for business objectives.

From that perspective, an engineer’s long-term value does not reside in the company they work for. It resides in their ability to solve problems and in the experiences they can carry from one system to another.

A Platform Succeeds Not Because It Exists, But Because People Actually Need It

One theme that appeared throughout the video was platform engineering.

When we hear the word “platform,” many of us—including those who spend countless hours building the foundational layers of such systems—often think of internal platforms consisting of numerous tools, dashboards, automation frameworks, or service meshes.

However, what was discussed in the video suggests a different perspective:

A platform is not successful simply because it exists. A platform is successful only when the rest of the organization uses it.

Building a platform is often the easier part. Convincing dozens or hundreds of teams to adopt that platform is the harder challenge.

A platform may reduce operational costs, standardize deployment processes, and simplify the development of new services. Yet if no team wants to use it, then fundamentally, it is still a failure.

During my time at FTEL, I have worked with, operated, and contributed to the development of several platforms. Through those experiences, I realized that a platform only creates real value when it achieves broad adoption across the organization.

This is not unique to FTEL. The same pattern exists in many companies. The larger the organization becomes, the more saturated it becomes with ideas. Dozens of ideas are proposed every day, but only a small fraction are actually implemented and ultimately used by real teams.

When Thinking About Innovation, Do Not Forget Migration and Maintenance

(i). Every legacy service carries its own history.

(ii). Every team operates under its own constraints.

(iii). Every application contains its own exceptions.

Another topic discussed in the video was the migration from legacy architectures to new platforms. Within the software industry, we often celebrate building new systems while underestimating the cost of migration.

In reality, many systems do not fail because the technology is inadequate. They fail because users cannot be successfully migrated to the new model. I experienced this myself while developing a Centralized API Hub over roughly three months. What I failed to anticipate was that persuading other teams to adopt the new API Hub would be significantly more difficult than building it. In practice, the migration process took more than eighteen months to complete.

Sometimes, the hardest problem is not building something new. It is helping the people who rely on existing systems embrace change.

Automation Can Be a Double-Edged Sword

One of the most interesting examples in the video was the discussion around Envoy and the management of large-scale proxy configurations. If every service manages its own routes, networking policies, and proxy configurations, the number of configurations grows alongside organizational scale. Once the number of services reaches hundreds or thousands, expecting engineers to manually manage each individual configuration is no longer practical.

At that point, the challenge facing the organization is no longer automation itself. The challenge is designing an appropriate abstraction layer. In practice, almost everyone involved in software development goes through a phase where they want to automate everything:

“Why are we still clicking through forms and filling out fields manually? Why not automate it?”

But after the automation is completed, we often discover that automating a process is not the final destination. It is merely one step in building a larger system. Without careful design, automation can become a double-edged sword, where workflows overlap, maintenance becomes increasingly difficult, and debugging grows significantly more complex.

Complexity and Scale Are Early Signals of Future Architectural Change

Near the end of the video, there was a discussion about how having every backend service independently implement authentication, authorization, logging, and similar capabilities eventually leads to a maze of thousands of configurations that become increasingly difficult to manage.

To address this problem, Atlassian’s engineering teams placed shared Anti-DDoS protection in front of Envoy proxies, centralized access-log processing within Envoy, and implemented authentication and authorization capabilities as sidecars running alongside Envoy.

At the early stages of software development, this often seems perfectly reasonable:

• One service only needs a few lines of code for user authentication.
• Another service only needs a middleware component for logging.
• A third service only needs a library for authorization.

However, as the number of services grows over time, everything begins to change.

Hundreds of services generate logs in different formats.

Hundreds of security mechanisms emerge.

Hundreds of locations require patching and maintenance.

This is a form of architectural smell that signals growing complexity and increasing system sprawl.

Recognizing signals such as rising complexity and expanding scale allows us to anticipate when architectural changes are necessary and address problems before they evolve into operational crises.

After All the “Cool” Things, Compliance Is Where the Journey Ends

Personally, I’ve always had a certain skepticism toward articles or videos that are packed with buzzwords like “MiCrOsErViCe”, “cLoUd NaTiVe”, or “AI-Native”.

Perhaps when we were still in school, these concepts were exciting enough for us to spend years chasing after them. But once we step into the real world, we eventually realize that after all the “cool” technologies and architectural trends, compliance is where the journey actually ends.

You can build a system with a modern architecture and adopt the latest technologies available. Yet if it fails to meet security requirements, regulatory obligations, or industry standards, it will ultimately fail regardless. I still remember the recent trend around “OpenClaw AI - Virtual Assistant.” The very first sentence on its landing page was:

“Install: One-liner; Works everywhere. Installs everything. You’re welcome.”

It certainly sounds convenient. But if you have even a modest amount of experience in the software industry, you know that deploying a new tool is rarely as simple as running a single command. It also raises questions about security, governance, software supply chain risks, and compliance requirements.

In a personal project, a one-line installation command may be perfectly acceptable. In an enterprise environment, however, that same command could trigger reviews from security teams, platform teams, compliance officers, and auditors long before it ever reaches production.

That is often the gap between technology as a demo and technology as a product that can be operated at scale within a real organization.

I have experienced similar situations myself. Even when a system is closely aligned with business outcomes, failure to satisfy compliance requirements inevitably leads to unnecessary complications and risks. It serves as an important reminder:

Software engineering is not only about building something that works. It is also about building something that can be operated, audited, and governed within a real enterprise environment.

A Technology Video, Yet the Most Important Lessons Were Not About Technology

After finishing the video, what stayed with me was not Atlassian, nor the platforms they built, nor the technologies they used.

What remained was the way they approached problems, the way they solved them, and the way they viewed change within the software industry.

Watching the video felt almost like attending a live system design interview that lasted more than thirty minutes—not to list technologies, nor to showcase achievements, but to describe real-world problems, architectural decisions, system limitations, and the lessons learned throughout the journey.

And perhaps that is what truly creates long-term value for an engineer.

In the end, software engineering is not defined by which framework or technology we use. What matters more is the ability to identify problems and solve them. That is the value that stays with an engineer throughout an entire career.

Link video: I was laid off by Atlassian - Vasilios Syrakis

Ho Chi Minh City, June 1, 2026. Threevien Lab Blog.