Onward to week 3.

The past week or so school has been ramping up – so, we’re back on the grind.

I can’t tell if I have senioritis or if I’m just so used to being this busy now. I feel pretty relaxed about everything which is certainly better than the alternative.

In addition to the Capstone Project, I’m also taking Cloud Application Development. I’ve also been doing cloud deployments at work. At this point, I’m not sure how much overlap there will be between what I’m learning in school and what I’m picking up at work. I do, however, feel pretty good about the basics.

My previous experience with cloud deployments was with web applications that I developed for school and the bootcamp I attended previously. As much as I thought that might help with what I’ve been doing at work, it turned out to be entirely different. I used Heroku before and the heavy lifting there was making sure you were able to migrate your database properly in the cloud. Configuration was mostly handled in a Procfile and aside from that it felt like Heroku abstracted away the hard stuff.

Recently I pretty much volunteered to be the guinea pig for my team (and the rest of the tech side of my company by extension) for navigating new workflows for cloud deployment. I, somewhat naively, thought that there would be more carry over from my previous experiences. What I discovered instead was that the new workflows are being built around Azure Red Hat Openshift (ARO) for container management and orchestration with deployments being handled by Flux.

In this workflow, you have to have a Dockerfile to configure the building of your application image and containerization of that image. This file lives alongside your application in the application’s repo. When you commit and merge your code into main, a pipeline then tags and pushes the image of your application to an artifact repository. In a separate repo you have a Helm chart that configures the deployment of your application to the cloud. In the chart, you reference the artifact repository where the image can be found and the tag that corresponds to the version of the image you want to deploy. Once your Helm chart is properly configured, you push your code and merge to main and Flux deploys and spins up a pod with your application running. This may sound like a lot but when you get the workflow down it’s really not so bad.

In the process of getting my apps deployed, I learned a lot about what it means to deploy to ‘the cloud’. Before, I just envisioned the process as me just uploading my application to a host. Now I have a better idea of what those steps actually are: From building an image locally to spinning up a pod with the containerized image.

Here’s hoping that I get the opportunity this semester to apply what I’ve been learning on the job in the classroom.