Your AI is Dumb
So, what do you use AI for? What do you mean “you don’t”? Do you want to get the next round of funding or not? Why aren’t you writing code for the new ChatGPT right now? No, I don’t care if that’s reinventing the wheel, hit the keyboard, Jack!
In recent years usage of artificial intelligence and machine learning has become such a popular technology to have that many corporations have claimed it as one of the main reasons for downsizing their staff (the real reason is corporate greed, but that’s a different blog post).
You can tell that a company has been started in the last 5 years if it has the term “AI” in its name (used to be .io, remember that? Well, Pepperidge Farm remembers!) 
Surely this is a sign of how powerful AI is and how we need to learn to speak, read and write in zeros and ones in order to serve the machines that are about to take over humankind!
As a person who spent 3 years working in a company that offered machine learning services as its main product, let me say that AI is not a panacea for all your technological problems, nor is it expected to replace all engineers currently working in IT industry.
I’m not an expert on AI or machine learning by any stretch, but I do have a good amount of first hand experienice in supporting predictive AI to know at least a few of its limitations, how it gets confused (used interchangeably in marketing pitches) with generative AI, and at times used as a fancy facade for a chatbot with roughly same functionality as Clippy (remember that happy-go-lucky helper from MS Word of early 2000s? Once again, Pepperidge Farm remembers).
On the note of predictive vs generative AI, it’s one thing to determine that an article contains narrative associated with a particular political agenda, and it’s a very different thing to actually create a new article with the same narrative. More importantly, however, having AI be able to write a piece of code that takes input A and turns it into output B does not mean that the same AI solution would be able to make educated decisions on how to
incorporate that code into the existing framework without introducing bugs, or
make it scale with the consideration of a specific company’s resources and constraints, nuances of the product, or other crucial factors inherent to a particular business/industry (e.g., seasonality of sales).
For that, you need a seasoned engineer who has context of the product and experience in taking strategic approach to problem solving. You can use AI to automate the kind of work that an inexperienced out-of-college engineer would do (thus circumventing employment prospects for fresh engineering graduates, but who needs them anyway, amirite?), but that won’t fly with anyone who’s been around the block.
Good Things Can Be Famous Too!
Don’t get me wrong, not all technologies that become famous are based on hype. One of the tools I’ve come to love recently is ArgoCD.
No, they’re not paying me to say it. It would be nice though.
I got introduced to it when I was at a company where we used it as part of software development lifecycle side by side with Jenkins. At the first glance, it seemed feeble compared to Jenkins, which is fairly more of a DevOps swiss army knife than just a code deployment platform. My initial reaction was along the lines of “why would we use a different tool for SDLC when Jenkins does all the same things and more?” However, as I got more acquainted with Argo, I realized a few important things that set it apart from Jenkins.
Namely, simplicity and closer integration with Kubernetes.
Sometimes, Simple is Good
Why is simplicity good? First of all, I’m calling ArgoCD simple here specifically compared to Jenkins. As much as I love Jenkins, I have to say that over the years it has become too versatile for its own good. The Jenkins plugin repo shows over 1900 plugins. I bet you there are at least a 100 that let you create a cronjob. Of course, it’s great to have options when it comes to solving any problem.
However, the issue comes in when you start searching the web for info on how to solve the problem with your specific requirements. That’s when it becomes apparent that there are 10 solutions that solve your case about 95% of the way, but only 1 that will take you over the finish line.
This isn’t nearly as big a problem with ArgoCD given its much narrower scope. It’s used to deploy containerized applications running in orcherstrated environments (namely, K8s). You’re not going to use it to deploy code to a handful of standalone HP Proliant DL385 servers. You know what it does and doesn’t do, and it’s fairly easy to choose whether it suits your needs and if yes, to also figure out how to use it to that end.
Current vs Desired State
Another advantage ArgoCD has over Jenkins is its tight coupling with K8s’s ETCD key-value store. Essentially, this allows ArgoCD to determine in real time the current state of components it manages. In my experience, Jenkins can only tell you what code/configuration it pushed last, not necessarily what happened in your ecosystem since then. Now, I’m sure there are about 20 Jenkins plugins that can accomplish that in some fashion, but… see the previous paragraph.
Why is that important? There are at least two reasons.
First, the config drift that takes place between deployments may make the difference between your code/config deploying successfully, or getting stuck somewhere midway, leaving you to wonder if you should roll back or roll forward or simply roll over and die. Therefore, the ability to tell the state your environment is currently in provides the crucial information when it comes to planning your releases.
Second, ArgoCD threads a rather fine needle of the tech stack between the application you’ve built and the elastic compute resources (e.g., EC2 instances), the land populated by Kubernetes constructs. This is important not only because this part of the stack sometimes falls through the cracks of conventional monitoring and application performance monitoring (APM), but also because of external dependencies.
Unfortunately, when we sign up to use external packages, be it in the form of Helm charts of just individual Kubernetes objects, we allow for a possibility of a 3rd party vendor changing things up in the next release and potentially yanking the cloud computational chair from under our industry-disrupting butts.
You may say, there’s an approach to solving that problem, and it boils down to bringing all external dependencies (forking 3rd party repositories, downloading packages to a server in your environment, etc. etc.) in house and maintaining them yourself.
No more depending on 3rd party vendors! Great, right?
Shut up. You don’t know nothing.
If you want to be a glorified package/repo librarian living on a secluded island that is secluded because nobody else wants to live there, then by all means, but some of us have some engineering to do! Let’s be honest, dependencies are difficult to manage, even if you specify every single version of every single library / Helm chart you use.
ArgoCD helps with this by providing visibility into your application’s ability to “sync” to the desired state. Just the other day we had an issue where a newer version of a Helm chart caused one of the app components that used the chart to become unhealthy. Mind you, all of the application’s pods were healthy. On the surface, everything was hunky-dory. However, Argo showed a failure of the component to sync, and when we looked at the diff between the current and desired manifests, it became clear that we were dealing with a Kubernetes component label that was deprecated in the newer version of the chart.
To sum this up, ArgoCD’s ability to keep its hand on the pulse of your containerized application’s state specifically in the orchestration layer is what will let you know if you’re actually ready to kick off the new release or not.
Tying it All Together
I can definitely think of a handful of other examples that would fit the “don’t” bucket or the “do” bucket, but in short, I hope I’ve conveyed my point to you from the comparison of these two technologies.
This is by no means a way to advertise ArgoCD. It is not nearly as versatile as other SDLC tools such as Jenkins, but the important part is, it serves the purpose.
By the same token, in no way do I imply that AI is useless. Just like any other tool, it has its purposes, and that’s really the point I’m driving at here. I do believe that it’s become quite the IT industry’s version of the inflatable arm-flailing tube man on the corner of the car dealership. Nonetheless, it does not negate the fact that in the right scenario it’s a powerful tool that drives progress forward.
All the difference is in your choice.
You can choose to be the kind of a person who composes their tech stack based on TechCrunch tech blog articles.
Alternatively, you can choose to be an engineer.
One of those requires doing research with consideration of your business needs, resources and constraints, as well as using critical thinking. Coincidentally, those are abilities that won’t be replaced by generative AI any time soon.
Thanks for reading this far.