It’s All About the API: Finding Common Ground

Common ground for storage

I discovered the goodness of API’s (Application Programming Interfaces) when I was working on a project with an IT industry colleague named Les. An API is what we used then to extend a wide area network testing platform across many different interfaces and protocols. Fast forward 20 years and API’s are virtually everywhere.

Les is also a close friend and riding buddy – we get along great on two wheels. I ride a Harley and he rides a Honda: two very different bikes. Our common ground is two wheels. It reminds me of the way API brings a common interface to persistent storage.

I have been specializing on microservices, containers and orchestration on Dell Technologies infrastructure. If you have embraced cloud native, you know that there are reasons for continuing to operate your apps within your own data center. Some things that affect your reasons for private cloud, public cloud, or a multi-cloud are performance, latency, data gravity, etc. Let’s explore the relationship between microservices, containers, orchestration and persistent storage a little deeper.

In the world of microservices, many apps packaged in containers are ephemeral – temporary, stateless, but there is also often a need for keeping persistent data and bringing this data to containers. There have been numerous plug-ins, work-arounds, or proprietary solutions that have been embraced to make this happen. The Cloud Native Compute Foundation community, (CNCF.IO,) brings together the world’s top developers, end users, and vendors and is part of the nonprofit Linux Foundation. The CNCF collaboration has agreed upon a framework, an anticipated industry standard, called CSI (Container Storage Interface) which enables storage vendors to provide access to persistent storage across container orchestration systems such as Kubernetes.

A fundamental reason for the CSI framework is to allow the adoption and development of new or different storage systems, features and functions – independent of proprietary code base. The use of Kubernetes storage API objects allows users to consume storage volumes with their container using documented API objects. These CSI drivers are developed and maintained by third parties such as Dell Technologies. These drivers can now be expanded with features across any number of storage systems independent of any development within the Kubernetes code. Dell Technologies as an infrastructure provider has embraced Kubernetes as a partner that enhances a rich portfolio of storage platforms.

Common ground for automated networking

API’s are great, and now we can use them to automate. A common automation tool for the IT professional and practitioner has become Ansible. This brings to mind the electronics theory I learned in the USAF basic electronics course. They represented ground as negative and electrons flowed from negative to positive poles. Well, I later heard that the US Navy uses positive ground in their electron hole flow theory? Similarly, for automotive electronics I discovered that Ford and International Harvester Company (IH) started with a positive ground theory, yet Chevy chose to use negative ground? Both get the job done.

Ansible playbooks, roles and now collections can be used to automate the configuration and ongoing management of our Dell EMC PowerSwitch Data Center networking solutions. Let’s get the job done another way… gone are the days when a network admin/engineer dropped into a CLI to configure ports on a switch. With the advent of API and now automation tools, this can be fully automated providing a very fast, “at the speed of business” way to maintain your network infrastructure. These Dell Technologies’ networking Ansible roles have provided a common and unified syntax for all the underlying Dell Networking Operating Systems DNOS6, DNOS9 and the Linux-based open networking OS10. Ansible collections is a newer concept, a distribution format for Ansible content that can include playbooks, roles, modules and plug-ins.

Source: dellemc.com