Reduced capital expenditures

The biggest initial benefit of getting on the cloud is saving money by reducing or eliminating future capital expenditures. Moving workloads to cloud-based hosting allows businesses to avoid spending precious money on new servers. You can shift your expenses away from paying for physical infrastructure, like purchasing new server hardware and replacing, upgrading, and expanding existing infrastructure for current applications and services, all substantial recurring capital expenses for on-premises (on-prem) datacenters. For every server uploaded to the cloud, disks and storage arrays can go with it.

Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and other cloud service providers (CSPs) advertise and deliver pay-as-you-go computing power and cloud services that accrue costs on an hourly basis. These cloud providers give you tools to budget and forecast the expenses over a week, month, or quarter. You can pay monthly for the computing, storage, and networking resources you have used during that billing period, rather than up-front.

Not paying up-front capital expenditures to onboard apps and services in the cloud is a big win. It is a refreshing shift to go from capital expenditures to operational expenditures. The savings can be significant. We’ll look at the trade-offs below.

Reduced operational expenditures

Another promise of cloud technologies is also financial: saving on operational expenditures. Many organizations expect to reduce or eliminate labor and maintenance costs by going to the cloud. The story seems straightforward.

I noted that moving to the cloud reduces future capital expense. How can that lead to reducing recurring costs? The three biggest annual operating expenses of running your own datacenters are power, staffing, and taxes. Power is the largest datacenter operational expenditure, at least 40% and sometimes as high as 80% of recurring costs. Fewer servers means less electricity, air conditioning, rack space, and network traffic. In many cases software license costs can be made month-to-month rather than annually or per major version every two or three years. Staffing datacenters account for 15% of operating expenditures. Some IT and DevOps teams divide their workers by specialty in horizontal layers. Others account for and manage the workload in vertical silos. However the IT teams are managed, you can shift these labor costs of operating and maintaining hardware and other physical infrastructure into what matters more to your business: the apps and services that are now running in the cloud.

Better security with less effort

Many businesses onboarding to the cloud believe that the cloud provider handles security, so they don’t need to. The cloud provider maintains firewalls, updates software, and delivers secure physical infrastructure and hosting platforms for the business’s apps and services. The cloud providers are vigilant about security. Thus, businesses migrating to the cloud often expect they will no longer need trained and experienced security staff. They assume that whatever their business data and intellectual property needs, a secure cloud means secure data.

CSPs make it quite clear in their training and documentation, however, that security is a shared responsibility. For example, Amazon notes that “Security and Compliance is a shared responsibility between AWS and the customer.” They distinguish between “Security of the Cloud” and “Security in the Cloud” (emphasis mine). Microsoft and Google make similar statements. They provide both standard and premium security options and automated “advisor” recommendations. They can be trusted to deliver on their stated security and compliance requirements and offers. But they make clear that the security of your apps and data is up to you, the cloud customer—yet enterprises often miss this crucial point. In the next sections, we’ll look at some of the reasons why.

A faster user experience

Developers expect fast response times from the apps they use to do their jobs. Their end users expect do, too: Many studies indicate that people expect near-instantaneous results from smartphones, tablets, computers, and the apps they run on them. For example, a 2019 Google survey indicated that “75% of smartphone users expect to get immediate information while using their smartphone.” Moving from aging on-premises infrastructure to the cloud means you can dodge the bottlenecks of sluggish outdated internal systems. So enterprises typically expect a faster user experience.

For example, Microsoft states, “Azure Cosmos DB is a fully managed NoSQL database service for modern app development with guaranteed single-digit millisecond response times and 99.999-percent availability backed by SLAs, automatic and instant scalability, and open source APIs for MongoDB and Cassandra. Enjoy fast writes and reads anywhere in the world with turnkey multi-master global distribution.”

A faster development and deployment experience

Enterprises expect quick times to market with new apps and new features in existing apps. We want development and deployment into the cloud to be rapid, agile, elastic, and blazingly fast. They can be, and some aspects of the benefits to app development times and solution delivery schedules can even be realized right away, with significant competitive and operational advantages. Most cloud vendors claim you can deploy to the cloud in minutes! An example from Google is a tutorial titled “Deploy a container to Cloud Run in 5 minutes.”

In the cloud, you’re not locked into versions of software that are two, three, or four years old. You always get the newest software. You can develop your own apps faster and deploy them faster. Your developers are not tied down by saturated on-prem IT infrastructure. They aren’t slowed down by time for IT to respond to change requests. The cloud is agile and breeds development and deployment agility, and faster time to market can mean more value for your customers sooner.

You do save money, but maybe not as much as you expect

Enterprises who go to the cloud do commonly save money—just not always as much as they expect. When you shift from capital to operational expenditures, you’re moving the expense to another column. And operational expenditures can be higher month-to-month because you’re not recouping a return on the investment you didn’t make in infrastructure.

Enterprises chasing cloud ROI often do not account for the costs of networking upgrades. Shifting servers and storage into the cloud can increase demands on the network. Each location where you do business needs network infrastructure. This usually includes Ethernet switches, WiFi access points, routers, DNS servers, DHCP servers, and network security appliances like firewalls and proxy servers.

This equipment cannot all simply go away or move to the cloud when you move your servers, storage, and apps. If you maintain offices, factories, or other work locations with client computers and mobile devices, you need to keep significant networking, depending on the size and capacity of each of your locations. And you need to keep it fast and reliable. Moving to the cloud may require increasing future investments in networking. We’ll revisit this in a bit when we return to the topic of latency.

Your security can be better, but it’s definitely more complicated

Security in the cloud can be better; it can also be worse. But it is certainly more complicated.

Although CSPs make clear that cloud security and compliance follow a shared responsibility model, many organizations miss the message. Let’s spell it out here. CSPs are responsible for security of the cloud hosting infrastructure. Customers—you—are responsible for the security of apps and data hosted in the cloud. That “of the cloud” vs. “in the cloud” distinction might not be clear at first. Here is a metaphor. The landlord of an apartment complex is responsible for providing a solid foundation, walls, and roof. The landlord is like the CSP. The renter is responsible for renter’s insurance, locking their door, and not putting valuable objects on their window sills. Like the renter of an apartment, the cloud customer is responsible for their security in the rented space. That relationship might not be initially clear.

A common reason enterprises don’t know about or understand the shared security responsibility model is related to who makes the decisions about onboarding to the cloud versus who actually reads the fine print provided in the CSP documentation. Many organizations decide to go to the cloud prior to reading all the documentation. They expect that the IT staff—the technologists—will figure out the technical details. Some of those IT staff may be lucky enough to attend cloud training before their cloud deployments.One of those “fine print” details covered in cloud training is the shared responsibility model for security and compliance. Many students in cloud training classes are surprised to learn that security is a shared responsibility.

This is an honest mistake. Organizations who have been operating on-premises are so used to owning their IT infrastructure, they aren’t used to thinking in a landlord-renter model. To make matters more complicated and frustrating, many organizations don’t send some of their IT staff to cloud training until during or after cloud deployments are already under way (or after they have failed).

You can experience increased latency

Onboarding apps to the cloud can sometimes result in lower performance, including increased latency.

Again, network communications aren’t instantaneous. Latency can reduce cloud benefits in several ways. It all comes down to geographical separation. The further messages have to go, the longer it takes. This is true of both networking and storage.

Imagine you have an office in Saint Louis, Missouri. As a baseline, assume that the network latency to an on-premises web server in your office might be one millisecond. What does moving to the cloud change? Figure X shows a map with approximate distances to eight Microsoft Azure cloud datacenters in the United States. The distance from your office to either of the two closest Azure regions in Chicago and Des Moines is about equal. If you host a web site in either of those regions, you are adding about a hundredth of a second (10 milliseconds) network delay just due to the network factors.

If you instead chose to host your web app in the Azure regions in Texas, Wyoming, or Virginia, the network lag would be about three times as long. Farther still, the network delay to Azure regions in California or Washington state is double that. Adding 10, 30, or 60 milliseconds to every operation might not sound like much. But if each page in your web app needs to do 75 requests (a typical http request count per page), you can multiply the latency for one request and realize that your users in Saint Louis can notice the difference.

Consider an organization, Gateway Lou in Saint Louis, whose IT investments have been tuned by trained IT staff who kept tight physical control over networking, servers, and storage. Assume they also have maintained precision control over client device connectivity to all of that on-premises. That investment is massive. If they now move some or nearly all resources to the cloud, they’re decreasing their ROI. Latency costs at every hop.

A typical three-tier application makes four “hops”: from client computer/device to front-end server farm, front-end to middle tier, mid-tier to back-end cluster, and back-end to storage array. Figure Y shows these connections between app components. As you move some parts of the system to the cloud, you change the latency. Maybe you move the front-end and middle-tier to the cloud and keep the back-end tier and storage on-premises due to stringent data residency requirements. This can cause more than just sluggish systems: it can cause erratic behavior or even outright failure. Latency is evil. But it can be managed.

Your old hardware won’t disappear overnight

Servers can be sticky. Yes, you can migrate many servers to the cloud. (Later in the book, we’ll get into the realities and tradeoffs of serverless computing.) But many businesses need to keep some servers on-prem in offices and datacenters. For example, some file servers may need to stay on premises due to data residency and security requirements. You might need to maintain caching servers and proxies.

Special hardware requirements on some servers may fall into a similar category—they cannot be moved to the cloud as-is. You may also choose to use disaster recovery or fault tolerant mechanisms which are not purely cloud-based, but retain some on-prem systems as a safety net you can physically control.

Two particularly persistent kinds of on-prem servers are those that host your virtualization fabrics and network infrastructures. Just because you have migrated some application servers to the cloud does not mean you can abandon your virtualization host servers. As long as some servers are running as virtual machines on prem, you need to maintain your clusters of clusters of virtualization hosts. This includes the hypervisors, such as VMware ESXi, Microsoft Hyper-V, and Citrix XenServer. The associated host management servers, such as vCenter, also need to be kept.

Some critical network infrastructure components that are best kept on-prem include DNS and DHCP. These could be hosted on physical servers, virtual machines, or embedded as features of network appliances. Demands on network equipment switches and routers might often increase with integration to the cloud. Depending on how you connect your on-prem sites to the cloud, you may need to upgrade your VPN services.

Legacy apps and processes can hold you back

Attachment is the cause of all suffering. Clinging to the processes you were used to under your legacy on-premises systems administration can hinder your ability to realize the cloud’s rewards.

To realize those rapid, agile, elastic, and blazingly fast speeds, you’ll need to update your processes and invest significant time and money in training. Working in the cloud is different than working in on-premises computing systems. Your development teams and IT staff need to become experienced with the new ways of doing things. One possible casualty of moving services to the cloud is security. Some organizations have moved to the cloud then realized they have exposed their apps and data. Failure to adequately comprehend and utilize cloud security options can introduce risks. Another issue is that legacy apps are quite often inflexible monolithic implementations of non-cloud-aware designs. This commonly leads to poor choices for scalability. This is one of many ways cloud migration prior to cloud understanding can result in worse performance and increased costs.

It is essential for app and solution developers to embrace cloud methods and best practices to ensure cloud success. Systems architects and engineers are also responsible for designing and implementing appropriate cloud strategies. But end user awareness can also make a significant impact on success. Both employees and customers who use your cloud-deployed can benefit from at least a basic degree of cloud awareness. The more everyone in your organization learns about the differences of the cloud, the more gains you can get.

Similarly, just lifting servers and storage from on-premises hosting and shifting them into the cloud (commonly called “lift-and-shift”) will not solve another related problem: old apps. Retaining outdated apps and services can block your returns on investment in infrastructure.

Many best practices for the cloud are rooted in recommendations for distributed and event-driven systems some software engineers and solutions architects have been recommending since the 1980s. Running apps that were developed in the early 2000s or follow 1990s designs that don’t follow cloud design patterns can significantly limit your ability to reap rewards from the cloud.

Inelastic metrics and budgets can stifle agility

Responsiveness to customer feedback is essential to modern and cloud solutions. Two aspects of how businesses traditionally manage IT operations can interfere with realizing potential cloud benefits: traditional metrics and budgets.

Traditional funding models are too often based on annual budgets, which are designed for slow “waterfall” development practices. Up-front funding worked for capital expenditures associated with on-prem equipment acquisition and long-term staff allocations. Old-school time reporting is used to distinguish how staff time relates to capital and operational budget goals set months or years in the past. But the rigidity of quarterly and annual budget pre-allocations lead businesses to resist responding to necessary feedback with short two-week scrum sprints or tight kanban-driven tasks.

Project-based, failure-intolerant, one-size-fits-all budgets do not align with the tight timeframes of agile development processes. This mismatch stifles the customer feedback needed to schedule weekly changes necessary to build agile solutions for modern business. But it is not just the timeframes of project funding that limits achieving ample rewards from the cloud. Businesses commonly use the wrong metrics to measure success against those budgets.

Success in IT is typically measured in terms of technical effort and/or technical rewards. Measuring technical inputs and outputs can be deceptive and misleading in any systems. Relying on such metrics of IT performance can be especially ineffective with modern DevOps solutions. Measuring IT inputs and outputs are focused on the wrong goals: technology for its own sake.

For example, organizations often measure success in cloud migration projects based on the number of virtual machines moved to cloud hosting. But that doesn’t reflect true business value. Metrics such as mean time to recovery, number of transactions processed, and number of developers trained in agile processes are just as much an illusion of success. These metrics measure inputs and outputs of IT, not true business value.

Your overall ROI is lower than expected

Overall, the realities of the cloud can surprise businesses who had unrealistic expectations of the cloud. Surprises equate to risk. We want a predictable path to cloud onboarding.

In summary, here are some of the factors that lead to lower ROI than expected when moving to the cloud:

• Cloud resources are accessed by clients across the public Internet or private on-prem to cloud provider networks. Therefore, smooth-running networks are essential to cloud successes.

• Not accounting for network upgrade costs can lower ROI. In addition, some servers may need to be kept on-prem.

• Depending on your cloud strategy, a hybrid design with cloud-based services and some on-prem servers may be required. If you had hoped to eliminate all on-prem servers, your actual ROI could be less than expected.

• Clinging to legacy systems administration processes can reduce your ROI.

• Finally, sticking with traditional annual budgets and chasing technology for its own sake will not serve to significantly increase your returns on cloud investment.

Set realistic expectations

Cloud technologies are not radically more complicated than the technologies used in on-premises datacenters. CSPs are companies that can deliver small or massive amounts of compute power and storage on demand. You can choose what apps and data you want to outsource into cloud hosting. You can choose to go with one cloud provider or multiple cloud providers. You can also choose to retain certain data and services in your own local networks. That’s the basic equation. We’ll get into details later. The key is that you have choices.

Successfully using the cloud comes down to setting realistic expectations, choosing the ways you use the cloud, and following through with your plan. Realistic expectations need to include considerations for avoiding bad choices that could limit your ROI.

Keep in mind that network upgrades may be required. This is because cloud services are accessed over the network. That could include public Internet connections and private connections to your chosen cloud providers. Don’t assume that eliminating all on-premises systems is the best approach: hybrid designs might serve your business better.

The dynamics of using cloud services are different than those of consuming on-prem resources. Be willing to let go of legacy applications and outdated administrative practices. Using modern software development and systems administration patterns and practices can increase your ROI. Accepting these adjustments to your expectations can reduce risk and increase your success.

Understand shared responsibility

Cloud services are provided within a shared responsibility framework. Your success is dependent on your understanding of what you are responsible for and what you can depend on the cloud providers to deliver.

One critical example is security. CSPs are responsible for the security of their physical infrastructure. This includes their physical datacenters, redundant networking, durable storage, and resilient virtualization fabric. That’s the secure foundation of the cloud. But you are responsible for the security of your data and apps that are hosted on top of that foundation. The major CSPs offer tools and options to help you uphold your end of that bargain.

Another essential ingredient in the shared responsibility model is operating expenses. Again, the CSPs are responsible for paying for their real estate, physical hardware, electricity, air conditioning, and staff. As a cloud subscriber, you are responsible for paying them for the on-demand resources you allocate and consume. If you allocate a rigid virtual machine instance that is running 24 hours a day, thirty-one days a month (744 hours/month), you pay for that. If, however, you choose a dynamic consumption model service that only runs as needed, you pay just for what you use.

The choice is yours for each and every app you host in the cloud. Choose wisely. Your ROI will thank you.

Understand the outlays

Can your business realistically on-board services to the cloud with zero up-front investment? Not likely.

While it is true that you can reduce or nearly eliminate future capital expenditures for new servers and storage, you might choose to keep some on-prem. They might need upgrades. More likely is network upgrades. Most of the expenses are month-to-month. By onboarding to the cloud, you trade some capital expenses for operational expenditures. However, if you simply lift and shift a virtual machine that runs 744 hours a month, you do not reduce those operational expenses as much as you could. That’s because simple virtual machine allocations are rigid—there’s no elasticity.

Both training and process updates require outlays of time and money. To best benefit from the cloud, you must embrace change. The learning curve may seem steep. It might appear expensive. But now is the time to invest in training your developers and IT staff on modern software and cloud technologies. The returns should continue many decades into the future, even as technologies evolve and improve.

Where is the greater value and greater ROI in the cloud? The secret to that is using on-demand elastic allocations of services in the cloud. That allows you to pay for what you use. If you choose highly-elastic scalable hosting platforms in the cloud, your monthly outlays are less. You save more. But it might require some app redesign and redevelopment.

If you invest in deeper redesign of your applications and services to use modern cloud practices, you can even go a step further—serverless. Think of this as ultra-elasticity. Then you truly pay for what you need and can potentially save significantly more than the highly elastic choice.

Embrace elastic budgets and modern metrics

Agile development and elastic deployments can serve businesses well. But annual and even quarterly allocations of funding can limit realization of potential gains. Development processes that are focused on customer input offer the best rewards from scrum sprints and short-lived kanban work. Budgets need to adapt to changing needs identified any given week, continuously throughout each year.

Incorporation of customer feedback is essential to modern and cloud solution success. Responding to trending and viral success as swiftly as possible, by scaling deployments immediately, can help you achieve some of the true promise of the cloud. Ramping up teams on trending innovative features for the next two week sprint enables your organization to reap the rewards when they are still relevant. Embracing elasticity in your DevOps operations requires elastic budgeting.

Business success is achievable and your organization can realize it. But measuring technical inputs and outputs as if they are business success is barking up the wrong cloud. Your organization can realize success by goal-setting and continuously monitoring real business outcomes: based on driving value for your customers. Operational maturity of businesses seeking rewards from the cloud and other modern digital technologies is measured in business outcomes.

Improvements in customer satisfaction and increased engagement can both drive growth in revenue. Empowering developers to be able to respond quickly to features relevant to your customers is the key to success. This doesn’t mean letting your developers go wild and develop without constraints or discipline. Security, compliance, and stability are essential ingredients that must be baked into any solution. Customers do not just want you to deliver speedy systems or the fastest speed to market. They want trustable, reliable solutions. Align your metrics for success based on what customers really need and want, and you can serve them well.