The development process of making apps in the cloud versus on premise is pretty much the same, although they have different dependencies. And you know what? It’s actually pretty different, because in a cloud environment you have a certain set of assumptions made that differ quite a bit from the assumptions made during on premise development.
With Cloud environments like Amazon Web Services you have a lot of different, small tools at your disposal. Meaning, if you just need a microservice up, they have something called Amazon Lambda that can run your code upon request, and tie the service into an Amazon API Gateway and you officially have a very solid API web service! That is part of the ease of a cloud environment.
You can also simulate Cloud environments on your own computer. This is a must for any type of professional development. As you become more experienced writing microservices for the cloud, you will start to see how much time can be eaten up waiting for either your deployment server, or waiting for yourself to click through the menus to upload a new version. If you have the need to test new versions ASAP, download something like Amazons AWS Serverless Application Model. I cover this in another blog post here.
With on-premise development you have your traditional server, it sits headless in a locked back room somewhere, maintained by a couple of guys telecom and system administration. They update it you hope. And they keep it online when it rarely happens to get knocked offline. That usually requires a report made by a person or made by a machine to tell people that the server is offline.
Automating the on-premise infrastructure is a bit harder, because you have a lot more opportunities for entropy and customizations, whereas a cloud provider will follow an API development model, which can be easier for some tasks. Right now if you are automating the creation of on-premise devices you maybe have something like a Kubernetes cluster set up with nodes that can be responded to on demand. If you have physical servers maybe you have a program such as puppet installed on one master server and all servant nodes responding to changes instantiated from the master. Or perhaps you automate with Chef. And you are writing scripts in Ruby to manage computers software dependencies with that. With both cloud and on-premise app development you have lots of options for automation. At some times one may be better than the other. It is up to you, the user, the developer, to create the value with those tools. In my opinion, with my skills, I would prefer to do on-premise automated infrastructure deployment. But I am adding in some other considerations, regarding security and how much time I have to spend negotiating with the issues that arise from automating on-premise devices. Plus I think on-premise saves me money.