In the complex world of cloud computing, insiders keep some secrets to themselves. It's in cloud service providers (CSP)'s best interests to hype and aggressively market some or their products' features while hiding certain aspects of other features.
Some of these mysterious features are logical and hide in plain sight. They may address architectural improvements or better processes that lead to better performance and security, which will usually lower costs. However, because those features are rarely publicized, enterprises often overlook them.
Unless there is an impending disaster on the horizon, many enterprises settle for the "good enough" solutions. Yes, those solutions might work, but it's frustrating to learn later that there was another one that was close to 100% optimized for lowest risk, highest value, and lowest overall costs.
Cloud operations, or CloudOps, which deals with cloud complexity, seem to be where most of these optimization secrets reside. This is because CloudOps is the long tail of the migration and refactoring process. It's also where cloud providers make their money in processing time, storage, data egress, and a list of other items that cause your monthly cloud bills to rise.
Operating something that is nearly 100% optimized versus something that is not even close can cost half as much money each month. Here are the CloudOps tricks and/or secrets that your cloud provider would rather you not know.
1. Use cross-cloud tools, even on just one cloud
If you implement a single cloud such as AWS, Google, or Microsoft, then leveraging cloud-native tooling for operations should be the logical choice. However, a few issues will soon become apparent:
- Over time, you will probably deploy other cloud brands with more processes and storage that move equally between those brands. It's almost a surety that you will become multi-cloud, planned or not.
- Cloud-native ops tools work best for the single cloud brand that they support. Some CSPs are moving toward monitoring and management compatibility with other cloud brands, but it's not in their best interests overall to play nicely with others.
Homogeneous cloud operations are inherently inefficient. Tools that work across cloud are typically a better choice. This means you should choose AIOps tools, monitoring and management tools, and security systems that can span clouds. They're a much better investment longer term, but more difficult and costly to implement.
2. Adopt SecOps that span all clouds and traditional systems
Leveraging security managers that span all your traditional systems and public clouds is three times more effective than following a cloud-native approach.
Similar to tip No. 1 above, cloud-native security systems operate best on their native cloud. Eventually you'll have silos of security systems, each solving tactical security problems for their native clouds. What you need is an overarching security ops platform that can manage security from cloud to cloud as well as for traditional systems, and perhaps with emerging technologies such as edge computing.
Again, this is about finding something "cross-cloud" that exists today, and to do that you'll have to look for third-party providers. If you don't choose cross-cloud security now, the move from cloud-native to cross-cloud security will happen when your security silos become too complex to maintain and the first breach occurs.
At that point, the transformation from cloud-native to cross-cloud security is difficult and costly.
3. Leverage cloud performance management outside of your public clouds
While this trick causes some debate from time to time, most experts agree: Abstracting public clouds for performance monitoring is a much better approach than just monitoring a single cloud using its cloud-native system.
Here's the issue: Systems will exist both on many clouds and on many traditional on-premises systems, many of which are loosely or tightly coupled. Latency on a single cloud-based system may affect other systems on other clouds and platforms.
You'll need observability across all systems, clouds, and platforms for performance to be truly understood using abstraction. Moreover, you need the ability to self-heal performance problems using automation.
4. Manage containers with third-party tools that operate outside of the clouds on which they run
It's a myth that containers are easy to run, especially containers that run under orchestration tools such as Kubernetes.
As we move toward federation of container-based systems (which means they will run across clouds, sometimes as a single application), the ability to manage heterogeneous systems becomes a problem. For example, containers operate differently on one brand of cloud than on another, or on an on-premises platform than on a cloud. When you add security and ops management to the list, the issues become more complex.
If you think you'll have containers running on a single cloud or non-cloud platform, you're dead wrong.
No matter how you approach container-based architecture and development today, you'll end up running containers all over the place tomorrow, even on IoT and edge-based devices. Find a heterogeneous ops solution now. You'll thank me in a few years.
5. Closely monitor and manage your serverless environment, and don't believe the hype
Many public cloud providers promote serverless technology as a concept that does not require as much management overhead as do other technologies. It's being promoted as a form of cloud-native development that's cheaper and requires no application resource provisioning planning. But this is wrong.
Serverless is about the cloud provider controlling the allocation and use of resources, such as storage and compute, to support a specific application function. However, unless serverless is closely monitored and managed, many enterprises discover that more operational complexity and surprise costs can plague serverless development and deployment.
Moreover, as you move to multi-cloud, you'll have to monitor serverless systems across cloud brands, since all vendors have or will have some sort of serverless offering.
Now that containers and databases are moving to serverless as well, it's a good time to get good at this skill. You'll also need to think about a single monitoring and ops tool that can see into all serverless development and deployment platforms.
6. Leverage third-party (non-native) cost governance tools to save up to 30%/year
Much as with the tricks listed above, you'll need the ability to monitor and govern costs across cloud brands. The costs are all interrelated from cloud to cloud, certainly as you build and deploy systems that are interdependent.
While there are cloud-specific tools to do these tasks, have you tried to run three of those tools at once? You'll quickly understand the need to leverage a non-native tool that supports all cloud platforms.
7. Application scalability is best managed using third-party non-native tools
Many consider public cloud scalability something that's cloud brand-specific. Certainly, all public clouds support auto-scaling, or advanced architectures that can scale to previously unimagined workloads.
Accept the reality that most applications will be multi-cloud now, or at some point in the future. Also, applications will run on different platforms and different clouds with some interdependency. You'll need to manage that cross-cloud scalability.
For instance, let's say that your user interface processing can automatically launch new compute instances as the number of users grows. However, a database that resides on another cloud supports that system, as well as 100 others. The database won't be able to keep up with the launch requests without managed cross-cloud scalability. Guess which application disappoints end users?
8. Lightweight multi-cloud cloud service brokering typically saves 50% in any given year
Best of breed is much better than "whatever works." The emerging best practice is to provide developers and architects with the choices they need for the optimal development platforms: database, AI systems, storage, etc. That means you must provide access to cloud services that exist on many clouds.
While this results in more complexity, and thus more ops risks and costs, the benefits far outweigh the downsides.
To do this effectively, you'll need some sort of cloud services brokering. This brokering app is where the developers (or others who need to leverage cloud services) go to find out what services are available and other important information, including costs, internal reviews, and even lists of what applications currently employ the services.
While they could go directly to the cloud providers, the brokering app allows those in ops to monitor where the services are being deployed and their usage, security, governance, and, most importantly, costs.
The best value of cross-cloud best of breed is that you do not limit innovation. For instance, forcing developers to leverage only the machine-learning tools that are native to a specific "approved" cloud platform may result in a less-than-optimal fit. This could result in a system that's not optimized for the requirements of the business and does not meet expectations.
These days, tech is typically the value of the business. In other words, technology has become the value that customers see—think Grubhub or Netflix. So any money saved by leveraging only a limited number of cloud providers, and thus cloud services, could reduce the value of the enterprise by 50% or more.
Consider how and why you build applications today. Limiting the innovators in the enterprise to a smaller window of available tools and technology could kill your business.
Watch the patterns
Common CloudOps patterns are emerging. Enterprises do best when given the ability to select approaches and tools that support a wide range of cloud services and when teams can choose clouds with the most effective approach and ops tool selection.
Better choices often mean fewer dollars for cloud providers and the continued commoditization of their on-demand services. So you won't hear about these secrets at their well-attended conferences or in their weekly blogs.
Instead of coming from the vendors, this emerging set of best practices comes from the rank-and-file cloud pros as they learn from their mistakes. The tricks listed above are true-life tested.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
