Каждый выбор — это чертёж
Жизнь — не поток.
Она строится из решений.
Ты — архитектор, хочешь ты того или нет.
#архитектура #жизнь #выбор #структура #осознанность
→ https://t.me/tribute/app?startapp=srfZ
P.S. Made by a madman — Kirill Bereznev
https://t.me/tribute/app?startapp=srfZ
Как работает DNS в Linux. Часть 1: от getaddrinfo до resolv.conf
Привет, Хабр! Меня зовут Анатолий Кохан, я — DevOps-инженер в К2Тех. Когда мы вводим в браузере имя сервера или доменное имя сайта, выполняем ping или запускаем любое удаленное приложение, операционная система должна преобразовать указанные имена в IP-адреса. Этот процесс называется разрешением доменного имени. На первый взгляд он может показаться весьма прозрачным, однако за ним скрывается многослойный механизм. Данная статья — начало серии, посвященной низкоуровневой архитектуре разрешения имен. Поговорим о том, как устроен этот процесс в Linux на уровне ядра, различных библиотек C и системных вызовов.
https://habr.com/ru/companies/k2tech/articles/919194/
#облачные_сервисы #linux #sre #devops #dns #системное_администрирование #инженерные_системы #инфраструктура #системный_инжиниринг #архитектура
Инфраструктура, которую видно: как мы делаем визуализацию облака
Привет! На связи Михаил Шпаков, руководитель разработки в Timeweb Cloud. Мы создаём облако, в котором удобно запускать и управлять проектами: от простых ВДС до масштабных решений с Kubernetes и десятками интеграций. Мы много думаем о том, как сделать инфраструктуру не только стабильной, но и понятной . Когда вы работаете в облаке, всё выглядит структурировано: список серверов, IP-адресов, баз данных, кластеров. Но в какой-то момент возникает вопрос: а как всё это связано между собой? Что подключено к балансировщику? В какой сети находятся серверы? Почему не пингуется база? Ответы есть, но они спрятаны в разных разделах интерфейса или требуют обращения в поддержку. Мы в Timeweb Cloud решили это изменить. Инфраструктура — это карта, а не таблица. Её нужно рисовать, а не запоминать. Мы сделали визуальную карту, на которой можно не просто увидеть ресурсы, но и настроить их расположение как в реальной жизни: сгруппировать, пояснить, добавить связи и комментарии. Это не просто картинка — это инструмент, который помогает понимать, как всё устроено, и быстрее находить проблемы. Это как перейти от чтения логов к полноценной карте: наглядно, понятно, живо. Визуализация стала тем самым недостающим элементом, который помогает по-настоящему понять , как устроена инфраструктура.
https://habr.com/ru/companies/timeweb/articles/916214/
#облако #devops #инфраструктура #визуализация #схема #reactflow #архитектура #timeweb_статьи
Как работает DNS в Linux. Часть 1: от getaddrinfo до resolv.conf
Привет, Хабр! Меня зовут Анатолий Кохан, я — DevOps-инженер в К2Тех. Когда мы вводим в браузере имя сервера или доменное имя сайта, выполняем ping или запускаем любое удаленное приложение, операционная система должна преобразовать указанные имена в IP-адреса. Этот процесс называется разрешением доменного имени. На первый взгляд он может показаться весьма прозрачным, однако за ним скрывается многослойный механизм. Данная статья — начало серии, посвященной низкоуровневой архитектуре разрешения имен. Поговорим о том, как устроен этот процесс в Linux на уровне ядра, различных библиотек C и системных вызовов.
https://habr.com/ru/companies/k2tech/articles/919194/
#облачные_сервисы #linux #sre #devops #dns #системное_администрирование #инженерные_системы #инфраструктура #системный_инжиниринг #архитектура
Галопом по архитектуре. Часть 2. Архитектура с нуля
В прошлой части мы разобрали: 1. Что техническая реализация заметно влияет на успехи бизнеса, хоть и не очень критично; 2. Что из всех аспектов технической реализации наибольший вклад в успех вносит именно архитектура; 3. Что самое важное свойство архитектуры - максимальная независимость команд друг от друга; 4. Что это свойство вытекает напрямую из двух фундаментальных характеристик программного обеспечения: coupling и cohesion, где coupling - характеристика связи двух точек системы/кодовой базы; а cohesion - характеристика того, насколько плотно упакованы такие связи в компоненты. С этим багажом заканчиваем с теорией и переходим к практике. Теперь, когда мы знаем, что хорошо, а что плохо, необходимо понять, как этого добиться. Тут надо задать два вопроса с совершенно разными ответами: 1. Как не допустить появления связанной архитектуры и сразу сделать хорошо? 2. Как исправить уже связанную архитектуру? В этой части постараюсь развернуто ответить именно на первый, оставив второй на десерт.
Почему Feature-Sliced Design (FSD) не спасет ваш проект
Каждый разработчик рано или поздно сталкивается с вопросом: как организовать проект так, чтобы он не превратился в хаос? Или как исправить проект, в котором уже царит хаос? Начинается всё одинаково: мы делаем простое MVP или проект с ограниченным функционалом, не заморачиваемся по поводу архитектуры и организации кода, ведь проект небольшой и несложный, а сделать его нужно уже здесь и сейчас. Но время идёт, и у бизнеса появляются всё новые требования. Какие-то изначальные идеи полностью отменяются или меняются до неузнаваемости, разрастается команда, дизайн меняется несколько раз, появляется необходимость покрыть проект тестами, а иногда и необходимость вообще сменить стек технологий. И вот вы уже работаете над кодом, в котором становится всё сложнее вносить изменения в существующий функционал. Всё держится на костылях, становится трудно ориентироваться в куче файлов, и кажется, что всё устроено как-то не так, как должно быть. В этот момент мы начинаем задаваться вопросом: “а как нужно писать и организовывать код на самом деле?”. В поисках ответа мы читаем статьи, смотрим обучающие видео, доклады и неизбежно натыкаемся на Feature-Sliced Design (FSD).
https://habr.com/ru/articles/919316/
#fsd #архитектура #методология #организация_кода #фронтенд #фронтендразработка #паттерны #паттерны_проектирования
Функциональное и объектно-ориентированное проектирование
В современном обучении программированию, как правило, основное внимание уделяется парадигме объектно-ориентированного программирования (OOP) и вытекающей из неё методологии объектно-ориентированного проектирования (OOD). Определённый ренессанс в наше время испытывает парадигма функционального программирования, но практически никогда в связке с ней не рассматривается функциональное проектирование. Попытаемся осветить наше видение этих вопросов.
https://habr.com/ru/articles/919190/
#проектирование #функциональное_проектирование #сверхувниз #снизувверх #ООП #декомпозиция #синтез #архитектура #функции
Галопом по архитектуре. Часть 1. Структурный дизайн
Когда вы в последний раз приходили на проект и думали: какая удачная получилась архитектура, кто тот гений с зарплатой вдвое больше, чем у меня, что придумал этот алмаз? Я вот такого не припомню, хотя мне удалось поработать лично с десятком разных архитектур в самых разных системах от дремучих легасей, госухи и банков до международных технологических и финансовых компаний. Окей, но при этом софт же как-то живет, выполняет задачи, а бизнес приносит деньги. Получается, что архитектура-то, наверное, не очень и обязательная для успеха бизнеса? Вообще говоря, очень часто так оно и есть. Однако из всех технических активностей вряд ли есть что-то важнее, чем хорошая архитектура. И с этого тезиса давайте и начнем.
https://habr.com/ru/articles/919168/
#архитектура_по #архитектура #архитектура_приложений #архитектура_системы #архитектура_систем
10 Принципов отказоустойчивости (с примерами на Javascript)
С хорошей отказоустойчивостью интерфейс остаётся стабильным и понятным, пользователь получает предсказуемый и комфортный опыт, а сбои отдельных компонентов не приводят к сбоям всей системы. В этой статье речь не будет идти о конкретных примерах реализации повышения отказоустойчивости. Понять то, что нужно подключать сервисы мониторинга ошибок вы можете и без меня. Хорошая отказоустойчивость начинается с мышления. Я хочу, чтобы эта фраза въелась вам в самую подкорку. Важно не просто латать ошибки по мере их появления, а комплексно подходить к решению — формировать правильное понимание, разрабатывать устойчивые подходы и строить систему, способную адекватно реагировать на возможные сбои. Принципы описанные далее универсальные и подойдут к большому количеству сфер, даже вне области информационных технологий. Перейти к 10 принципам
https://habr.com/ru/articles/918574/
#отказоустойчивость #UX #архитектура #ошибки #стабильность #fallback #устойчивость #frontend #error_handling #надежность
Vertical Slice Architecture на примере C# — простая и удобная архитектура для небольших (и не только) пректов
Простой вопрос: делая задачу, касающуюся API - вы чаще работаете с одним эндпоинтом, или пишите, условные, репозитории, которые используются сразу в нескольких эндпоинтах? Скорее всего, первое, тогда почему мы разбиваем проект по слоям, а не по фичам (эндпоинтам)? Это видно в часто используемых нынче архитектурных подходах: Layered, Clean Architecture, Onion, и так далее. Не буду выделять что-то конкретное и объясню общую разницу в подходах: Vertical Slice Architecture (VSA) строится вокруг каждого отдельного feature-слайса (эндпоинта, как самый простой пример), а не на вокруг слоев. То есть, если код относится к конкретному эндпоинту, мы не размазываем его по всему проекту в папках Commands/Services/Repositories/DTOs и т.п., а кладем в одно место, там где и будет находиться эндпоинт Главный принцип - уменьшаем связанность между слайсами (фичами), увеличиваем связанность внутри слайса
https://habr.com/ru/articles/916704/
#c# #vertical_slice #minimal_api #архитектура #net #software_design
Простой вопрос: делая задачу, касающуюся API - вы чаще работаете с одним эндпоинтом, или пишите, условные, репозитории, которые используются сразу в нескольких эндпоинтах? Скорее всего, первое, тогда...
Kirill Bereznev
Habr
Habr 25+
