Container Orchestration vs. the Status Quo
In Agile shops especially, “build vs. buy” is an ongoing and evolving debate among CIO’s and DevOps teams. You see a demo of a new product which solves a problem, you look at the talent on your bench and you think: Yeah, but we could do this ourselves. Then you remember the mountainous backlog waiting for your team in Jira, and you quickly realize that you may not have the luxury of building it OR buying it right now. So it’s actually “build vs. buy vs. the status quo”. And it’s in that calculation where some real opportunities and challenges lie for your business — especially in what it means to be able to continue to get your features to market faster than your competition.
Adding to the challenge, with the recent Cambrian like explosion of containers everywhere from startups to enterprises and beyond, the time tested cloud architecture pattern of “letting the platform do the hard stuff” is being tested anew. Don’t get us wrong: We heart containers! Containers are amazing! Traditional app deployments vs. containerized app deployments is like the difference between mom sending you a recipe and sending you a cake. Everyone loves cake! However, the reimagining of deploying and running app workloads in containers is having unintended consequences for all of us, some of which may have been hard to anticipate when Kubernetes was initially released in June 2014… let alone when Docker debuted allll the way back in March 2013. But indeed, containers are inspiring new and urgent conversations about longstanding operational concerns like scheduling, security, monitoring, and performance, not to mention somewhat newer topics like containerized service discovery and overlay networking.
Read the entire article here, Container Orchestration vs. the Status Quo
Via the fine folks at Entisys360.