Preparation for deploying API services to the cloud (continued...)

This is a continuation of the previous post. We mentioned that APIs are desirable features to deploy because they enable automation, programmability, and connectivity from remote devices. Deploying the API to the cloud makes it even more popular now that the clients can reach them from anywhere that has IP connectivity. The public clouds offer immense capabilities to write API services and deploy them, but the preparation is largely left to the source. Some of the mentions we made include:

1) Choose the right technology: There is a variety of stacks depending on the language and platform to choose from. There are side-by-side comparisons available to choose from, and the investment is usually a one-time cost even if the technical debt accrues over time. 

2) Anticipate the load:  Some back-of-the-envelope calculations in terms of the number of servers depending on the total load and the load per server will help figure out the capacity required but Service-level agreement and performance indicators will help articulate those numbers better. 

3) Determine the storage:  Disk i/O is one of the most significant cost contributors especially when it occurs over the network.  ACID guarantees are required for certain storage and in others, the size of the data matters more.  The proper choice of storage even if it is a public cloud global database matters.

4) Determine the topology:  The firewall, load-balancers, proxies, and server distributions are only part of the topology. The data and control paths will vary based on topology and the right choices can make them more efficient. 

5) Tooling:  Investing in tooling will reduce troubleshooting costs.

6) Create pipelines and dashboards for operations: Continuous Integration, Continuous Deployment, and Continuous Monitoring are core aspects of API service deployments. Investment in tools such as Splunk can automate and enable proper alerts and notifications to tend to the services. 

7) A pipeline for staged progression of code to the production environment allows multiple opportunities to test and rollback the changes. The tests can even be mixes from those of other flows so that the code can be vetted against other environmental factors. 

8) The deployment must be automated so that it can be repeated over and over again in different stages and environments. With the code propagation streamlined to not require manual intervention, it is possible to have a continuous release.

9) Each stage or environment in which the code is tested must have a dashboard so that the operations of the code in that environment can be analyzed.