Как работают быстрые приготовления для статей на Хабр – чтобы получить 20к просмотров за сутки Готовите вы, стало быть, статью к себе на Хабр. При прочих равных Хабр – долго. В среднем по больнице на статью с нуля уходит 8-12 часов, начиная с "у нас всё обычное / мне не о чем написать" до финальной вёрстки. Но есть быстрые трюки. Каждый из них занимает в пределах получаса и при этом обладает потенциалом, чтобы вывести статью на качественно более классный уровень. Например, дошлифовка заголовка и открывашки. === Пусть делаем переводную статью. Что имеете в оригинале: Заголовок: Goodbye Microservices: From 100s of problem children to 1 superstar Открывашка: Microservices is a service-oriented software architecture in which server-side applications are constructed by combining many single-purpose, low-footprint network services. The touted benefits are improved modularity, reduced testing burden, better functional composition, environmental isolation, and development team autonomy. The opposite is a Monolithic architecture, where a large amount of functionality lives in a single service which is tested, deployed, and scaled as a single unit. Twilio Segment adopted this as a best practice early-on, which served us well in some cases, and, as you’ll soon learn, not so well in others. In the early days of Twilio Segment, we reached a tipping point with a core piece of Twilio Segment’s product. It seemed as if we were falling from the microservices tree, hitting every branch on the way down. Instead of enabling us to move faster, the small team found themselves mired in exploding complexity. Essential benefits of this architecture became burdens. As our velocity plummeted, our defect rate exploded. Eventually, the team found themselves unable to make headway, with 3 full-time engineers spending most of their time just keeping the system alive. Something had to change. This post is the story of how we took a step back and embraced an approach that aligned well with our product requirements and needs of the team.