Skip to main content

5 signs your cloud needs a refresh

If your cloud strategy hasn't reduced cost and complexity as much as you expect, a hybrid cloud strategy could be the solution you need.

Suppose your company has an on-premises infrastructure and a foothold in a cloud provider's infrastructure, but this cloud strategy hasn't reduced complexity and cost as much as you expected. If that's so, adopting a hybrid cloud strategy could be the solution you need.

[ Learn why it's important to keep the cloud open. ]

A hybrid cloud is a combination of at least two computing environments that share information and run a uniform series of applications. It could be a combination of private and public clouds, several private clouds or public clouds, or a virtual or bare-metal environment connected to a cloud.

5 signs that your cloud strategy isn't working

Here are five signs that your current (non-hybrid) cloud setup isn't serving you as well as it could.

1. Services appear everywhere

Are you getting more and more requests to integrate services into your environment? Are the projects requesting additional services as requirements for their applications? And are some of these services hosted as software-as-a-service and others on a yet-to-be-integrated cloud provider? Maybe some have special security requirements. Others need special hardware to optimize execution. And still others need proximity to data.

If that's what you're seeing, it probably indicates that a single cloud provider and an on-premises cloud aren't able to cope with the disparate requirements within your organization.

2. You have an ever-increasing number of clouds

You've noticed that the complexity of integrating and operating your environments has increased notably, even if you have just two environments, such as an on-premises infrastructure and one cloud. You have to deploy to two different environments, implement their different security constraints, and monitor them. And you have to implement those services for every platform.

[ Learn how to build a flexible foundation for your organization. Download An architect's guide to multicloud infrastructure. ]

3. Lock-in is rising

You seem to be more dependent on one cloud provider and feel you don't have enough options.  If your cloud provider's services are not available on other cloud platforms, it is difficult and expensive to move away from that infrastructure. This obstacle to moving away from your cloud provider often leads to increased unit costs.

4. Regulations are strengthening

You are in a regulated industry and the requirements for cloud platforms increase every year. Because your workload is deemed system-critical, your regulator says moving to the cloud requires extra governance. To test an exit strategy, you need at least two cloud providers able to deploy the required applications and access the needed data. This increases the complexity of developing and operating the application.

5. Costs are running wild

You received your first invoice from your cloud provider, and you don't believe what you see. Your cloud resource consumption is more expensive than you expected. Maybe your estimates for cloud infrastructure were invalid because the usage wasn't accurate. Or you might have a committed spend that forces you to consume where it isn't necessary.

[ Learn 5 ways architects can maximize committed cloud spend. ]

Secondary provider services could be the main factor for your infrastructure's cost. Data is the new gold, and it seems that getting your data out of the cloud is expensive. And running your instances 24/7 is more expensive than operating an on-premises environment at capacity. The high cost of data transport has led you to execute base-level load on the platform where your data is, rather than where execution is cheapest.

Integrating multiple clouds

It's clear that organizations need to be able to access and integrate more than one cloud. How can you solve the problem of integrating multiple clouds with multiple participants, multiple integration options, and multiple, diverse security requirements?

You could integrate each cloud infrastructure individually, especially if you integrate only one or two clouds. But the more clouds you need, the more cost-efficient a generalized framework becomes. This also reduces the need to integrate another cloud and another, and another, and so on as you grow. It also allows your organization to become more flexible in its deployment options, overcoming future challenges, and addressing your customers' dynamic needs.

This framework can provide generic deployment procedures where you need to address only specialized options for each cloud provider. Several parameters become easier. For example, it's easier to set a standard for all environments. You can enforce access control lists (ACLs) and access constraints, threat prevention, monitoring options, and more at a central point of interaction with all of your clouds.

Setting a standard makes it easier to consolidate direct interactions with the cloud provider's specific services, which otherwise could inhibit a dynamic move from one cloud to the other.

In addition, as development becomes more cumbersome in a cloud-native environment, such a framework can reduce complexity for the DevOps team. Your team can concentrate on implementing the business use case rather than on adhering to a platform's specific requirements.

[ Discover ways enterprise architects can map and implement modern IT strategy with a hybrid cloud strategy. ]

Two ways to simplify your cloud environment

Here are two ways to simplify your cloud environment.

1. Recognize that microservices are the future

When deploying into production, your focus will change from the complete application to the microservices it consists of. Your application and its set of services might require closeness to sensitive personal data, an artificial intelligence framework with an abundance of GPU-specific compute power, or integration with services supplied by partners. It definitely needs to be cost-efficient to develop and operate. 

A single cloud can't provide the environment for all of these requirements, so your application needs to span different clouds.  Because it can be complicated to choose and deploy the right cloud for a service, you may want to assign these tasks to a specialized team.

2. Consolidate interactions with cloud providers using a service deployment center

You can use a competence center to integrate different clouds, provide procedures, set up new environments, and establish standards and programming guidelines. But it does more than just interacting with cloud providers. Its focus is on providing environments where services can interact with each other, which makes it essentially a service deployment center (SDC).

In this setup, the DevOps team provides the necessary microservices, with either custom-built services or SaaS options. Then the SDC considers the service's requirements and overlaying application and decides where to place the service.

Those requirements can depend on many factors including data gravity, security requirements, estimated base and peak load, hardware constraints, latency, cost, and service level agreements. Because these factors aren't typical development team concerns, they are better addressed by a centralized competence center of platform engineers. These professionals are in a better place to implement an organization's cloud strategy.

[ Plan your next cloud project based on your current cloud results by asking these 4 essential cloud project questions. ]

Where does this lead?

Most companies can't—and shouldn't—concentrate all their workloads on a single cloud provider and should implement a hybrid cloud strategy instead. Yet when you branch out to multiple clouds, it's critical that they can interact with one another. A service deployment center helps overcome many of the challenges of implementing a hybrid cloud strategy, but the first step to success is to have a hybrid cloud strategy in the first place.

[ Get the Hybrid cloud strategy for dummies eBook. ]

Topics:   Cloud   Kubernetes  
Author’s photo

Axel Saß

Axel is a Chief Architect for Red Hat FSI in Germany. After obtaining his business administration degree in Kiel, Germany, Axel worked as a consultant for mainframe development strategy and tools. More about me

Navigate the shifting technology landscape. Read An architect's guide to multicloud infrastructure.


Privacy Statement