Using a UI means that whenever you want to deploy your service, you’ll need to remember how to set up everything. This can become time consuming especially if you ever wanted to redeploy your services. By using Serverless framework, your infrastructure becomes part of your codebase.
Agree with /u/ikbelkirasan, you do not want to be working in the UI it’ll slow you down. If AWS is and will be your only platform you can achieve much of the same functionality with AWS SAM. That said, where the Serverless Framework really shines is in its portability for other CSPs. Being able to develop against this framework and deploy to a variety of providers can be a beneficial layer of abstraction which provides a measure of flexibility especially if you want to protect against vendor lock-in or decompose your serverless application in a way that allows you to take advantage of services provided by a number of providers that may have unique features that meet your business needs.
I think we need to be very careful with claims like this. The Serverless Framework is a deployment framework that can be used with multiple cloud providers. This is very different from a framework, like Rails or Laravel, which abstracts the underlying platform. Vendor lock-in still exists. You can’t build an application for AWS then deploy it to other providers without change.
I agree to an extent, but it also depends on the CSP specific features/services you make use of. Which is why I intimated that decomposing your application to take advantage of a specific service or services from one or more providers could be an advantage depending on your use case. Granted if you write an application that uses DynamoDB you’re not going to be porting that directly over to Azure. I don’t think I implied you could, but the word of caution is valid nonetheless.