You already know the promise of running infrastructure as code. Having extensible infrastructure means programmatic control, robust integrations, and great agility. Organizations are adopting infrastructure in large part because of its extensibility and the general robustness of its API. We see this all of the time with SolidFire customers.
Today’s IT organizations develop tremendous amounts of automation to run their IT and development shops, enable DevOps groups, and extend features to their cloud management platforms. Dependencies on the API and its associated integrations now exist, but what happens when you need to upgrade the infrastructure to take advantage of new features or capabilities? What impact will this have to your automation?
The typical response to infrastructure upgrades that possibly affect automation is to do an extensive API change test/review before upgrading the infrastructure. This means a delay in adoption since no one wants potential disruption to the critical automation put in place to support the business. This means more time to wait to get value from those features — and potentially considerable energy spent.
SolidFire is different. Not only do we offer a full-featured API, we also offer side-by-side APIs on every system. This means that with our ninth release of Element OS, named Fluorine, an organization has an opportunity to update to this version without concerns.
We accomplish this by maintaining the previous versions of the Element OS API, think 8.0 Oxygen and 7.0 Carbon, on the system at all times. All an organization needs to do is ensure that their system connection strings be targeted to their current code version for all of their integrations.
Let’s walk through how this looks with a famous fictional company. ACME Anvils has a SolidFire cluster, and they are excited about the greater performance and efficiency offerings in Fluorine. They are also keenly interested in implementing VVols to support a new service offering. To prepare for this upgrade, they simply need to target their connection strings for any API usage to the current version string.
They can perform the upgrade to the cluster, and that API target persists. Once the upgrade is complete, they have a new target URI ending with /9.0 that serves as the new default. Additionally, both URIs can be used on the same system without issue, allowing them to easily test after the upgrade is completed if they’re taking advantage of the new features and capabilities.
Interested in seeing how our API changes over time? Visit our GitHub page, and pull full Postman API collections for numerous versions of Element OS. Check it out here.