Если вы хотите создать веб-сервис сегодня, у вас есть тонны технологий на выбор.
В свое время разнообразие языков программирования, фреймворков, баз данных и интерфейсных решений не было столь впечатляющим. Большинство веб-сайтов и сервисов работали в тандеме PHP / MySQL. Значительное количество сайтов все еще делают. Вместе с миром современных фреймворков (Ruby’s ROR, Python’s Django и Pylons и т. Д.) И новыми решениями, такими как NodeJS, все еще существует интернет старых технологий.
И если ваши клиенты все еще используют их, вы должны принять это во внимание.
Почему бы просто не модернизироваться?
Когда вы создаете что-то с нуля, легко выбрать правильную структуру — ну, прямо во время создания, то есть. Но когда вы начали свой бизнес в 2002 году, используя решения, которые у вас были под рукой, это не так легко изменить. Много времени, денег и усилий было вложено, сложная структура была построена, и теперь вы знаете, что если вы хотите модернизировать только один элемент, вам придется изменить все это. Или это заняло бы целую вечность.
Это может показаться невероятным, поскольку переписывание и модернизация не являются чем-то необычным. Давайте посмотрим на это с другой точки зрения и сравним технологию с дизайном. Нам всем нужны красивые продукты и отличный пользовательский опыт, и все же мы по-прежнему используем ужасные сайты каждый день!
Посмотрим правде в глаза, даже некоторые гиганты, такие как Amazon, не имеют веб-сайтов, которые следят за текущими тенденциями. Да, Amazon уделяет большое внимание дизайну своих сайтов (им нужно увеличить конверсию и т. Д.), Но это другой вопрос. Есть много причин, по которым Amazon вносит только небольшие изменения — одна из них заключается в том, что люди привыкли к своим сайтам и знают, как их покупать.
Дьявол и Глубокое Синее Море
Если ваши клиенты используют устаревшие решения и вам необходимо интегрироваться с ними, вы знаете, что рано или поздно вы не сможете поддерживать высокий уровень обслуживания. Когда вы работаете на доисторических технологиях, а ваши клиенты — стартапы, которые меняют мир, вы знаете, что в скором времени можете потерять бизнес.
Это непростая ситуация: вы либо поддерживаете не модернизированные решения и рискуете не получить новых клиентов, либо вы изменяете свои способы и заставляете старых клиентов обновляться.
ОТДЫХАТЬ или НЕ ОТДЫХАТЬ
Одна из компаний, которая имела такую дилемму, была PayLane. Мы могли бы различить относительно новые и небольшие компании / службы, которые обычно используют (и требуют!) Современные технологии, и старые компании: значительное количество крупных корпораций с большими системами, которые помнят старые времена. Конечно, есть и одинокие гонщики, которые просто не следуют тенденциям, но это довольно незначительное число.
Такое разнообразие приводит к совершенно другим подходам и общению. Например, API RESTful в настоящее время считаются стандартным подходом, однако многие клиенты PayLane все еще хотели использовать SOAP. Да, это были те «пожилые люди», которые годами пользовались PHP и SOAP, до того как REST был популяризирован.
Таким образом, компания осталась с SOAP API, потому что многие наши клиенты чувствовали себя лучше. Это был не простой выбор, потому что многие другие, естественно, предпочли REST, и компания это поняла. PayLane на самом деле некоторое время работал с RESTful API и предлагал его тем, кто предпочитал его (например, разработчикам мобильных приложений — PayLane считал, что просто неуместно этого не делать).
У PayLane были клиенты, которые хотели внедрить свои платежные системы с использованием PHP, Python или Ruby, у нас были некоторые, кто предпочитал Java или C #, но у нас были и более удивительные случаи, например Lisp! Было много других отличий, даже небольших. Например, некоторые клиенты (обычно крупные компании) хотели получить техническую документацию в виде документа или PDF-файла, они не считали веб-сайты надлежащей документацией. Это было полной противоположностью того, что ожидали стартапы.
Некоторое время PayLane просто считал числа, и эти цифры убеждали нас остаться немного дольше с SOAP API. Революции обычно обходятся компаниям рядом клиентов, но они разумны, только если выгоды преодолевают такую потерю. PayLane решила пойти маленькими шагами.
Один шаг за раз
В течение некоторого времени PayLane поддерживал две версии API, но в конце концов мы достигли точки, когда мы могли изменить ситуацию. Компании удалось убедить множество наших клиентов в REST и получить еще больше новых, поэтому больше не было необходимости удваивать работу с API.
API RESTful стал официальным, PayLane настроил нашу Зону разработчиков (включая документацию) и выпустил бесплатный технический документ по REST, чтобы упростить работу для клиентов или всех, кто интересуется этой темой.
Старый SOAP API все еще работает, но PayLane считает его устаревшим и рекомендует всем использовать RESTful.
Тенденции важны и обычно не возникают из ничего. Важно идти в ногу с новейшими технологиями, чтобы предлагать клиентам лучший сервис и, следовательно, оставаться конкурентоспособными.
Не менее важно, чтобы ваши клиенты чувствовали себя комфортно, работая с ними. Если вы продолжаете изменять основные правила, вас могут считать нестабильным или ненадежным, даже если вы пытаетесь улучшить качество обслуживания своих клиентов.
PayLane упорно трудились , чтобы сделать переход к более совершенной технологии сглаживания для своих клиентов, находя сбалансированный подход, удовлетворять потребности как тех , кто готов принять новую технологию и тех , кто хочет стабильности , что они уже знали.
Мы обнаружили, что поэтапный, постепенный подход, подкрепленный четкой информацией и поддерживающий выбор потребителя, стоил усилий по поддержанию дублированных систем какое-то время. Другие могут найти подход, основанный на революционных изменениях, более эффективным, чем подход, основанный на эволюции.
Какой у тебя был опыт?