With the rise of microservices and the move away from monolithic architectures, IT and DevOps teams have focused on consolidating everything in infrastructure into a smaller and smaller set of platforms and technologies. The bold vision was that everyone would be on the same single “God platform” with one management plane, one data plane and one easy point of reference. Kubernetes, cloud native and microservices were to be the vehicle for this vision. Everyone would be on the same page, using the same metrics and speaking the same language. Networking and development teams would suddenly mind-meld and joy would ensue.
The trouble is, reality and KPIs have gotten in the way. NetOps, SecOps and DevOps teams need very different capabilities and metrics, to the point that jamming all teams onto a single platform and forcing them to share everything causes real pain to all parties.
The reality for most large enterprises today is that they must live in two worlds: cloud native and the older, but still relevant, monolithic world.
Reality Bites: Teams Need Different Things
For example, NetOps and DevOps have incompatible expectations of traffic management. NetOps wants to maintain security and uptime, with network stability and consistency the primary goal. NetOps teams have to keep the entire company up and running, including applications across finance, HR, marketing and more. So, no, some enthusiastic dev who wants to try out a new Clojure-based microservice cannot do a blue-green rollout this week. File a ticket and get in line, yo. This conservative view makes NetOps unwilling and frankly unable to make changes to firewalls, load balancers and other key networking platforms. NetOps’ caution subverts the entire premise of rapid iteration, continuous testing and snap deployments that are table stakes for agile DevOps.
On the other hand, DevOps, especially when building cloud native and microservices-based apps, needs to be able to make changes to security rules and routing tables quickly to test and iterate at the speed of modern CI/CD pipelines. Services and cloud native applications are, by design, loosely coupled and only succeed when developers have a greater degree of self-determination and control over deployment. At the same time, modern applications are decomposed into so many different services that lack of control at the granular level that can dramatically degrade the ability of DevOps to properly tune and deliver proper application performance, to the point that customers might notice. For DevOps teams, the idea of someone else controlling their deployments feels like a return to the 1990s when they had to wait a month for a server.
For SecOps, microservices and Kubernetes present security challenges that can’t be addressed solely by traditional methods such as ring-fenced security. While SecOps is well-equipped to enforce policies outside the Kubernetes cluster, their tools aren’t suited for lightweight, containerized apps. With inadequate security, configuration errors by Kubernetes teams lead to data breaches and exposures. SecOps becomes the villain when they shield the organization from risk by delaying or halting containerized app deployments in production. DevOps view them as a major constraint on their ability to deliver apps quickly, shadow IT becomes the norm and security is routinely sacrificed in the name of speed.
#cloud native #devops #microservices #contributed
