Dell Technologies sponsored this podcast.
The tools and technologies DevOps teams rely on for infrastructure-as-code certainly have changed, especially as it has begun to scale for storage. At the same time, the tools, technologies and platforms that started in the hyperscale, cloud native applications and their DevOps environments have actually democratized “scale.” The concepts of configuration management and state-based declarative paradigms are actually reinforcing the fact that “cloud is not a place” and instead it’s how you manage the operations to achieve objectives like self-service, elastic scale and agile application development.
During this The New Stack Makers podcast, a part of the Dell Technologies Virtual Day of Podcast series, we discuss a number of topics relating to infrastructure as code and how it applies to storage — and what that implies in today’s increasingly cloud native-centric world.
A key part of infrastructure as code, as it relates to storage for DevOps teams, consists of the container storage interface (CSI). The API allows for the creation of plugins or storage drivers for container orchestrators, Ohly said. The CSI has evolved so that “storage vendors can deploy a driver that can provide it separately, completely independent from Kubernetes,” Ohly said. “And it runs on Kubernetes as a true add on its own container.”
“So, deployment is also now a lot easier because you do manage the CSI driver just like any other application, but you run it on Kubernetes — it really is very flexible today,” said Ohly.
The self-service model is also increasingly important. On a higher level, business stakeholders use infrastructure and other IT services as if they are choosing from service catalogs, Kodati said. “Thanks to modern platforms, it is getting easier and easier to rely on a service catalog-type of approach,” he said.
Meanwhile, on a lower level, “self-service is acquiring a new meaning,” Kodati said. “It’s self-consumption, like for a developer, a development, a DevOps or a deployment environment — being able to self-service infrastructure without having to go through any manual steps of somebody provisioning storage, making a backup at a given schedule, or taking a snapshot or replicating the data to a different site,” Kodati said. “All these tasks are also being consumed in the code.”
While demand exists to adopt infrastructure as code in order to make, for example, cloud native adoption less complex and more flexible to meet the needs of different organizations, all stakeholders, including the business teams, must have a reasonably deep understanding of what their organization is adopting and how it will affect their business outcomes first.
“Cloud native alone won’t get you there — that’s something that has to be clear that it’s really about how it’s implemented that will ultimately affect how flexible you are,” Paganini said.
Many cloud native-based technologies can also “lock you in,” Paganini said. “Lock-in is not always avoidable, but whenever you go into that direction, it should be a conscious decision, not something you just kind of have to do because you didn’t understand the implications. A lock-in technology alternative really shows “how big those implications can be because it will affect your future ability to react to market demands,” Paganini said.
“And if you’re taking part in these discussions, you have to understand the big picture, so in short, technology is far too important and complex to rely on it to boil it down in a few slides that you can consume. Before you make your big decision, you really need to read up on it and understand it on a high level — you don’t have to be an expert, but you have to understand it on a high level,” said Paganini.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: firstname.lastname@example.org.