June 20, 2019
Topics: 5 minute read
“Eureka!” Luke exclaimed with a sigh of relief. As an SRE with a system engineering background, Luke had spent months on end trying to rehost and operationalize the development and production pipeline for one of their key business workflows in the public cloud. This workflow uses a widely popular suite of applications called JIRA and Confluence, from Atlassian. Many companies are leveraging these apps for agile project management and enterprise content management and collaboration.
As a world-renowned lifestyle, clothing, and accessories retailer, Luke’s company had a clear digital transformation strategy: they were ‘cloud first’. Their goal was to build a multicloud-ready environment that could scale horizontally, globally, and provide seasonal burst capabilities. On a global scale, that capability would then allow them to find new ways to differentiate their world class products, reaching even more customers.
Like others, Luke’s company was also looking to lift this workflow into the public cloud, where they had already built out some key production components. Approximately 300 developers were using these tools on a day-to-day basis, and they were promised an enhanced end-to-end experience in Google Cloud with a high degree of reliability.
On the IT side of their transformation efforts, the company had a certain degree of cloud maturity because they’d previously deployed development and staging projects in the cloud, including some new production workloads. With Luke’s help, the company had already carried out rationalization and assessment for all of their existing business apps running on-premises, with the goal of categorizing them as “lift and shift” or “refactor” and provide a pathway to production in the public cloud.
Having had some early success with devops projects in the public cloud, the company’s cloud center of excellence (COE) team (Luke was a member of the committee, along with his colleague Ted) was now targeting the migration of the data layer (unstructured files) for this JIRA and Confluence suite of Atlassian applications. This was a production environment in Google Cloud, meaning that reliability and availability were top concerns.
Ted is a senior platform manager with decades of experience at the company in question. He has firsthand experience with the reliability challenges of software development and new releases in on-premises infrastructure. This application had many dependencies, as well as a complex network of file shares, application processes, and user access workflows that needed to stay intact as they moved to the cloud.
Native Cloud Options and Challenges
The cloud team built out a replica of their application development and testing and production environment in Google Cloud. They were easily able so spin up a number of compute instances for both their application tier and their middleware tier. They proceeded with the production instances in Google Compute Engine (GCE). For structured data layer needs, they were able to leverage Google’s persistent disk and other managed database services for their workflows.
It was a different story when it came to the unstructured and file data layer. Luke and Ted spent months with their team trying to swap out this file layer with what was a very promising object storage tier—or so they thought.
After some hard lessons, they arrived at the same conclusion as many other applications owners: moving to the cloud is impossible without breaking down existing business processes, the application’s stringent need for POSIX compliance, and NFS and SMB protocols in their application code. They needed to keep the unstructured data layer and all efficiencies intact.
But Luke is a persistent person. Luke had, by then, seemingly exhausted all cloud-native and marketplace options in the cloud. Native solutions, such as DIY file servers, still had the same on-premises infrastructure “pain points”. The DIY approach was also a huge step backward from running the file tier on an enterprise grade system on premises.
The marketplace offerings were slim in terms of capabilities—and the options were limited. In addition, the marketplace didn’t offer holistic solutions. The company had to, for example, employ a different system to manage billing and support—and all of the options had mediocre performance reviews. Beyond that, they needed to protect their business-critical data, make point-in-time snapshot copies, create backups with cross-region replication capabilities. One of their key motivations was to improve the reliability and availability of the application.
Luke and Ted Take Cloud Volumes Service for Google Cloud For a Spin
Finally, Luke and Ted decided to give NetApp® Cloud Volumes Service a try, in the us-east4 region for NFS endpoints. Having had some on-premises exposure to Netapp’s solutions in the unstructured data arena, Luke and Ted were thrilled to hear that Cloud Volumes Service was already available on all three major cloud providers (AWS, Azure, and Google Cloud). They found it even more exciting that they didn’t have to spin up or manage any underlying resources.
Cloud Volumes Service is a fully managed offering available in Google Cloud. It offers consistent performance with adjustable performance tiers (for example, the Standard tier may be best suited for a testing environment, while the Premium tier may better suit a production load). Users can dynamically move between tiers. Luke started out with one 5TB volume at the Extreme performance tier, and plans to expand to 350TB as his company completes the cloud migration.
As an SRE, Luke could also check the final box: data protection. Cloud Volumes Service offers backup capabilities, snapshot copies, and replication within Google Cloud.
Now, with all of these major hurdles to cloud application management swept aside by NetApp technology, they can focus on testing and deploying the app in production.
Luke Solved a Major Impediment to Cloud Migration for His Organization
Not only has Cloud Volumes Service allowed Luke to dramatically shorten the time required to get production up and running in the cloud for this particular application, but it’s also helped the organization standardize on their data strategy. Because of Luke’s cloud ardor, all of his company’s future applications migrations can be sped up, with a reliable plan to back them. There’s no more need to intensely manage the availability or performance of the unstructured data layer in the cloud.
Luke and Ted are now seen as thought leaders within their Cloud Center of Excellence team. They enabled their organization to advance their cloud-first mandate. Service reliability improved by about 30% relative to on-premises performance for their Confluence and JIRA applications.
They were able to run production applications in Google Cloud with high reliability and confidence and to standardize the process of migrating the unstructured data layer of other applications to the public cloud.