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.
Когда инфраструктура только начинает расти, почти всегда возникает один и тот же вопрос.
Лучше создать одну мощную виртуальную машину и разместить на ней все сервисы или сразу разделить их на несколько отдельных?
На первый взгляд первый вариант выглядит привлекательнее.
Меньше серверов.
Меньше настроек.
Проще следить.
Но это преимущество обычно сохраняется недолго.
Представьте, что на одной виртуальной машине работают сайт компании, база данных, система мониторинга и корпоративная Wiki.
Пока все функционирует стабильно, никаких проблем не возникает.
Затем приходит время обновить базу данных.
Для этого требуется перезагрузка.
Вместе с ней становятся недоступны и остальные сервисы, хотя к обновлению они отношения не имеют.
Через несколько месяцев появляется новая задача — увеличить объем памяти для базы данных.
Теперь приходится менять параметры всей виртуальной машины, хотя сайту дополнительные ресурсы не нужны.
Постепенно таких зависимостей становится все больше.
Любое изменение начинает затрагивать сразу несколько систем.
Совсем иначе выглядит ситуация, когда сервисы разделены.
Сайт работает в одной виртуальной машине.
База данных — в другой.
Мониторинг — в третьей.
Теперь каждую из них можно обновлять независимо.
Если один сервис неожиданно начинает активно использовать процессор, остальные продолжают работать в привычном режиме.
Даже поиск неисправностей становится проще.
Когда все находится в одном месте, сначала приходится выяснять, какое именно приложение стало причиной высокой нагрузки.
Когда сервисы разделены, круг поиска значительно уже.
Конечно, это не означает, что для каждого небольшого приложения обязательно создавать отдельную виртуальную машину.
Иногда несколько тесно связанных сервисов вполне логично работают вместе.
Но если система развивается, получает собственные обновления и имеет разные требования к ресурсам, разделение обычно окупается довольно быстро.
Есть интересное наблюдение.
Когда инфраструктура небольшая, кажется, что лишние виртуальные машины только усложняют работу.
Через несколько лет взгляд меняется.
Гораздо сложнее становится сопровождать одну огромную систему, в которой все зависит друг от друга.
Современные облачные платформы позволяют создавать виртуальные машины за считанные минуты.
Поэтому сегодня главным ограничением становится уже не количество серверов, а понятная архитектура.
Чем проще ответить на вопрос «где работает этот сервис и что произойдет, если его остановить», тем легче развивать инфраструктуру в будущем.
Именно поэтому при проектировании облачной среды часто думают не о том, как уменьшить количество виртуальных машин, а о том, как уменьшить количество ненужных зависимостей между ними.
Share
