Pull to refresh

Comments 8

А че Amazon'овские сервера уже серверами не считаются?
Можно расшифровать «без серверов»?
Наверное, имеется в виду отсутствие необходимости поднимать и конфигурировать свой собственный web-сервер для запуска ядра приложения типа Puma/Passenger, Tomcat/JBoss и иже с ними (и ещё NGinx/HAProxy поверху). Вся эта инфраструктура уже предоставляется AWS (включая и физические сервера — куда же без них), а задача разработчика сводится к тому, чтобы оформлять решения поставленных задач в виде кода, скармливая его Amazon.
Таким образом, из классического понимания разработки клиент-серверного приложения «сервер» как будто исчезает (остаётся только приложение), хотя физически он никуда не денется, конечно.
Мдаа… думал будет что-то про Peer-to-Peer, хранение данных на мобильниках и интересная отдача контента через них, или еще что-нибудь гениальное, что лежит под ногами. Оказывается всё просто — «амазон придумал API, давайте его использовать»!
Да, поправьте заголовок. Я тоже облизнулась, подумав про peer to peer, а оказалось несколько банальнее.
Без своих серверов. Так будет корректнее.
Ваш заголовок вводит в заблуждение, это не «Микросервисы без серверов», это «Микросервисы в облаках».

Я могу написать техническое задание, «скормить» его программисту, затем передать результат системному администратору и получить «Микросервисы без кода».

Вы в магазине покупаете «Хлеб без пекаря» и «Рыбу без рыбака», но инновацией это назвать уже нельзя.

Оплачивая облачные услуги, вы оплачиваете работу инфраструктуры и персонала, это совсем не значит, что их нет.
А как вы предлагаете решить вопрос с роутингом, к примеру у меня одностраничное приложение, и в случае получения запроса по пути /api/ нужно отдавать API Gateway, а во всех остальных случаях отправлять запрос в index.html, который лежит в бакете. Какой инструмент AWS для этого подходит лучше всего, не держать же для этого инстанс EC2 с поднятым nginx.
Sign up to leave a comment.