Dying Achilles at Achilleion, Corfu

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.

Josh Atwell

Josh Atwell is a Cloud Architect for SolidFire focusing on developing VMware and automation solutions. Over the last 10+ years he has worked very hard to allow little pieces of code to do his work for him through various automation tools. Most recently Josh worked as a vArchitect for VCE where he worked with customers to architect solutions to meet their infrastructure needs. He also served as a VMware and cloud champion, as well as being selected as a technical team lead. Prior to VCE Josh worked at Cisco on the Virtualization Infrastructure Operations team where he focused on automation for VMware, Cisco UCS, and architecting Splunk for all of IT. Josh is a contributing author to the popular Mastering vSphere series and the upcoming Devops for VMware Administrator book. He is highly involved in the virtualization community where he's been active leading technology based user groups and the vBrownBag podcast. Josh holds a degree in aerospace engineering from North Carolina State University and has maintained residence in the Raleigh, NC area.

Add comment