Comments 18
Хотел написать — «ну и кто теперь в ОБЛАКА захочет» — ведь собственного админа легче «вздрючить». НО — неоднозначно это все, надо просчитывать экономическую целесообразность владения инфраструктурой в облаке (с учетом вот таких вот траблов, на которые повлиять не сможешь, однако — не частых) либо собственной — про админа не говорю (даже в случае облака кто-то должен рулить инфраструктурой, просто сервера у него будут «несколько подальше»). А с учетом того, что компания Microsoft на десктопных-серверных продуктах в лицензионных соглашениях совершенно снимает с себя ответственность за различные потери, в том числе и из-за обновлений, то в облачных продуктах это, наверное, еще безответственнее.
UFO just landed and posted this here
Хотел написать — «ну и кто теперь в ОБЛАКА захочет» — ведь собственного админа легче «вздрючить».
Дык в конечном счете админы и менеджмент тех. отдела и решают переезжать в облака или нет.
И кого будут *ть за проколы, один из плюсов для админов при переезде.
ЗЫ уже попкорн кончается за факапами микрософта наблюдать...
Ну так несколько месяцев назад. Мне кое-кто утверждал, что дескать AD не падает, а если и падает, то его легко поднять. Ну как легко, если взять достаточно большой AD, то выясняется, что внезапно, даже люди, которые знают структуру и код приложения как свои пять пальцев и то не в состоянии откатить и поднять ее мгновенно. Что касается редко, но случается. То это случается не так уж и редко, просто большинство сбоев не достигают таких последствий как этот.
Моя мысль и была немного про то, что чтобы понять стоимость-трудозатраты-отзывчивость на поднятие AD в облаке или внутри собственной конторы.
Ну так и та, и другая операция требует высококвалифицированного админа, так что разницы по большому счету и нет между: я тут поднял samba/ я развернул AD локально/ я развернул AD в облаке. Если вы основное требование не выполняете, результат всегда предсказуем. Не нужно вестись на маркетинговые фишки вроде, «даже чайник поднимет AD». Поднять, может и поднимет, но обслуживать все равно не сможет. А уж админ сам разберется, что ему поддерживать проще. Мы по большому счету ленивы в положительном плане. т. е. выбираем путь где для решения большинства задач нужно меньше телодвижений.
А там не AD DS внутри)
AD по своей сути везде одинакова. Виртуальная древовидная структура объектов и директорий поверх некоей БД. Скорее всего отличие Azure только в том, что нижним слоем выбрана кластерная БД. Но и это как мы видим не помогает ввиду чрезмерной переусложненности и связанности большинства решений MS. Меня не удивит, если механизм репликации AD не сработал, так как опирался на учетные данные сохраненные в AD.
Вы ошибаетесь. Azure Active directory не имеет никакого отношения к Windows Server Active Directory (это то что раньше было известно как просто Active Directory), и из общего у них только собсно кусок названия.
Azure AD по функционалу и возможностям является полным аналогом того же Keycloak (опенсорсный SSO и Identity Management сервер). МС не признается, что там внутри (во всяком случае я не находил такой информации), но не удивлюсь если у за фасадом спрятана какая-нить из опенсорсных SSO систем.
Azure AD по функционалу и возможностям является полным аналогом того же Keycloak (опенсорсный SSO и Identity Management сервер). МС не признается, что там внутри (во всяком случае я не находил такой информации), но не удивлюсь если у за фасадом спрятана какая-нить из опенсорсных SSO систем.
А что по вашему Keycloak, как не дальнейшее развитие Directory? Ну сменили LDAP на HTTP, ну бызы стали использовать SQL а не KV, а вместо LDIF теперь YAML. Принцип остался прежним. Даже термины многие перекочевали. Я даже смотрю на эти описания объектов в yaml и они во многом напоминают старые добрые ldif-файлы.
Вы в целом правы: ряд возможнойстей AAD (такие, как поддержка специфичных для приложений атрибутов) не реализованы в AD DS и, скорее всего, AAD использует другую технологию.
Только вряд ли MS использует чью-то стороннюю разработку: у нее с давних времен был для синхронизации каталогов свой, весьма навороченный (и весьма недешевый, как и все предназначенное для кровавого энтерпрайза) Identity Management Server (его несколько раз переименвывали, в 2016 он назывался Microsoft Identity Management server, как сейчас — не знаю). Кстати, урезанная (по уши) версия этого продукта используется под названием AAD Connect для синхронизации AD на земле и AAD.
Ну, и продукт для SSO у MS тоже есть (на земле это — роль AD FS в Windows Server).
Только вряд ли MS использует чью-то стороннюю разработку: у нее с давних времен был для синхронизации каталогов свой, весьма навороченный (и весьма недешевый, как и все предназначенное для кровавого энтерпрайза) Identity Management Server (его несколько раз переименвывали, в 2016 он назывался Microsoft Identity Management server, как сейчас — не знаю). Кстати, урезанная (по уши) версия этого продукта используется под названием AAD Connect для синхронизации AD на земле и AAD.
Ну, и продукт для SSO у MS тоже есть (на земле это — роль AD FS в Windows Server).
знают структуру и код приложения как свои пять пальцев
Боюсь, вы слишком хорошего о них мнения. Ведь наверняка разные элементы инфраструктуры в ведении разных отделов и уж тем более отдельно от разработки.
И, скорее всего, даже организовать совещание всем, кто понимает, как оно устроено и что могло привести к отказу — проблематично.
Мы нажимаем какие-то кнопки и смотрим, помогло или нет. :(
«мы откатили изменение, которое, вероятно, является источником воздействия», «мы не наблюдаем увеличения количества успешных подключений после отката недавнего изменения», «мы перенаправляем трафик в альтернативную инфраструктуру, чтобы улучшить взаимодействие с пользователями», «мы наблюдаем улучшения в работе нескольких служб после применения мер по снижению рисков»
Мы нажимаем какие-то кнопки и смотрим, помогло или нет. :(
UFO just landed and posted this here
Таки мне интересно, какие SLA у Microsoft на Azure AD?
У Oracle Cloud есть SLA на Availability, control plane Manageability, и Performance.
При простое заказчик получает скидку на оплату сервисов.
Let me google that for you:
g.zeos.in/?q=SLA%20%D1%83%20Microsoft%20%D0%BD%D0%B0%20Azure%20AD
g.zeos.in/?q=SLA%20%D1%83%20Microsoft%20%D0%BD%D0%B0%20Azure%20AD
Sign up to leave a comment.
Причина масштабного сбоя облака Microsoft 365 определена — единой точкой отказа стала Azure Active Directory