0 0

Why Tintri for Software Development?

Typically, there is a disconnect between software development and storage. Software development demands agility— spinning up test environments and tearing them back down again. Conventional storage is simply not designed to support these use cases. Plus, it requires storage expertise—knowledge of LUNs, volumes, RAID, striping and more.

Tintri defies that convention with storage built specifically for virtualized and cloud environments. Since Tintri operates exclusively in VMs, a non-expert can manage it; software development can take total ownership of their storage footprint. And since Tintri eliminates archaic concepts like LUNs, suddenly spinning-up and tearing-down VMs is trivial. Here are three reasons why Tintri will change the way your software development function thinks about storage. 

Challenge #1: Storage bottlenecks impede development agility

Conventional Storage

Development has to halt or slow their software development while they re-configure and re-provision storage. 

Tintri

Tintri VMstore goes from box to rack to running VMs in minutes. There is no complicated configuration or ongoing management, so software development teams (non-storage experts) can own their storage footprint and bypass bottlenecks. 


Challenge #2: Inefficiency of development environments with many copies of similar files or machines

Conventional Storage

Replicate and clone at the LUN level, which adds unnecessary bulk—taking all the VMs in a LUN along for the replication ride. 

Tintri

Tintri replicates and clones individual VMs—only the incremental block-level changes between snapshots—so you can use your WAN and storage up to 95% more efficiently, and quick spin VMs up and down. 


Challenge #3: I/O intensive workloads require sufficient performance reserves

Conventional Storage

I/O requests are scheduled sequentially—First- In-First-Out. So, time sensitive development requests can be slotted behind I/O intensive workloads and suffer from latency. 

Tintri

Tintri assigns every individual VM its own ‘lane’ to guarantee quality of service. That eliminates the ‘noisy neighbor’ problem and ensures that software development gets the exact performance needed for each VM. 

Temporary_css