Software deployment is an often neglected aspect of the overall software development process. We don't think much about it or plan enough regarding the same when we start building a shiny new app or service. With the advent of the internet, software is all around us these days in various forms. Users of the apps and services rely on the continuous availability of their favorite social, productivity and utility platforms and applications. Software bugs and newer features, requirements and enhancements is another aspect of software that the internet and software companies need to address thus requiring to continuously upgrade the user experience without hindrance and service discontinuity. Software deployment strategies play a key role in this regard and I wish to explore the same topic in this three part series of blogs.
Types of Software
Types of Hosted Services / Software
Stateful and Stateless services are the two varieties of service I have owned and operated. Both of them have different characteristics and require unique strategies for deployment.
Stateless: Service statelessness characteristic is detailed here. In short, the software in the stateless service does not need to store data on the disk and can service each of the requests individually.
APIs are the biggest examples of stateless services. These services are dependent on other components that store the state viz. cache, databases, etc. A thing to note here is that the API would be called stateless if and only if it does not maintain or require any state regarding the user or the request context to operate. Else, it would be a stateful API.
ETL jobs reading data from a source and storing the result in another sink is another example of Stateless service. E.g Stream processing pipeline converting source data into a new aggregated or transformed data to be consumed by a different part of the software.
Single function IoT processors or AWS Lambda functions doing a single unit task is another example of stateless service.
Stateful: Stateful service is something that stores the state and there is a need for continuity of the same state post an upgrade of the software. This is a more involved process and requires careful well tuned process to prevent data loss.
Databases like MySQL or Cassandra is a stateful service that stores the data used by the software.
Distributed Caches or In-Memory stores like Memcached or Redis is another example of stateful service.
Distributed File Systems like Hadoop, Configuration and Consensus systems like Zookeeper or etcd, Messaging systems like Kafka.
Best Practices of Software Deployment across all types of Services
Software upgrade should follow the process of immutable deployments. Mutability on the same node can cause unforeseen errors and issues leading to downtime and/or bad experience for the users of the software due to unclean starting auxiliary state expected by the software like the log directory or 3p libraries installed, etc. Incorrect app/service configuration is another peril of mutability.
Software upgrade should allow for controlled rollout to limit the blast/impact radius of a bug in the new version of the software. This is usually termed canary deployment.
There should be functionality to conduct A/B testing with the different versions of the software allowing for turning features on/off via dynamic configurations. This also may additionally involve creating sticky routing and needs controls in the load balancer fronting the service to enable the same.
In the next two parts we will cover the deployment strategies of Rolling Deployment and Canary Deployment useful for Stateless services and Blue-Green Deployment with additional possible strategies for Stateful services.