You know what is going on when somebody whitewashes a controversial subject or greenwashes an environmentally unsound service. They are tricking you. Cloudwashing is pretty much the same thing, but it can sometimes be harder to spot.
It is important to know cloudwashing when you see it. When a vendor tries to cloudwash a traditional, old application, passing it off as “cloud native” or “cloud enabled,” you need to call them on it. If you get fooled, you are putting part, if not all, of your cloud implementation at risk.
The benefits of using true cloud solutions are clear. You want to take advantage of all the benefits cloud offers – the flexible pricing, elastic usage, resilient storage, robust performance, geo-redundancy, connectivity, high availability and minimal maintenance that enterprises have come to expect from the cloud. Buy a cloudwashed solution, and you might get some of these benefits, but once the paint dries, you will be able to tell the difference.
The Telltale Signs of Cloudwashing
So, how do you know if you are being cloudwashed? Here are five signs that your vendor is trying to pull one over on you.
1. The vendor is extending the on-premises model to the cloud
You may hear a vendor make a blanket statement that the infrastructure you already have on-premises will work seamlessly in a new cloud. It is an enticing argument – if it is not broken, do not fix it. You are hoping for a light lift, and the vendor offers you a license that will support your existing solutions without doing anything else. Make sure you validate everything. Do not just accept their marketing person’s word for it. It might seem obvious, but many people simply do not ask the right questions.
2.The billing model does not support pay-as-you-go
Your consumption model should be tied to the number of resources or services you use on the platform. If you are pitched a service that charges a flat fee no matter how much you scale, you are being cloudwashed. As you turn down your cloud usage, you are going to want vendor costs to go down with it. As you scale up, your vendor costs should scale up proportionally. Your vendor should be able to present a billing model that scales up and down with your cloud usage.
3. The service has a classic licensing model
If your vendor claims its product is “cloud compatible,” with a user-based or CPU-based licensing model, beware. This is legacy thinking. Typically you will see this come through the procurement team when they say, “we already have a security product,” or “we already have a logging and monitoring product.” The procurement team will want to extend this, based on the vendor’s cloudwashed marketing material. Educate your procurement team about why you want a consumption-based model, going forward. Licensing-based or role-based models require that you fill up 100 percent of the licenses to get full value. You are paying in advance for software you may not use. That is completely counter to the pay-as-you-go model in cloud.
4. There is no multi-region or multi-zone architecture
Classic IT resiliency is done through a disaster recovery program that includes a number of support mechanisms that move data on and off premises. In the cloud, a well architected application will have cross-region and/or cross-zone architectures. If your vendor has not built out a multi-region or cross-zone architecture, and a failure occurs in either a region or zone, your partner’s platform will go down, no matter how much effort you may have put into your own application resiliency. If your partner has an operating model that includes monitoring, logging, security and scanning, having a multi-region architecture is critical. Your whole platform can crash, even though you have architected your application correctly. Validate the architecture to determine if it was built with high availability capability, and get the vendor to acknowledge that with documentation.
5. There is no evidence the platform is performing in highly available situations
Has the vendor’s platform been implemented in highly scalable or highly available situations? Vendors may try to skirt around this question. Make them show you. Make them name names. If you find out you are going to be the first on their list with a highly scalable or highly available situation, you know you are being cloudwashed. Ask their sales or support team for evidence that what you are doing has been done by them before.
The Benefits of Going Cloud Native
What do you look for in a cloud native partner? Several things.
It might seem obvious, but you want to make sure the platform being offered actually runs on the cloud. Validate that the platform itself was built to run on the infrastructure you have chosen: Azure, AWS or Google Cloud. That way, you will have consistency across the platform from a number of vantage points, including identity, security, monitoring, logging and all other features you and your partner want to use in common.
Make sure the solution was built with multi-region and/or cross-availability-zone architecture in mind. This is important because your vendor has planned for its own operations to scale. You know your vendor is here to stay. As problems happen in the cloud, you want to know your partner has taken the necessary steps to harden its platform on the cloud you have chosen as your home.
We have mentioned it several times, but it is worth doubling down on the concept that cloud models have to be consumption-based, and pay-as-you-go. If your vendor has built its business model on a pay-as-you-go structure, you know the whole company is set up to survive on that model. Having a licensing model changes the whole economic structure on which the company is built. Pay-as-you-go companies already have the business model set up to survive on a subscription basis.
Getting a true cloud native solution puts you on the path to success as you scale up your own cloud infrastructure. It removes surprises. You can grow exponentially without having to worry about your partner continuing to cloudwash you in the future. You are resilient and durable, because your app – and your partner’s app – were built in the cloud.
Cloud Native Partners of CTP
CTP’s best-of-breed ecosystem partners are part of a reference architecture and a proprietary deployment methodology built on IP and process, called Minimum Viable Cloud (MVC). An MVC is a production ready environment on AWS, Azure or Google Cloud Platform, that is ready to accept any enterprise application with all governance, security, automation and compliance controls in place. Some of our key partners include:
- Sumo Logic – Provides a cloud-based service for unified logging and metrics management for modern apps, by delivering real-time analytics and insights across on-premises and public cloud infrastructure environments.
- Dome9 – Delivers full visibility and control of security and compliance in AWS, Azure and Google Cloud Platform environments by minimizing attack surfaces and protecting against vulnerabilities, identity theft and data loss.
- HashiCorp – Enables enterprises to use consistent workflows to provision, secure, connect and run AWS, Azure and Google Cloud Cloud infrastructure for any application.
- Palo Alto Networks – Provides enterprises a Next-Generation Firewall (NGFW) and IDS/IPS services for all edge firewall requirements.
- Trend Micro – Reduces the maintenance and overhead associated with endpoint security support and operational function in hybrid cloud infrastructure environments with Deep Security and Deep Security Smart Check.
- New Relic – Delivers a Cloud Adoption Solution (CAS) for AWS that includes sample dashboards designed to help DevOps teams understand and analyze application dependencies and infrastructure resources associated with cloud migrations —and their business impact.