If you are a large Fortune 500 company you have most likely invested billions in data centers, fail over, and your application deployment process. Long before things like Docker and containers, these companies hired top technical talent to make sure their applications scale and run smoothly. Then came DevOps and the race to implement continuous integration and continuous delivery(CI/CD) began.
Having already invested so much money into these data centers, I have heard CTO’s come right out and say “we will never move to SaaS“. When you dig a little deeper what they really mean is they won’t move “everything” to SaaS. – meaning a hybrid cloud may be in play. Now, more than ever, there is a huge push for micro-services, so the pieces and parts the companies care about most remain inside the firewall while the commodity types of technology move to SaaS (or outsourced to put it another way). This still surfaces a problem to those companies that wish to keep mission critical function in house – how do I do it?
CIO’s and CTO’s are being challenged by their line of business users to provide the same level of auto-scaling and availability many SaaS companies provide. If you recall I wrote a fairly popular post here named “Automate, everything“. This is exactly what technical execs are faced with today: few resources and constant budget cuts. By automating everything you provide excellent quality, faster deployments, and faster time to market, all with fewer resources. Do it right the first time and automate!
There are so many options for CI/CD, containerization, and deployment platforms it’s actually hard to keep up with it at this point. I think standardizing on an orchestration engine is key – many argue that Kubernetes is the winner in this space. I have blogged about Kubernetes a lot this year, starting with this article back in March (12 Kubernetes distributions to think about). Standardizing on Kubernetes at least gives you many deployment platforms – internally (IBM Cloud Private), IBM Cloud, Azure, AWS, etc. This also means things like HELM scripts are transferrable across these deployments. These are the scripts that Kubernetes uses to manage your deployments. By standardizing on Kubernetes you are basically standardizing on an open container orchestration technology that doesn’t lock you into a specific platform – as long as it supports Kubernetes your application will “just work”.
I will end with a great technical video that was passed on to me by a colleague. It shows how to build Helm charts from start to finish. So next time you are on the treadmill watch this 30 minute video and see how it’s all done.