As the multi-cloud strategy becomes more popular, it is critical to understand what cloud-agnostic companies lose by not going cloud-native.
When you’ve spent years managing your own hardware in your own data centers, it’s hard for a wary technology leader to commit to cloud-native architectures. Companies are often more comfortable dipping their toes in the water than taking the full plunge and keeping their options open by implementing a multi-cloud approach rather than cloud-native computing. Avoiding cloud-native apps is a mistake. If you go the multi-cloud route, you’re losing out on some of the most valuable benefits of the cloud-native architecture.
Cloud, Multi-Cloud, and Dealing with Trust Issues in Cloud-Native
Why do tech leaders find it so hard to commit to cloud-native architectures? Instead, many initially prefer muli-cloud approaches for several reasons:
1. If you design and build your software for others, you might worry about cannibalizing your business.
Many independent software vendors (ISVs) build versions of their software to run both locally and in the cloud, mainly because they are afraid of losing their existing on-premise customers. These customers don’t trust cloud-native due to a perceived lack of security. This lack of trust has been especially evident in financial companies and government agencies for whom data breaches are particularly damaging. But cloud providers have made significant advances on that front, offering most of the common security standards and compliance certifications.
For many ISVs, this duality sets up a classic innovator’s dilemma — whether to cater to their customers' current needs or to usher in innovations and new technologies to address future needs. Today, with all of the competition, it is crucial for software companies to disrupt themselves. By investing in new business innovation to compete, they’ll build a product that’s fundamentally more scalable.
2. If you run software to support your business, you might worry about sudden price hikes or vendor lock-in.
Many IT leaders in the process of transforming their organizations are also nervous about committing to cloud-native application vendors. They can be skeptical about betting on one vendor — e.g., Amazon Web Services (AWS) vs. Azure Cloud Computing (Azure) vs. Google Cloud Platform (GCP) — and sometimes IT buyers worry that cloud vendors will start to ask for more money or disappear in a year or two.
You may also be concerned that public cloud platforms are not specialized enough for your needs because they build data centers that accommodate all types of customers. Companies might also believe that they can build a more reliable data center than the major players, such as Amazon, with cloud-native technologies. These fears come with severe opportunity costs:
- Spending more time reinventing the wheel with custom code that will need ongoing maintenance.
- Missing out on new features of higher level services that vendors add over time for free.
- Overestimating the benefits gained by implementing a multi-cloud architecture, and underestimating the cost of the additional complexity.
It’s Not Cloud Lock-In, It’s Cloud Buy-In
1. Going multi-cloud reduces your volume (and leverage) with each vendor.
Logically, you’re in a better position to negotiate if you’re using more cloud-native volume. For example, AWS' Reserved Instances and Google's Committed Use Discounts both offer opportunities to minimize cloud costs by providing a particular service level for an agreed-upon period. Both service providers give respective discounts of up to 75 percent and 57 percent on pay-as-you-go prices, depending on contract length and — in the case of AWS — the amount of your upfront deposit. This discount is a big advantage of committing to a single public cloud vendor.
2. A cloud-native approach gets better and cheaper over time.
The more high-level, cloud-native services that you buy into, the more you stand to gain. Even now, the AWS key players are competing on margins, and the prices are dropping as services get cheaper to build and maintain. Additionally, vendors continue to improve their offerings, adding new features — like machine learning and natural language processing — at no cost to you.
3. Unless you're provocative or directly compete with vendors, avoid do-it-yourself.
If your content is controversial (Parler, WikiLeaks, 4chan, etc.) or you are one of the largest companies in the world, such as a direct competitor with Amazon, it may make sense to invest in cloud-agnostic or wholly-owned infrastructure. But for most companies, there’s really no reason to keep a physical data center. Instead, commit to the highest level, cloud-native services you can.
4. If you’re going to go cloud, go cloud-native.
Cloud infrastructure is not your core business, so you’re better off spending the majority of your valuable development time on building business logic and unique algorithms. This is especially true if you’re making ongoing investments in code.
By buying into the highest level, cloud-native services that a vendor offers, you’re effectively leveraging one of the biggest, most well-funded companies in the world to do development for you. Every year, you’ll benefit from their economies of scale as their services get better and cheaper without any additional effort from your team.
How To Take Advantage of Cloud-Native Services.
Refactor your application to replace your custom code with cloud services everywhere you can. Leverage custom code as the mortar rather than the bricks. The code that’s easiest to maintain is the code that you remove. And don’t worry about getting lost. AWS has tons of documentation on how to wire their services together.
Use the highest-level, most cloud-native services you can. This is going to give you the most bang for your buck. A good example is AWS QuickSight (which started as a kind of budget version of Tableau). It lets you easily develop and publish interactive dashboards. It was recently updated to do automatic Machine Learning-based forecasting and natural language processing (NLP)-based dashboard creation. These dashboards can be accessed from any device, and easily added to your portals, applications, and websites. These new features are “free” for customers already using the service.Take, for example, moving from a relational database to object and key-value storage.
- Drop-in: Run your existing database (ala OracleDB) directly in the cloud as a VM. You’re still responsible for administering the database and managing performance.
- Managed: Migrate to RDS and off-load the administration to AWS.
- Cloud-enabled: Use Amazon Aurora, an ACID-compliant relational database engine that offers a PostgreSQL-compatible version that’s also fully managed. It unites the reliability and speed of upscale commercial databases with the savings and ease of open-source databases. This is a drop-in compatible engine although the back-end storage is entirely different.
- Cloud-native: Use Amazon DynamoDB — a document and key-value database that gives you single-digit millisecond performance on any scale — for object storage. Amazon DynamoDB can handle more than 10 trillion requests per day. Using DynamoDB will require you to rewrite data storage for portions of your application, but you’ll gain enormous scalability.
Spend time on the business logic in your application. Spend less time building services that cloud vendors already provide and more time on your actual intellectual property, such as your patented algorithm. Develop custom rules and algorithms to manage the exchange of information between the user interface and your database.
Most importantly, don’t be afraid to invest in your business. It’s going to be crucial to your thriving and even staying afloat in the future.