When I started my career, analyzing and finalizing hardware needs for deployments was a major task and had to be taken up months before actual production deployments. Hardware was costly. Though we had providers which would provide machine virtually, you would need to decide the requirements beforehand as once you procured a machine, you had to pay at least a month’s rent. And if you decide to upgrade or downgrade the server machine, it was a painful manual task.
Just imagine what a nightmare it would have been to scale up during a surge in requests. You had to foresee it, plan for it, arrange hardware for it (monthly rents).
With the cloud, things have changed for the better. You have a pay as you go model, so you actually pay for the usage of hardware only. With autoscaling features inbuilt into the cloud infrastructure, it is easy to increase or decrease compute power without any human intervention. Setting up databases and scaling them is another area which the cloud takes care for us. Most of the cloud service providers support both relational and NoSQL databases in an easy to use manner.
Security, access management, monitoring, encryption, and storage are some of the other services which are provided by cloud services providers of the shelf. Another popular set of services off-late is serverless compute. This means one can write code directly which can be run as functions on the cloud, without worrying about the deployment details completely. Cloud provider is responsible for scaling and maintaining such functions. This is in sync with the microservice approach where each function can behave as an independent microservice.
With one’s mind taken away from hardware details, it is easier for software engineers to focus on building quality products. But it is important that we design our products in a manner which are capable of taking advantage of cloud services. For example, it will be easier for a microservices-based application to autoscale in a cloud than a monolith application. A stateless service is easier to be deployed and scaled on cloud than stateful service. One still needs to take care of the fact which services are exposed on the internet and which should be exposed only to internal service. With the ease of deployment, it might be easier to mess up a running service, so proper automated and manual checks are required to be implemented.
Cloud, though makes things easier, but one needs to be cautious of using its capabilities and designing the system in a manner to make maximum use of services being provided