«Неважно, кто вы, большинство самых умных людей работают на кого-то другого». Так сказал соучредитель Sun Microsystems Билл Джой, предлагая мудрые советы компаниям, которые хотят получить наилучшее программное обеспечение. Если вы занимаетесь продажей или использованием программного обеспечения (которое описывает каждую организацию на планете), вам необходимо спроектировать свои системы, чтобы обеспечить постоянный, развивающийся выбор. Как это работает на практике?

“ Наем ” умных разработчиков с открытым исходным кодом

Возможно, один очевидный ответ – открытый исходный код. Большинство организаций уже поняли это, по крайней мере частично. Как предполагает Gartner, более 95% ИТ-организаций используют открытый исходный код для критически важных ИТ-рабочих нагрузок. ИТ-руководители могут не всегда знать об этом, но их разработчики знают. Мы и близко не подошли к завершению: Gartner прогнозирует, что более 70% предприятий увеличат свои расходы на открытый исходный код до 2025 года – и это платное внедрение. Вероятно также, что 100% разработчиков увеличат использование открытого исходного кода до 2025 года.

Почему? Потому что «самые умные люди работают на кого-то другого». Или, в данном случае, они строят для кого-то другого, будь то проект Kubernetes или GDAL или [insert name of your favorite open source project]. Вы не можете позволить себе нанять всех этих «умнейших» участников открытого кода, да и не нужно. Это особенность, а не ошибка открытого исходного кода, в которую разные люди и разные организации по-разному вносят свой вклад и извлекают выгоду из открытого исходного кода. Единственное, что остается неизменным – мы все чистые бенефициары. Или, как Дуг Каттинг, основатель Hadoop, Lucene и других компаний, сказал, «Ожидать, что вклад в открытый исходный код будет пропорционален выгоде от него – безумие».

Каждая организация должна углубиться в открытый исходный код как на способ увеличения инноваций и снижения затрат, позволяя тем самым «самым умным людям» [who] работать на кого-то еще », чтобы использовать его в собственной организации. Что еще можно сделать?

Архитектура на выбор

Получите ли вы возможность использовать новейшее и лучшее программное обеспечение с открытым исходным кодом или какой-либо другой лучший в своем классе инструмент, во многом зависит от того, как вы проектируете свои системы. В виде ThoughtWorks недавно написал в своем «Технологическом радаре»: «Мы наблюдаем рост … интеграции инструментов, ориентированных на разработчиков, с объединением инструментов для репозиториев артефактов, управления исходным кодом, конвейеров CI / CD, вики-сайтов и прочего. Эти объединенные наборы инструментов обещают большее удобство для разработчиков, а также меньший отток. Но набор инструментов редко представляет собой лучший из возможных вариантов ».

Возможно, это сказано слишком сильно. «Наилучший возможный выбор», конечно, субъективен. Например, когда я работал в MongoDB, людям нравилось называть его игрушкой по сравнению с «настоящими» базами данных, такими как Oracle. Они признали, что да, MongoDB добилась превосходной эргономики для разработчиков таким образом, что его было удобно создавать с использованием базы данных документов, но они утверждали, что он не может обрабатывать серьезные масштабные или критически важные приложения. Сегодня никто не делает этого ошибочного предположения, и MongoDB используется для широкого спектра критически важных приложений, работающих в глобальном масштабе. Хотя удобство для разработчиков не было единственным ценным предложением MongoDB, оно является центральным, почему так много разработчиков любят его использовать.

Тем не менее, в том, что предлагает Майк Мейсон из ThoughtWorks, есть веская причина, согласно которой организации могут удобство за счет превосходной функциональности. Платформа «делает выбор по умолчанию простым для понимания и приобретения, предоставляя команде все инструменты, необходимые для запуска программного обеспечения в производство. Преимущества аналогичны тем, которые вы могли получить от выбора одного технологического стека в 2000-х годах ».

“Достаточно хорошо” часто не так

По словам Мэйсона, компромисс заключается в том, что «эти« достаточно хорошие »варианты могут отставать от ведущей в отрасли независимой альтернативы. Это ставит под угрозу всеобщие инновации. … Команды часто принимают выбор по умолчанию, поскольку он (в основном) работает достаточно хорошо, и бороться с помощью процессов закупок или утверждения другого варианта просто не стоит. Как сказал в нашем обсуждении один из авторов Radar, «когда все, что у вас есть, это GitHub, весь мир выглядит как пул-реквест». ”

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

Лучшим подходом является построение на тесно интегрированной платформе, которая также предоставляет API-интерфейсы и другие способы подключения альтернативных сервисов, которые идеально подходят для ваших нужд (что лучше всего подходит для вас). Например, Microsoft Azure предлагает различные способы доставки потоковой передачи событий в реальном времени, но для многих золотым стандартом является Апач Кафка. Так что Azure тоже объединяет с Confluent Cloud, Confluent является основным спонсором разработки Kafka.

Таким образом, имеет смысл подключиться к тем умным людям, которые не работают на вас, могут даже не работать на выбранного вами поставщика платформы, но работают на одного из их партнеров (или для проекта с открытым исходным кодом, который интегрируется в эту платформу). С открытым исходным кодом и открытыми API-интерфейсами предприятия избалованы выбором сегодня – до тех пор, пока они выбирают архитектуру. Нет, я не думаю, что это означает мультиоблако, как некоторые любят притворяться, как я написал, но это означает строительство таким образом, чтобы вы всегда получали пользу от умных людей где-то еще.

Авторские права © 2021 IDG Communications, Inc.




#Обращение #самым #умным #разработчикам #программного #обеспечения

Source link