Elastifile has announced the availability of a fully managed scale-out file service for Google Cloud. This is more than just another marketplace offering. The company’s Cloud File Service is now fully integrated into the Google Cloud ecosystem. Storage is configured through GCP APIs and GUIs and billed by Google based on consumption. This is a coup for Elastifile and an indication of an increasingly competitive part of the public cloud market.
Although I’ve followed the company for some time, I haven’t really written about Elastifile’s Cloud File Service (ECFS) that much, so here’s some additional background. Essentially ECFS is a scale-out file system designed to run on all-flash storage. The company was founded in 2013 and brought their first GA release to market in Q4 2016. Since then, major versions have been released approximately annually, with version 3.0 announced in October 2018. The biggest enhancement in version 3 was ClearTier, a feature that allows data to be tiered to and from an object store without having to first “re-hydrate” the data back into an entire file system. This integrates with CloudConnect, the feature that tiers data to an object store.
You can find more on Elastifile in a number of Tech Field Day presentations. I’ve embedded the Google Cloud one from 2017 here.
Elastifile has been working with Google for some time. ECFS first ran on Google virtual instances in June 2017. An update followed in April 2018, making ECFS available through Google Cloud Launcher. So, clearly, the Google partnership has been developing over the years to culminate in an integrated service.
Why is being natively integrated so important? Well, the most obvious feature is the ability to use native APIs that integrate with other features that include security, automation and networking. Being a so-called ‘first class citizen’ is important, because the customer is buying a true service. Google and Elastifile support the operation and running of ECFS on behalf of the customer. This means scaling the infrastructure automatically and dealing with any failures. Second, this is a consumption billed service. Storage capacity is billed through Google and simply added to the Google bill, based on TB/month usage.
ECFS will sit alongside Google’s Cloud Filestore service. The differentiation between the two is in scalability; ECFS scales better with greater performance and capacity. This makes the service more appropriate for enterprise workloads, whereas Filestore is better suited to smaller deployments like home directories or local web content.
The third most important point here is that ECFS is a purely software-based solution. This means Google and Elastifile can deploy this solution anywhere in the world that runs the right virtual instances with appropriate block storage. Cloud service providers are already adept at pushing out daily or hourly software updates, so making ECFS available globally is (relatively) simple. This is a strong benefit compared to solutions that are highly hardware dependent, like cloud-adjacent solutions. It also removes the need to seed locations with hardware, as ECFS just uses existing local resources.
So, surely this is a win-win for customers, Google and Elastifile? Well, yes – and no. Let’s think about how this service is being delivered. The first challenge here is in managing back-end support. Moving from a direct customer model to one where the product is sold as SaaS means that demand could be huge in the coming months. How are Google and Elastifile positioned for this support requirement? Second, how easy will upgrades be to implement? Customers won’t tolerate any future downtime our outages, so new releases and features need to be implemented seamlessly. These will be the biggest issues for Elastifile for 2019 – dealing with scale. As a result, Elastifile has stated that initially, it will not offer SLAs on ECFS for Google Cloud (although this may come later).
One other point to address is the ability to natively replicate with other ECFS instances, such as those on premises. Although ECFS in Google Cloud will support external IP addresses, it isn’t clear (yet) how multiple ECFS deployments will be linked, other than via an intermediate object store with CloudConnect. This is one area I’ll be interested to see some clarity in.
The Architect’s View
The public and hybrid cloud storage market is heating up. NetApp was arguably first to this market, with Azure NetApp Files in 2017 and deployment in Google Cloud earlier this year. AWS made a slew of storage announcements at re:Invent just last month (which we will talk about separately). Traditional and start-up storage vendors are clamouring to be cloud-native, as data emerges as the centre of the hybrid cloud universe. Having a marketplace offering won’t be enough; native integration with APIs, security and networking will be the goal for the winners in this space. In this respect, Elastifile is onto a winner.
It’s not clear whether hyper-scalers will be keen to run multiple cloud storage offerings from different vendors at the same time. Obviously, we’re already in a position where that is happening, albeit with a mix of native and 3rd party solutions. I guess time will tell. Hybrid storage in 2019 is going to be an interesting place to watch!
Comments are always welcome; please read our Comments Policy first. If you have any related links of interest, please feel free to add them as a comment for consideration.
Copyright (c) 2009-2021 – Post #7AC8 – Chris M Evans, first published on http://blog.architecting.it, do not reproduce without permission.