The topic of “Day 0/Day 1/Day 2” in the context of the software lifecycle is very prominent in the professional IT media today. Presentations and conference talks are often focused on making software development processes effective and easy to manage.To do so, it is necessary to clearly define the notions that are used. The basic terms “Day 0/Day 1/Day 2” are often understood intuitively, which can introduce some ambiguity when talking about the software life cycle. For that reason, I have decided to define them more accurately to show the entire process of software development and how they are used in real projects. This short blog post provides a definition of “Days” understood as stages of the software lifecycle. It also describes how cloud has changed the traditional way of thinking about software development and maintenance processes. After all, we’re in the “cloud age”, as the RightScale 2019 State of the Cloud Report confirms. The report explains that 94% of survey respondents are using cloud (private or public). So, without further ado, let’s explore just how ‘days’ and cloud come together.
What “days” are all about
In IT, the terms Day 0/Day 1/Day 2 refer to different phases of the software life cycle. In military parlance, Day 0 is the very first day of training, when recruits enter their formative stage. In software development, it represents the design phase, during which project requirements are specified and the architecture of the solution is decided.
Day 1 involves developing and deploying software that was designed in the Day 0 phase. In this phase we create not only the application itself, but also its infrastructure, network, external services and implement the initial configuration of it all.
Day 2 is the time when the product is shipped or made available to the customer. Here, most of the effort is focused on maintaining, monitoring and optimizing the system. Analyzing the behavior of the system and reacting correctly are of crucial importance, as the resulting feedback loop is applied until the end of the application’s life.
In the pre-cloud days, these phases were handled separately, with no overlap between them. Today, that’s no longer the case. Let’s have a look at how all of this applies to the lifecycle of modern applications.
Day 0 – boring, but essential
Day 0 is often overlooked because it can be boring, but that doesn’t diminish its importance. A successful software product is the result of a thorough planning and design process. It is necessary to carefully plan the architecture of a system or app and the resources needed (CPUs, storage space, RAM) to get it up and running. Secondly, you should define measurable milestones leading to the realization of a project goal. Each milestone should have a precise date. This helps measure the progress of the project and determine if you are running late with the schedule. All project time estimates should be based on the probability and not be merely best-case scenarios. When planning, it is good practice to add buffers, as unexpected events can throw sand in the gears of even the most carefully elaborated plan. The testing phase plays an important role too, and should be included in the initial project planning. These are the basic requirements, and they are as important in the “cloud era” as they have ever been.
Still, the cloud has changed two things in the Day 0 planning of computing resources. Thanks to the cloud getting different or new resources (CPUs, storage space, RAM) at any point of the project, it is easier than it was with on-prem infrastructure. Therefore some mistakes made at the planning stage can be forgiven. On the other hand, commitment to a specific cloud vendor already in the planning phase may later result in vendor locking. This can cost you money and take time to change, so a cloud vendor should be chosen wisely.
Secondly, as we are currently observing in the shift to the cloud, the effort related to the operations remains the same, but it is no longer focused on infrastructure. Now it is software that is driving automation and value.
Day 1 – where things get creative
For developers and project owners, Day 1 is definitely the most interesting phase. The initial design is brought to life and an infrastructure is created based on the project’s specifications. In order to become truly cloud-native, best practices must be observed. Guidelines such as Twelve-Factor Apps methodology can be followed. What’s more, using cloud means that you should stick to the important DevOps practice: Continuous Integration/Continuous Delivery (if you want to read more about CI/CD – check out our blog post).
The cloud has brought us important change from the old-school approach to software development: an application starts to live as soon as the first lines of code are pieced together to make your proof-of-concept. You can start with Continuous Integration practices to test your application’s sanity, but you will quickly venture towards Continuous Delivery. When developing the app, we start introducing some operational elements, especially when multiple environments are used. Taking care with these operational elements will make the maintenance team’s life easier during the maintenance phase (Day 2).
There are several classes of tools that can be used during “Day 1”. They can be grouped by the problems they solve. “Infrastructure-as-a-code” should be mentioned at the top of the list. IaaC manages the operations environment just as the applications or code are. This approach allows DevOps best practices, including version control, virtualized tests, and continuous monitoring to be applied to the code driving the infrastructure. Here too there are plenty of tools at our disposal, such as Terraform, Ansible or Puppet, to name a few. The second class of tools is related to the container orchestration systems that automate the deploying and managing of containers. Kubernetes and its implementations, such as Google Kubernetes Engine and Amazon’s Elastic Kubernetes Service, are essential. Finally, there are CI/CD systems like Jenkins, Zuul, and CircleCI, which help engineers automate the building, testing, and delivering or deploying of software.
Day 2 – daily operations routine
Once the software is ready, it goes live and customers start using it. Day 2 begins here, and elements including software maintenance and customer support are introduced. The software itself is going to evolve in order to adapt to the changing needs and customer requirements. During Day 2, the main focus is on establishing a feedback loop. We monitor how the app is working, gather feedback from users and send it to the development team, which will implement it in the product and release a new version. The military terminology Observe-Orient-Decide-Act aptly captures what occurs in this phase.
- Observe – obtain information from monitoring systems (resources usage and metrics, application performance monitoring)
- Orient – perform root cause analysis of the problem.
- Decide – find a way to solve the issues arising.
- Act – implement the solutions.
As during the combat, this cycle is continuously repeated.
Monitoring procedures are based on the requirements defined in the Service Level Agreement (SLA). The SLA is based on Service Level Objectives (SLO), which represent the state of our Service Level Indicators (SLI). Automation and monitoring are the key to tackling the Day 2 responsibilities.
Several classes of tools help get the Day 2 job done. Application performance monitoring (APM) class groups software that helps IT admins monitor app performance and thus provide a high-quality user experience. Here we can name Datadog, Dynatrace, SignalFX or Nutanix Xi Epoch. There are also automation and orchestration tools, such as Ansible or Kubernetes, which help manage application environments. As you might have noticed, the application of these tools overlaps Day 1 efforts. Finally, ticketing systems such as Servicedesk or Zendesk handle customer service, enabling users to report problems and issues related to the apps they are running.
Day 0/Day 1/Day 2 – stages of software lifecycle
Cloud as a game changer
In the pre-cloud era, the separation between these phases was distinctly visible, but today, with cloud our everyday reality, things are constantly changing. Using the cloud and modern software development practices makes it much easier to handle the ever-changing requirements in the software life cycle. Continuous Integration/Continuous Development methodology enables us to dynamically respond to customer feedback and improve apps in real time without the need to wait for a major release to introduce improvements.
DevOps practices in cloud-based and cloud-native software help achieve shift left, which means that the steps that traditionally have been left until the very end can now be performed much sooner. Among other things, this has led Day 1 and Day 2 to now overlap one another. Moreover, the biggest pain point of traditional software development was the transition from Day 1 to Day 2 – the handover from developers to operators. Now, DevOps shows how to handle this problem: initiate the processes early and keep them running until the end of the application’s life. Last but not least, toolchain is becoming complete, making it possible both to perform Day 1 tasks and to adapt to Day 2 changes. The tools used can be modeled to our needs and everyone involved in the process can use the same set of tools.