Распределенный кеш от Netflix на базе memcached https://github.com/Netflix/evcache/wiki

Рисование на чистом CSS. Топ 5 CSS свойств, на которые я полагаюсь при создании CSS искусства

http://diana-adrianne.com/how/

Для тех кто все еще хочет нормальную профессию)

​​📖 Руководство по Figma

Первый бесплатный самоучитель для дизайнеров, который поможет освоить этот инструмент и заложит солидную техническую базу для дальнейшего развития в дизайне мобильных приложений, сайтов и любых других продуктов.

Фигма — единственный графический редактор, который делает возможным совместную работу дизайнеров и разработчиков над интерфейсными макетами и спецификациями в реальном времени.

Скачать

@itlibrary

Вэб-комикс про сети от Julia Evans:

https://wizardzines.com/zines/networking/

#linux #networking

Брошура по архитектуре с использованием NoSql-баз от Aerospike: https://www.infoq.com/vendorcontent/show.action?vcr=5039

Вот только вопрос как из https://habr.com/ru/post/439104/ получилось раздуть столько бойлерплейта? Только вдумайтесь, что бы написать простое приложение на React+Redux надо написать: компонент, props к нему, коннектор, фабрику actions, сами actions, редьюсеры, саги\thunk'и, стор. И это если у вас не TypeScript, иначе еще надо определить кучу типов, интерфейсов и констант. И все это удовольствие нужно для того что бы создать один экран с простой формой. Фронтенд, что ты делаешь, аххахха, прекрати

DC/OS в версии 1.11 добавил поддержку Kubernetes.

Для тех кто не в курсе - DC/OS это уровень абстракции над Mesos, и в качестве контейнерной оркестрации там используется Marathon.
Разумеется, DC/OS проигрывает в битве с Kubernetes, и не важно почему: хайп, Google, you name it - причин там очень много.

Поняв, что конкурировать с кубером в поле контейнерной оркестрации нельзя, Mesosphere сделала следующее. Выпустила распрекрасный блог пост о том, что “Кубер нам не конкурент, мы вон, смотрите, даже внедрили его поддержку”. (https://mesosphere.com/blog/the-docker-vs-kubernetes-vs-apache-mesos-myth/)

Любой куберовод задастся вполне логичным вопросом: зачем мне поднимать кластер DC/OS и ставить на него Kubernetes, когда я могу сразу поставить Kubernetes? Вопрос вполне себе валидный.

В свою очередь DC/OS помимо оркестрации предлагает запуск различных сервисов. То есть непосредственно на фреймворке Mesos вы можете запустить кластер Kafka, балансировщики, ElasticSearch, Jenkins, Cassandra… Да в целом много всего. Самое смешное, что это все еще контейнеры запущенные на уровне Marathon’а, но пользователь видит их как отдельные сервисы.

Штука, на самом деле прикольная. Ну а что? Получается такой себе cloud provider на коленке. Хочешь какой-то сервис (будь он stateful или stateless) - выбери из каталога, да установи. Если его в каталоге нет, то запакуй его в “правильном” формате да и выкати. Удобно.

Вот только у Кубера есть операторы, которые (как я понял из документации) делают ровно тоже самое.
Посему вопрос остается прежним. Зачем нужен DC/OS?

Ну ваще зачем нужен Mesos-то понятно: в инфраструктуре нельзя обойтись только контейнерами. Всегда будут RDBMS, которые в контейнер ставить грешно, кластера всяких Хадупов-Кликхаусов, которые вроде можно и поставить в контейнер, но хз зачем, и вот тут, типа, Mesos и аналоги вылазят из своих болот. Но вот зачем нужна прослойка в виде Marathon'а — непонятно, ведь унифицировать ландшафт можно и просто загнав куб в марафон

Раз уж сегодня маленькая пятница, то вот прикольная статья про разные "законы" в IT: https://vk.com/@javarush-izvestnye-zakony-mira-razrabotki

От себя еще добавлю вот этот: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%90%D0%BC%D0%B4%D0%B0%D0%BB%D0%B0
и вот этот: https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9B%D0%B8%D1%82%D1%82%D0%BB%D0%B0

Интересный рамс за процессы в Amazon: http://highscalability.com/blog/2019/3/4/how-is-software-developed-at-amazon.html

Наиболее интересным мне показалось вот это:
- Developers on a team are responsible for architecture, the architecture doesn't come from architects. Once they have an architecture it's reviewed with an architect or a principal engineer. The role of a principal engineer is to review and teach, not do the architecture. Same with security. The role of a security engineer is not to create the threat model, that's a developer in the team, they review threat models. Same with testing. A team owns the entire process. A lot of time is spent teaching because you want developers to learn.

- The best way to plan is bottom up. Teams closest to the product are closest to the customer. They know what the customer wants. The people closest to the customer should tell Amazon what to do. Every year there are two docs OP1 and OP2 (Operating Plan). Every organization level writes a 6 page document about what they want to do next year. In the plan you say what you would do if you had flat resources and incremental resources. These 6 page business plans are presented at every level of the organization. Managers take the 6 page docs from all the teams they manage, make their own 6 page doc and present it to their management. This happens all the way up to Bezos. Resources then flow down to the teams.

Ansible and HashiCorp: Better Together

Terraform + Ansible = ❤️

https://www.hashicorp.com/resources/ansible-terraform-better-together

отличный доклад с RDD про туллинг современного мамкиного инфраструктурщика: https://youtu.be/HpsyaKbJx58
Больше всего зацепило четкое разделение тулзян по категориям(наконец-то можно кинуть что-то коллеге вместо полуторачасовой лекции "почему плохо деплоить Ansible'ом")

вот, кстати, остальные:

6 наиболее залайканных докладов с Riga Dev Days с видео.

6. Zero Downtimes with Faulty Solutions, Dimitris Kapanidis, 2017

5. The DevOps 2.0 Toolkit, Viktor Farcic, 2017

4. Gotchas using Terraform in a secure delivery pipeline, Anton Babenko, 2018

3. Fabric8 Camel Microservices for Docker and Kubernetes, Claus Ibsen, 2016

2. Continuous Deployment With Jenkins X and Kubernetes, Viktor Farcic, 2018

1. 360° monitoring of your microservices, Philipp “xeraa” Krenn, 2017

#slides

[Перевод] Назад к микросервисам вместе с Istio. Часть 1
https://habr.com/ru/post/438426/
Tags: Блог компании Флант, DevOps, Kubernetes, Микросервисы, Системное администрирование, Istio, service mesh, микросервисы
Author Wimbo on #habrahabr

В течении десятка часов пришло две большие новости:

1. AWS анонсировали выпуск в опенсорс «Open Distro for Elasticsearch» — дистрибуции Elasticsearch с набором компонентов, которых так не хватало в опенсорсном Elasticsearch:
* Security — поддержка разных аутентификаций, rbac на разных уровнях, шифрование трафика и аудит;
* Event Monitoring & Alerting — создание оповещений по данным в индексам;
* Deep Performance Analysis — API для получения метрик производительности кластера;
* SQL Support — поддержка создания запросов к данным с помощью SQL;

Статья от Jeff Barr http://amp.gs/4eWD
Более общая от Adrian Cockcroft http://amp.gs/4eW0
И сам сайт проекта http://amp.gs/4eWa

2. F5 покупает Nginx.
Статья на TechCrunch http://amp.gs/4eWJ
Анонс Nginx http://amp.gs/4eWX
И от F5 http://amp.gs/4eW3

#news #elasticsearch #nginx