Очень часто при взаимодействии с заказчиками на первоначальных этапах проекта мы сталкиваемся с различными разногласиями в вопросе защиты и использования персональных данных компании-клиента. Данные опасения весьма справедливы, и действительно FSM-система хранит информацию о клиентах, историю обслуживания, способы доступа к объектам обслуживания, отчеты об обслуживании оборудования и т.д.
SaaS или On-Premise (локальное или облачное развертывание) в разрезе безопасности использования данных.
Каждой компании важно оправдать ожидания клиентов, особенно публичному сервису. В случае облачных провайдеров клиенты приходят, чтобы быстро и привычным способом получить, например, виртуальную машину. Их мало волнует, что бывает взрывной рост запросов, в ЦОД приезжает новое железо, а инженеры заняты масштабной миграцией другого пользователя. Клиентам важно быстро получить услуги и отказоустойчивость сервиса. Любое, даже незначительное изменение во внутреннем пространстве сервиса может привести к проблемам на стороне клиентов, как минимум к увеличению времени создания машины.
Константин Еремин, старший системный администратор дежурной службы «Облачной платформы Selectel», рассказал, как поменять архитектуру облака на OpenStack и не поломать пользовательский опыт. На примере выдуманного провайдера Vanilla cloud solutions он объяснил, как определить масштаб проблемы. Почему, перебрав различные варианты, разработчики пришли к Apache Airflow? Какую схему использовали для реализации своих задач и что им удалось сделать с облачным сервисом с помощью выбранного инструмента? Рассказываем под катом.
Пару месяцев назад, когда Oracle представила в своем публичном облаке двухсокетные серверы с 80-ядерными ARM-процессорами, в англоязычном блоге Тодда Шарпа появилась статья о том, как запустить сервер Minecraft в облаке. Теперь, когда Oracle добавил эти процессоры в Always Free Tier, все стало еще интереснее — вы можете совершенно бесплатно и неограниченно создавать и использовать виртуальные машины, использующие в общей сложности 4 ядра и 24GB памяти. Однако за два месяца изменился интерфейс Публичного Облака Oracle и версии программ, которые применяются для запуска сервера Minecraft. Поэтому сегодня я хочу поделиться своим опытом прохождения этого же пути — с учетом изменений и подводных камней, а также в русскоязычным интерфейсом. Всех любителей Minecraft, а также заинтересованных в создании бесплатных виртуальных серверов, прошу под кат!
С помощью облачного Amazon Relational Database Service (Amazon RDS) можно разворачивать базы данных и фокусироваться именно на работе с ними, не отвлекаясь на администрирование сервера или операционки. Сам вендор так и позиционирует эти облачные сервисы: “Amazon Relational Database Service (Amazon RDS) – это веб-сервис, который позволяет легко создавать, использовать и масштабировать реляционные базы данных в облаке. Он предоставляет экономичные масштабируемые ресурсы для стандартных реляционных БД и выполняет типовые задачи по администрированию баз данных.”
Для защиты данных, хранящихся на этих облачных инстансах, AWS умеет делать снимки состояния БД. А что если хочется реализовать разные политики хранения или выполнять репликацию этих снимков в другие учетные записи или другие регионы AWS Regions? С этими задачами справляется Veeam Backup for AWS.
Как-то раз рассматривая очередной запрос от пользователя на право работы с корпоративной учеткой во внешнем сервисе, наткнулся на странный список URL который, вероятно, раскрывает список клиентов автора приложения в Enterprise applications.
Потратив 8 минут на прочтение данного текста, вы узнаете:
1) Какой сервис лучше выбрать для проведения и создания опросов
2) Как создать опрос
3) Какие есть подводные камни при создании онлайн опроса
Сначала вам нужно решить, какой сервис опросов вы будете использовать для работы. Это важный момент, т.к. сервисов много, и при выборе лучше бы не ошибиться, ведь данные всех опросов аккумулируются в вашем ЛК, а переезд с одного сервиса на другой, помимо новых согласований и договоров, ведёт к невозможности хранения данных в одном месте и, в итоге, к беспорядку и неудобствам.
Основная претензия при работе с serverless — время холодного старта, которым нельзя управлять «из коробки». Если функция стартует впервые за последние 5–25 минут, скорее всего запуск будет долгим — сотни миллисекунд. Причём статически типизированные языки имеют в разы большее время холодного запуска, которое может достигать нескольких секунд. Разработчики решают это на этапе загрузки своего кода, и им в помощь есть целые библиотеки. Например, они позволяют вызвать функцию заранее. Эти способы действительно сокращают время, но не устраняют проблему полностью и могут работать нестабильно. Параллельно этот вопрос пытаются решить и сами облачные провайдеры. Сегодня поговорим о том, как с холодным стартом справляются и те и другие.
... а также 8 инструментов безопасности для Kubernetes.
Подборка новых шпаргалок, вебинаров, свежих статей и полезных книг в самом полезном дайджесте на просторах #Хабр! Оставайтесь с нами – станьте частью DevNation!
Вопрос об облачных вычислениях и локальных решениях больше не стоит так остро, как раньше. Это может показаться смелым заявлением для специалистов, которые привыкли думать об облаке и о внутренней среде как о двух разных вселенных. Но я думаю, что пора изменить эту точку зрения.
Если вам приходится время от времени работать в терминале, и хочется сделать его удобнее, не затрачивая много сил, то небольшое руководство от Рейгана Макфарланда будет как нельзя кстати.
Есть масса более гибких и настраиваемых решений, но этот вариант для тех, кому надо сделать всё быстро и просто.
У Яндекса много самописных сервисов для внутренних задач: Яндекс.Формы, Яндекс.Диск, трекер, календарь. Со временем их решили использовать не только внутри компании, но и за ее пределами. Так появилась платформа Яндекс.Коннект.
Большинство сервисов Коннекта построено на Python V3. В качестве web-фреймворка используется Django, реже Flask и Tornado, а новые чаще пишутся на FastAPI. Сервисы, как и базы PostgreSQL, MySQL и MongoDB, живут в облаке. В качестве очереди сообщений почти везде используется Celery с MongoDB в качестве брокера. Он и стал проблемой.
На Russian Python Week 2020 Владимир Колясинский, разработчик бэкенда сервисов платформы Яндекс.Коннект, рассказал, почему они пользовались связкой Celery MongoDB и почему пришлось отказаться от этого брокера. Он сравнил претендентов: Redis, RabbitMQ и YMQ, с их плюсами и минусами. Подробно разобрал процесс переезда на нового брокера, анализ его состояния и возможные проблемы. И у него получилась пошаговая инструкция, которая пригодится при подборе и настройке брокера. А для любителей разбираться самостоятельно под катом есть расшифровка доклада с конференции.
Ранее мы уже обсудили вопросы законодательного регулирования ИБ и определили границы зон ответственности облачных провайдеров и клиентов.
В этой статье разберемся, как формулировать запрос на облачные услуги и как с помощью ТЗ облегчить жизнь облачному провайдеру и избежать нежелательного увеличения стоимости предложения.
К 2026 г. рыночный оборот в сфере управления выездным обслуживанием может достичь суммы в 10,81 млрд долларов. Несмотря на такие ожидания, более 3/4 компаний, занимающихся выездным сервисом, заявляют о том, что они постоянно «борются за увеличение доходов».
В одной из предыдущих статей я писал, что для увеличения доходов сервисной компании нужно перестать конкурировать ценой. Чтобы это сделать, бизнесу нужно уметь перестраивать модель обслуживания и научиться точно управлять себестоимостью услуг. Иметь возможность измерять показатели полезной загрузки персонала, отслеживать время между поломками оборудования, учитывать объемы переработок и контролировать множество других критичных параметров работы. Сегодня невозможно собирать все эти данные вручную.
Какой подход выбрать при построении сети передачи данных: на базе оборудования одного производителя или нескольких?
Есть устоявшееся мнение, что вариант с одним вендором позволяет уйти от проблем несовместимости, снизить расходы на эксплуатацию, упростить процесс модернизации и логистики.
Принцип «одна сеть — один вендор» продвигается ведущими производителями в качестве единственного варианта для упрощения эксплуатации, повышения надёжности и снижения общей стоимости владения сетевой инфраструктурой (TCO). Такая вот забота о потребителе. Но так ли всё выглядит на самом деле? Не кроется ли за этим стремление «огородить свою поляну», вытеснив конкурентов?
В то же время одни системные архитекторы заявляют, что использование продукции одного вендора позволяет добиться наиболее эффективного результата, а другие не против использовать оборудование различных производителей в одном проекте с целью повышения отдачи от инвестиций, в первую очередь по линии цена/качества.
