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
Through the years in my work as a Software Engineer at various companies in different domains, I have built, owned and operated apps, services and storage platforms. Traditionally, software was developed and delivered on floppy disks, cd roms, dvd roms. More recently, downloadable apps on your devices (desktops, laptops, mobile phones) via the internet is the mechanism to deliver software that executes on client devices. But most of the modern apps running on client devices (mobile or web browsers) also have hosted server counterparts where services running in remote data centers or cloud are doing the heavy lifting of powering these apps with complex features. Software living on the client devices are delivered via platform application stores for mobile apps (Google Play Store, iOS App Store and Steam App Store are some examples) and via CDNs in case of web apps (JavaScript code to be executed on the client side browsers). In these articles we would focus on the deployment strategies for hosted services in the data centers or cloud.
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.
Whats next?
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.
This is the first of the three part blog posts on this topic. Please find part 2 here and part 3 here.
Comments