Serverless is an entirely different way of building and operating web systems. In general it makes your life easier but there are also some major limitations which come with it.

• Vendor lock-in - Currently every serverless implementation is highly dependent on the vendor you are using. That makes it extremely difficult to switch from one vendor to the other.
• Limited features and tools - When you manage your own server you have full control over it and can configure things the way you want but with serverless the vendor decides how to give you access and control of different features, most of the times you are provided with tools specific to the vendor and you have to build your processes around them.
• Architectural complexity - Traditional applications are not built to go serverless. You have to refactor your application to ensure it can be run Serverless. Serverless applications follow an entirely different design pattern and that increases their complexity. This increases the time and cost for onboarding your team to Serverless.
• Cold start - your code eventually has to get executed on some server. By design when your endpoint gets called for the first time or is scaled up it takes some extra time to initialize which results in high latency and bad performance. This is a very common problem with serverless applications.
• Local testing - In serverless your vendor controls the libraries and configuration of the environment where your code runs. They do give you an option to use packages that you want however there are a lot of limitations. It’s difficult to replicate the same environment locally so as to ensure that everything will work fine in production. Due to this, in the early stages of adoption it takes a lot of time to test things.
• Loss of control - In non-serverless the entire software stack is under your control. You can choose to download and alter components from the operating system or even the bootloader if needed. Going serverless involves giving up full control of the stack which then resides with the vendor.
• Limitations with monitoring and logging - Serverless code executes in a stateless environment where nothing persists after the code execution. Due to this you have to depend entirely on the vendor for getting access to logs. Each vendor has their own implementation for this and that can lead to vendor lock-in and additional dev time spent.

With appfleet you can take the advantage of not managing servers and at the same time also overcome a lot of the above limitations.

For instance with appfleet you can create your docker image and instantly deploy it in multiple regions without worrying about servers and management.
With a docker image you get full control over the software stack which also makes local testing seamless.
And since you are using containers you can switch to any other platform when you wish to.
With appfleet you also get additional features like smart load-balancing, failover, managed SSL, logging, monitoring and also console access for debugging.