The post has been translated automatically. Original language: Russian
When a new internal service appears, many people follow the simplest path.
There is a server on which the processor, memory and disk are free. This means that you can install another application there.
At first it really seems convenient.
The website is running on the same server.
There is a database nearby.
There's also a monitoring system.
Later, the corporate Wiki appears.
Then a VPN.
After a while, the file storage is added.
While there are few users, everything is functioning without noticeable problems.
But a year passes, and the question arises: what exactly can be rebooted, updated, or migrated so as not to break anything?
It turns out that it is no longer easy to answer.
All services start to depend on each other.
If you need to update the operating system, you have to consider several applications at once.
If one service suddenly starts actively using the processor or memory, this affects the work of the others.
And if you need to transfer only one of them to another server, you won't be able to do it quickly.
That is why virtualization has changed the way we build infrastructure.
Today, a separate virtual machine is not a luxury or a sign of redundancy.
This is a way to make the system more understandable.
Each service gets its own environment.
It can be updated independently of the others.
Restarting one application does not affect the neighboring ones.
It's easier to look for the causes of errors.
It's easier to migrate services.
It's easier to plan development.
Of course, it doesn't always make sense to create a separate VM for each small task either.
It is important to maintain a balance.
But if a service performs an independent function, has its own lifecycle, or requires separate maintenance, isolation usually pays off.
There is an interesting observation.
When the infrastructure is just developing, everyone is thinking about computing resources.
Is there enough memory?
Is there enough CPU?
How much disk space should I choose?
After a few years, the questions become completely different.
How easy is it to update this service?
Is it possible to transfer it without stopping the rest?
Is it clear to the new employee exactly where he works?
It is then that it becomes noticeable that a well-divided infrastructure saves not so much processor time as people's time.
Cloud technologies are valued not only for the ability to quickly create a virtual machine.
The main advantage comes later, when the infrastructure grows. The more independent and understandable components it has, the easier it is to maintain order and the less likely it is that a change in one place will unexpectedly affect the operation of a completely different service.
Есть привычка, которая досталась многим IT-командам еще со времен физических серверов.
Если приложению требуется 4 ГБ оперативной памяти, лучше сразу выделить 16. Если достаточно двух процессорных ядер, пусть будет восемь. Вдруг когда-нибудь пригодится.
Когда оборудование покупается на несколько лет вперед, такой подход понятен. После установки нового сервера быстро добавить память уже не получится.
Но в облачной инфраструктуре логика немного меняется.
Представьте, что компания запускает новый внутренний сервис. На старте им пользуются десять сотрудников.
Опасаясь роста нагрузки, для виртуальной машины сразу выделяют восемь процессорных ядер, 32 ГБ памяти и большой объем дискового пространства.
Проходит полгода.
Сервисом по-прежнему пользуются те же десять человек.
Мониторинг показывает, что процессор большую часть времени загружен на несколько процентов, а значительная часть памяти остается свободной.
Такая ситуация встречается чаще, чем кажется.
Лишние ресурсы не делают приложение быстрее сами по себе. Если программе хватает двух ядер, дополнительные шесть будут просто простаивать.
При этом появляется другой эффект.
Когда в инфраструктуре десятки виртуальных машин с избыточными параметрами, становится сложнее понимать, сколько ресурсов действительно требуется компании.
Планировать развитие тоже становится труднее.
Это не означает, что нужно выделять минимум возможного.
Небольшой запас всегда полезен. Он помогает пережить кратковременные пики нагрузки и дает время спокойно реагировать на изменения.
Вопрос в другом.
Запас должен быть разумным.
Одно из преимуществ облачной платформы как раз заключается в том, что ресурсы можно изменить позже.
Если проект начал расти, увеличить объем памяти или количество процессорных ядер обычно значительно проще, чем во времена физических серверов.
Поэтому многие команды используют другой подход.
Сначала выделяют столько ресурсов, сколько действительно необходимо.
Затем наблюдают за нагрузкой.
И только если появляются признаки роста, постепенно увеличивают конфигурацию.
Такое решение имеет еще одно преимущество.
Оно заставляет опираться не на предположения, а на реальные данные.
Не на вопрос «А вдруг когда-нибудь понадобится?», а на графики использования процессора, памяти и дисковой подсистемы.
Со временем именно эти данные становятся лучшим помощником при планировании инфраструктуры.
Облачные технологии ценят за гибкость. И эта гибкость работает в обе стороны.
Она позволяет не только быстро увеличивать ресурсы, когда проект растет, но и не резервировать их заранее без необходимости. Иногда самое эффективное решение — не выбрать максимально возможную конфигурацию, а выбрать ту, которая соответствует сегодняшним задачам и может без лишних сложностей измениться завтра.
Share
