devopsy.kinsta.cloud

Tag: storage

  • Is Your Storage Too Slow for DevOps?

    Is Your Storage Too Slow for DevOps?

    To have a successful DevOps transformation, teams on both the development and the operations side need fast storage infrastructure and high-performing tools to maximize its performance and the people that work with it.

    Over the last decade, a major operational problem in on-premises enterprise data centers have emerged, as the fundamental mismatch between the infrastructure and the needs of increasingly virtualized applications has become glaringly apparent. There is a major contrast between what organizations want their staff to focus on—strategic projects, new application deployment, new customer acquisition and releasing new products—and the things they end up spending too much time on. This includes infrastructure “plumbing” and reconfiguring, re-architecting or redeploying across all stacks.

    The widespread adoption of virtualization has introduced increasing complexities to IT infrastructure. It is also spurring businesses to accelerate development efforts and deliver applications and services through a DevOps model. The arrival of cloud infrastructure and cloud-native workloads has made addressing the mismatch an even more pressing issue. As they seek to overcome the shortcomings of outdated traditional infrastructures, organizations are adopting a cloud strategy that includes the public cloud and, in many cases, their own private cloud built from all-flash storage and intelligent software.

    This move to a hybrid cloud platform, a mix of public and private cloud seeks to blend the benefits of public cloud for workloads that need agility and scale, while retaining control of workloads and data that would be better served on-premises because they are too valuable to entrust to other providers.

    An effective storage platform should combine the performance, control and management of an internal data center with the agility and scale of public cloud. This provides organizations with the ability to build and run agile environments for cloud-native and mission-critical applications in their own data centers. It also helps to solve the fundamental mismatch between infrastructure and virtual applications and helps prepare organizations to adopt DevOps practices, which cannot be fully supported by traditional infrastructure.

    Choosing the Right Storage Platform for DevOps

    The growing emphasis on DevOps is placing an extra burden on infrastructure teams, so choosing the right platform to underpin the IT infrastructure is highly significant. This will ensure the DevOps model works for the organization and makes life easier for the IT infrastructure team.

    Traditional storage systems often are unable to match the requirements for a simple, flexible and automated enterprise infrastructure. A number of issues must be taken into consideration for the enterprise cloud infrastructure to work with the DevOps model, including:

    • Copy data management
    • Data protection
    • Disaster recovery (DR)
    • Quality of service (QoS) and performance guarantees
    • Monitoring and troubleshooting
    • Automation

    The problem for copy data management in DevOps is that refreshing and updating testing/development environments is time-consuming, and rapid test cycles require data synchronization with potentially hundreds of servers. A system is required that provides up-to-date virtual copies to the DevOps team, eradicates the need for physical data duplication, lifts the load on production storage and protects the performance of applications. Modern storage systems in conjunction with next-generation software can create data copies using snapshots, cloning and replication—and they can utilize the same technologies to protect and manage the development side of the environment in the event of failure or data corruption.

    When seeking to adopt DevOps, quality of service (QoS) and guaranteed performance is a major factor. QoS is vital to control the performance allocation of a storage system to different workloads. It gives organizations the capability to set a maximum and minimum on the number of input/output operations per second (IOPS) or bandwidth consumed. Using the higher performance of all-flash and QoS, DevOps can be consolidated on the same platform as production, making it easier to access production data sets while reducing the storage footprint.

    Organizations that want to provide data at a speed for DevOps need the ability to monitor the infrastructure and correct problems and misconfigurations rapidly. Continuous monitoring and end-to-end visibility across the IT stack, along with predictive analytics, integration with other monitoring tools and VM-level monitoring, are particularly valuable attributes when seeking to provide the basis for data-driven decisions in a DevOps environment.

    It is also critical that the storage platform provides the capability to provision and manage IT infrastructure programmatically. With the increased use of automation, organizations can create and break down environments as necessary, incorporate snapshots and cloning as part of daily workflows and eliminate the potential for error from manual or interactive configuration.

    The Case for Fast, Virtualization-Aware Storage

    Implementing a storage system that is able to match the requirements of a simple, flexible and automated enterprise infrastructure delivers many benefits to the organization and to the DevOps environment. Virtualization-aware storage eradicates the need for logical unit numbers (LUNs) and volumes and enables enterprises to work at the VM and container level. With clean REST APIs, they can connect all-flash to compute, network and other elements of the cloud and see and share across the entire infrastructure.

    Using virtualization-aware storage, application test and development can be accelerated from a matter of days or weeks to minutes. By retaining custom settings and automating with APIs, rather than having to rebuild the entire environment after every data refresh, enterprises can radically speed up the release cycle and integration testing.

    For example, using this approach, one financial services company was able to reduce development update time from five hours to five minutes and slash latency by 82 percent. With the visibility into files, VMs and vDisks provided by virtualization-aware storage, it is possible to recover these in fewer than five clicks and response times can be reduced dramatically.

    Data at DevOps Speed

    As enterprises move inexorably toward a mixture of virtual and physical, on-premises and cloud-based IT, it is imperative that their storage platform can seamlessly work across physical and virtual environments. This will facilitate DevOps environments to meet its goals while eliminating concerns around performance, scalability, manageability, resilience and flexibility.

    The storage system underpinning their IT infrastructure platform needs to support businesses in their desire to replicate the agility of public cloud within the data center while making it easier to manage enterprise and cloud-native applications. Adopting virtualization-aware storage can ensure their data is ready for the DevOps model. Enterprises wanting to deliver data at DevOps speed can’t afford to keep their storage in the slow lane.

    — Chris Colotti

  • When Bad Things Happen to Good Clouds: Why You Need a Recovery Plan

    When Bad Things Happen to Good Clouds: Why You Need a Recovery Plan

    Amazon S3 storage service recently experienced a widespread five-hour outage in its East Coast availability zone. Many next-generation consumer and business applications rely on a cloud storage, so the S3 outage quickly cascaded and temporarily crippled organizations from Netflix to Slack.

    Cloud outages like this are normal, and notable because they affect so many businesses. The last significant AWS outage was in August 2016. While Amazon S3 is architected for data durability, that doesn’t equal fast recoverability during an outage. As good as cloud platforms are, they still leave a few gaps:

    • Availability zones don’t equal recoverability. S3 is designed to withstand a site outage within a zone, but as the most recent outage shows, networking issues can lead to a widespread outage across an entire region.
    • Data still needs to be backed up. As we noted in a previous blog post, even Amazon recommends backing up data.
    • Recovery can be slow and tedious. It’s one thing to back up data. It’s another thing entirely to recover it. It can take hours or days to recover data after a failure—especially for hyperscale applications and databases.
    • Data is often in one “basket.” If backup data is stored in the same cloud service as the primary data, in the same availability zone, there’s no way to recover data during a widespread outage.
    • Data can get compromised or enter an inconsistent state. The cloud itself doesn’t protect data from application- or database-level corruption, or human error.

    A data backup, recovery and continuity strategy needs to be designed with the cloud in mind. To make sure you can recover quickly, even from a cloud outage:

    • Keep backup data in another service or region. Failures like this one often affect an entire region. A backup and recovery strategy needs to include the ability to recover in another region, cloud service or even a private cloud.
    • Have a fast recovery process. Traditional backup solutions and scripting-based approaches can’t recover data quickly, particularly if the application needs to be recovered to a different topology.
    • Have point-in-time recovery. Since data can get compromised at the early stages of an outage, being able to restore applications quickly to a point in time is important as well.

    The cloud as-a-service architecture is more resilient than traditional infrastructure, and gives you agility. But when failures do happen, they are also entirely out of your control. Don’t ignore recoverability and resiliency of the data because it’s in the cloud, and don’t expect the same recovery processes and tools to work on next-generation, hyperscale applications.

    — Shalabh Goyal

  • Deep Art of Scaling for Cloud Environments, Part 2

    Deep Art of Scaling for Cloud Environments, Part 2

    In Part One of our two-part series on scaling for cloud environments, we looked at some of important factors for scaling and best practices for code storage. Let’s continue the discussion.

    Auto Scaling for Next-Generation Applications

    There are a few very good-looking cloud hosting service providers that provide the features mentioned in Part One: AWS, Google Cloud Platform (GCP) and Microsoft Azure. If you are going to auto scale, it’s best to use one of these cloud hosting services. There are other cloud hosting service providers in my knowledge that follow similar approaches, but they are not widely used or are platform-as-a-service (PaaS) ecosystems so we will not cover them.

    Also, it’s important to remember that in auto scaling, all app nodes are changing and created dynamically, with a new host, new IP, etc., so your synchronization mechanism needs to determine how to update the code with the new nodes that may change or be deleted later.

    Options to Auto Scale and Not Die Trying

    Lsyncd

    Lsyncd allows you synchronize nodes across the cluster that are spinning up/down new instances, Work using this script, which monitors the auto scaling group for new nodes and updates the Lsyncd master with new auto scaled slaves. Discovering which IPs or instances are within the auto scaling group is the preamble auto scaling faces, but this script will help resolve the discovery.

    GlusterFS

    Another approach is to use GlusterFS, which ensures high availability and syncs between your web nodes. You need a minimum of two instances in case one fails. The other instance can jump in and still be tolerant for failures. Once the failed instance is back online, it’s added again to the cluster. GlusterFS works similarly to master/master or master/slave. I won’t cover how to configure GlusterFS, but I’m sure this approach was a very good option before AWS EFS was released. If you are not using AWS, this is an awesome option.

    On the other hand, if you are using AWS environments with EFS, consider registering your web node to the master node using “AWS User data,” so every time a new EC2 instance is created by the ASG, it will register this new volume to the master and keep data synced with the rest of the nodes.

    Pre-Baked AWS AMIs (Old Approach)

    Given the fact that your code won’t change or barely changes, baking an AWS AMI and updating the auto scaling launch configuration will do the trick—this is an older but still-used approach. When you have a defined code release schedule and a defined development workflow, you could bake an AMI for every new code release and, once ready, recycle the nodes to use the new AMI with the latest code update. There are plenty of tutorials on this method.

    Admin Server (mainly used for WordPress, Drupal, Magento and CMS-based apps)

    Another wild approach is to use an admin or master server out of your auto scaling group. This is used commonly to sync code from the master to the scaling group, but I believe this a waste of server resources that can be used inside the auto scaling group. I would recommend this approach for WordPress or Magento sites; in addition to this, consider proxying the wp-admin or administrator URL to the admin server, or update the CMS directly to the admin server. As with NFS, AWS EFS will facilitate everything with WordPress, Magento, joomla and CMS-based apps. Click here for an example of what I’m talking about.

    Implement AWS EFS

    Finally, the easiest approach is AWS Elastic File System – EFS. Amazon Web Services released EFS a few months ago as a very promising technology—a distributed file system similar to NFS but improved—think of it as a sophisticated NAS solution. During AWS Re:invent, the company said EFS is based on NFSv4.1 but with better network performance, and is a pNFS workaround. I have waited for such a component in the arsenal of AWS for months, though early access was only available for the Virginia region. Today, though, it is supported across all AWS regions – Yay!

    EFS can be mounted as a local mount point within fstab, similar to NFS, and you can share your code across your AWS auto scaling group: Set your EFS volume in/etc/fstab to load automatically in each reboot. Therefore, If you are in AWS, use EFS; it will facilitate everything—really. To accomplish this approach, make sure to update your user data in each EC2 instance with the EFS mount point, so every time a new instance is created it automatically will have the EFS volume.

    Note 1: All EFS mount points should be in the same region; if an EC2 instance tries to mount from another EFS region, it won’t be allowed.

    More Details can be found here.

    Google Cloud Platform

    Well, what do we have for Google Cloud Platform? I suggest GlusterFS, Lsyncd, rsync or Google Cloud Storage—although it shares a lot of features with Amazon S3, it is faster. Google states that its cloud storage is faster than Amazon S3 due to its infinite edge points across the world and, yes, it is correct. The easiest way to share the code across your auto scaling group is to use Google Cloud storage and GSutils. Additionally, you could use GSutils and call the bucket in each Google Instance—just make sure the visitor/user does not change the code or static content in the instances. Also, Gsutils helps sync the bucket data to your instance data to stay in sync. If your code changes dynamically with your traffic, you need to use gluster or Lsyncd, given that it is very complicated to deploy since Google auto scaling is always recycling instances/IPs and needs some workarounds.

    Don’t Forget Scaling Databases!

    Another topic that we didn’t touch was scaling a database, for AWS RDS, DynamoDB, Postgresql, Mysql and Nosql databases. All these modern databases are easy to scale; some of them are PaaS such as DynamoDB or RDS. For Postgresql, MySQL exists only for manual scaling, which is adding new database nodes to the master/slave cluster. In AWS RDS, with some clicks you can get a slave “replica” and you are scaling already. But I won’t go further about it as it’s out of scope for this piece.

    Scaling Microservices and Serverless Apps

    Definitely, these topics need another talk. There will be another time to explore this new architecture approach of splitting your application into pieces. Microservices is changing the IT paradigm, but to survive for this new paradigm, you need to understand first scaling for cloud before evolving to microservices with Docker, Consul, Compose, RancherOS, AWS ECS, Kubernetes and Serverless apps architectures.

    Conclusion

    diagram

    As you can see, scaling an application can be challenging when you are dealing with a custom app or CMS-based application. With this article,  you have the options and their pros and cons in tackling this constant preamble of how to scale with custom apps. Everybody uses their own scaling process and seriously, they never fit with other applications’ needs. Now that AWS EFS is out there, I’d recommend it every time you can, but in case you are not using AWS, implement Lsyncd or GlusterFS, but don’t forget the other methods that also can help accomplish your scaling goals.

    About the Author / Alfonso Valdes

    alfonsovaldesAlfonso Valdes is the CEO and Founder of ClickIT Smart Technologies, a IT agency focused in the architecture and implementation of Modern Cloud Applications highly resilient in Linux and Open Source technologies. He combines more than 8 years of IT experience in the field of scalable architectures, distributed systems and developing cloud-native applications, and has worked for different U.S companies such as: Sprint Nextel, Texas Instruments and Nike USA. Nowadays he is encouraging enterprises to join the cloud. Connect with him on LinkedIn.

  • Deep Art of Scaling for Cloud Environments, Part 1

    Deep Art of Scaling for Cloud Environments, Part 1

    The number of resources to scale an application are abundant, but every application has its own challenges to scale successfully, and the solution to this problem doesn’t come handy. This two-part article focuses on the best approaches to build a scalable application, software-as-a-service (SaaS) application, mobile app, or WordPress-, Drupal- or Magento-based website. The scope of the approach extends to both auto scaling and manual scaling.

    In my experience, there are two types of applications: ones that use an admin and Admin panel to modify the code, layout and functionality (WordPress, Joomla, Drupal, etc.) and modern, next-generation applications that are stateless and follow the 12-factor app approach.

    But first, we have to decide whether to use auto scaling or manual scaling. It is an important decision to make in the very beginning, as it changes the whole approach and complexity of developing your app. We will be discussing both, but in essence of auto scaling, you will need to consider how to maintain the code synchronized across the web nodes and how to maintain new web nodes that constantly are being created/deleted in the auto scaling group. (With stateless apps this is not an issue, as the images or static content can go to Amazon S3, CDN or isolated services. Later on will explain a bit about these technologies.) Working with manual scaling will facilitate your work—you just need your code synced across all the web nodes. All of the approaches mentioned below apply to manual scaling.

    But on the other hand, auto scaling with an admin application is a headache for some common reasons: Every time a front-end developer  changes something in the admin, code will be inconsistent across multiple web nodes along with the Git versioning.  Because of this issue, I don’t  recommend using Git for such applications—there are always discrepancies between the last commit/version in Git and the last update in the admin CMS, which makes auto scaling with admin even more complicated.

    Let’s cover some approaches to solve this problem. Using an NFS distributed file system will resolve everything for a CMS app, but as everybody knows, this approach pulls down the performance.

    What’s Important for Scaling:

    • Designing a deployment workflow that is easy for your team, your manager and developers—that’s why you are here, to improve development productivity by defining a good mechanism to deploy code to your cluster or auto scaling group. Here, you can think of Webhooks, rsync cronjob, bash scripts, Jenkins, CircleCI, DeployBot, manual pulls or AWS CodeDeploy.
    • Isolating and centralizing all services. Databases, caching session, integrate s3 for static content, implement CDN, worker servers, cronjobs, Load Balancer, app server, web server, etc., to name a few.
    • Dynamically synchronizing code in a live application with many web nodes behind a load balancer or AWS auto scaling Group.
    • Ability to use the 12 factor approach for next generation applications, or stateless apps. You may be using this approach already but you don’t know it!
    • Bootstrapping your application with a stateless approach—this will facilitate all your work when you implement a scalable infrastructure. There are many ways to bootstrap your base application using bash scripts, docker files, vagrant file, AWS code deploy, git, user data file from AWS and baked AWS AMI, among others.
    • Using immutable servers in your environment. Make sure your applications and servers are in a pre-configured image state. Every moment a new server/instance is created in an auto scaling mechanism, the instance should be identically cloned of any other instance in production without any further configuration. As you know, AWS, Docker, Google Cloud, and cloud-based providers are much more easier for immutability. This really helps to deliver software faster and decrease time to market.
    • For CMS based apps, stay out of git for now, unless you have a very good code change control with your CMS admin and a very good discipline to push your changes with every dashboard/back-end change in the CMS.
    • A load balancer for auto scaling, such as AWS ELB, Google Cloud LB, Nginx or HAProxy.

    Advised Practices for Code Storage

    Understanding how your application works in terms of how visitors dynamically change your application data is very important. It’s imperative to understand how the session is saved, either locally or in Redis/Memcached. If it’s saved locally, you need to add this data to your synchronization mechanism. Another storage change is the user image uploads for WordPress or Magento-like CMS-based websites; use of plug-ins such as Wp super cache or w3 total cache makes image upload configuration easy. Plus, the option to integrate with a CDN, Amazon s3 or a cloud storage pushes the boundaries even further.

    But if you have a modern application, you need to understand and guide your development team how to change local image uploads path to a cloud storage or CDN. Make sure all your dynamic data is saved in a SQL or NoSQL database, and all cached database data (db queries, objects, sessions, keys, etc.) is saved to redis/memcached, Taking care of these factors will facilitate your scaling journey.

    Why not use NFS?

    Well, we hear a lot around the internet that the easiest way to achieve scalability is integrating NFS. Though it is the simplest way to look for and implement a fix, reducing the work for a service provider/developer  by almost 50 percent, it’s a real sacrifice in terms of application performance. Autoscaling an environment with a slow response speaks against the whole cause of the setup! It is very irritating to a client whose application speed is 1 second to 2 seconds when switching to a scalable environment with NFS slows the application by at least 50 percent.

    It’s also very disappointing when your small EC2 instance is much faster than your auto scalable environment with NFS. Additionally, using NFS has a point of failure, unless you have a failover in the cloud that is rarely used. It is just not worthwhile to have a complete standby environment waiting for a failure, and it’s better to use this environment within your cluster and have more resources to consume your traffic, or even better use this redundant environment to balance between different regions or data centers.

    Why not use Amazon S3 to Share Code?

    What about using Amazon S3, Google Cloud Files or any cloud storage to share code?

    Implementing Amazon S3 to share code between nodes will slow down your site similar to NFS. There’s not much of a difference accessing the S3 URL to mounting the S3 to a Linux directory, so don’t use Amazon S3 as the document root or code base folder. Keep the use of S3 limited to static content that needs to be fetched over time. Yes, there are websites that can survive and work decently using Amazon S3 for static web pages, but from my experience, I don’t recommend it for websites that support an application responsible for driving revenue to the company.

    Stay tuned for Part Two of our conversation on scaling for cloud environments.

    About the Author / Alfonso Valdes

    alfonsovaldesAlfonso Valdes is the CEO and Founder of ClickIT Smart Technologies, a IT agency focused in the architecture and implementation of Modern Cloud Applications highly resilient in Linux and Open Source technologies. He combines more than 8 years of IT experience in the field of scalable architectures, distributed systems and developing cloud-native applications, and has worked for different U.S companies such as: Sprint Nextel, Texas Instruments and Nike USA. Nowadays he is encouraging enterprises to join the cloud. Connect with him on LinkedIn.

  • Backup and Recovery of MongoDB, Part 2

    Backup and Recovery of MongoDB, Part 2

    This blog is the second in a two-part series on backup and recovery for MongoDB. In one of my previous blogs, I covered why companies require both replication and backup for enterprise grade data protection. And in the first part of this blog series, I discussed the existing solutions for backup and recovery of MongoDB and their drawbacks. Now in this blog, I will discuss the key requirements for protecting data that resides on MongoDB (deployed either on-premises, on private cloud with an as-a-service model or in public cloud with Amazon AWS or Google Cloud Platform).

    Requirement 1: Online Cluster-Consistent Backups

    Next-generation applications deployed on MongoDB must be always-on. This means pausing the database to make backups is not feasible and the backup operation should not impact the performance of the application. As the application scales, the underlying MongoDB also needs to scale-out to multiple shards. In this case, a backup solution must provide a consistent backup copy across shards without disrupting database and application performance during the backup.

    Advanced Data Management ServicesRequirement 2: Flexible Backup Options

    Depending on the application, data may have different change rate and patterns. For example, in a product catalog, certain items may be refreshed every day (fast-selling goods, for example), while the others may have longer shelf life, such as premium items. Based on the application requirements, some collections may need to be backed up every hour versus others that may be backed up daily. Providing this flexibility to schedule backups at any interval and at collection level granularity is another requirement we have heard from customers using MongoDB. More importantly, these backups always should be stored on the secondary storage in native formats to avoid vendor lock-in.

    Requirement 3: Scalable Recovery

    During its life cycle, data resides in multiple stages such as development, test, preproduction and production, and also may reside in multiple clouds (private cloud and public cloud). The topology of MongoDB clusters at each stage is different. For production, the application could be deployed on a sharded MongoDB cluster on-premises, but the test team might have access only to unsharded MongoDB clusters in the Amazon AWS (public cloud). Hence, the backup solution should allow multiple restore operations such as sharded to sharded (such as from 5×3 cluster to 2×3 sharded cluster) or sharded to unsharded (such as 5×3 cluster to 1×3 unsharded) across such cloud configuration.

    chart

    Requirement 4: Handling Failure

    Failures are a norm in the distributed database world. However, the backup solution should be resilient to database process failures, node failures, network failure and even logical corruption of data during backup and recovery operations. Finally, the backup solution should be able to handle failures of MongoDB config servers that store metadata for sharded clusters.

    Customers are deploying MongoDB in physical servers, private clouds and microservices such as frameworks, and in public cloud.  Backup and recovery should be seamless across these deployment example and the ease of backup and recovery deployment is a big one for MongoDB customers and I will cover this in the next blog. Stay tuned!

  • 3 Tips to Avoid Painting Your DevOps into a Scalability Corner

    3 Tips to Avoid Painting Your DevOps into a Scalability Corner

    When everything is firing on all cylinders, DevOps can be awesome. Teams work together seamlessly. Routine tasks are automated. Continuous delivery is continuously integrated, continuously tested, continuously deployed and continuously monitored. All is well, and right with the world—unless your DevOps needs begin exceeding the capacity of the platforms and tools you depend on. Scalability is a crucial element of DevOps success.

    Wikipedia defines “scalability” as the capability of a system, network or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth.

    The need for scalability is one of the primary reasons that DevOps and cloud computing are so integrally linked. While it’s possible to do DevOps on some level using physical hardware or virtual servers running on hardware in a local data center, it can quickly become impractical—if not impossible. Cloud computing using platforms such as AWS, Rackspace or Microsoft Azure enables an organization to increase server capacity exponentially at the push of a button.

    “Many of the issues and challenges experienced before the advent of cloud are no longer issues: Engineers now working on cloud implementations remember working at companies that feared the Slashdot effect—a massive influx of traffic that would cause servers to fail,” explains Jason McKay, VP of Engineering for Logicworks, in a blog post.

    Tackling Scalability

    There are a number of factors impacting scalability in your environment, which could impact the success of your DevOps. Here are three things to keep in mind to ensure your environment is ready to scale:

    1. Make sure your tools and apps are scalable

    The ability to scale capacity on demand—automatically—is one of the chief advantages of cloud computing, and one why cloud computing is so important to DevOps success. There is more to scalability, however, than just server and network capacity. You must also ensure that the tools you rely on can seamlessly scale with the infrastructure, and that the apps you’re delivering through your DevOps environment are designed to take full advantage of the increased capacity as well.

    2. Continuous optimization

    Some tools and apps will continue to run as the underlying infrastructure scales up or down, but may not run optimally. Make sure that the tools you use and the apps you deploy are able to continuously adjust to changes in server, bandwidth and storage capacity. The tools and apps should be able to take full advantage of the resources available to ensure the best performance possible at all times.

    3. Don’t forget about storage

    Most apps have a data component and that means there is data storage that must be scaled as well—either as a function of the broader network infrastructure scaling or just in response to increased demand for data storage.

    Dan Leary, VP of Products, Solutions and Alliances at Nimble Storage, believes that scalability is emerging as a differentiating factor between storage solutions. “Due to the high performance offered by many vendors of flash-optimized storage solutions, performance will no longer be the primary differentiating factor when considering one vendor over another. Instead, a much greater focus will be placed on the array’s reliability, data integrity, scalability, manageability and in-built data-protection capabilities. We are now getting to the point where performance in storage has been democratized and will change the way people purchase storage.”

    There is one more thing to remember when considering scalability: cost. While it may be easy to automate scalability on cloud platforms, it’s not free, and the DevOps tools you depend on may include licensing fees that could be impacted as your usage scales, so keep that in mind.