CEO Guide to the Public Cloud

What is the Public Cloud?

As we’ve pointed out previously, “the cloud” has too many and often conflicting definitions. Similarly, “public cloud” is often both over- and misused. For our purposes, we use the term public cloud to mean infrastructure as a service (IaaS) from providers such as Amazon’s AWS, Microsoft’s Azure and Google’s GCP. Public cloud is also often extended to mean “platform as a service” – solutions that are sold on top of compute infrastructure such as applications (databases, web servers, etc) to reduce the need for the user to maintain various components.

True public clouds have the following attributes:

• On-demand compute infrastructure (think computers and storage) owned by a third party and that is rented or leased to a company like yours.
• Compute resources are multi-tenant, meaning that multiple users (or companies like yours) will share physical hardware.
• The shared physical hardware is partitioned or “walled off” between tenants using “virtualization” software.
• Access to compute resources is provided over the public internet – the same shared global infrastructure you use to access various sites from home and work.
• Access is open to virtually anyone who can pay for usage, and to virtually anyone who might want to interact with the products and services hosted by the public cloud provider.

Most public clouds (but not all) have the following National Institute of Standards and Technology (NIST) capabilities and attributes:

• On Demand Self-service – you, as a user of the infrastructure service, can provision compute resources yourself through an interface that allows you to configure the:

• size (number of processors, memory, storage, etc)
• type of server operating system and/or hardware (Windows, Linux, etc)
• paid or open-source applications running on the service, such as a database, etc.

• Elasticity – resources can be provisioned and retired on demand, or even done in an automated fashion as demand increases and decreases. This is often called “horizontal scaling” (adding more components).
• Measured service – system resources are monitored and controlled and if necessary metered to optimize the multi-tenant environment.

Contrast this with the attributes of a “private cloud”:

• Offered over either the public internet or a private internet (such as an internal corporate network)
• Almost always single tenant – meaning that your solutions will be the only one on the compute infrastructure you employ.
• Available typically only to you for maintaining – but the applications/services running on it may be made available for usage to everyone or just a few people (such as your company or segments of your company).

Why is the Public Cloud Important?

The public cloud offers multiple potential benefits for users/buyers of public cloud services including:

1. Faster time to market

   Unlike the case of self-hosting services in your own datacenter, or within a colocation facility, and unlike working through a managed service provider you need not order equipment in advance, rack it, power it on, and connect it to the internet. Lead times for provisioning new services or extending existing services (horizontal scale) therefore are faster. That means you can launch something when you are done ensuring it has the appropriate quality and you need not worry about equipment lead times or coordination between teams to install equipment.

2. Lower provider (hosting partner) business risk.

   Because demand is rapidly shifting to the public cloud, colocation providers often find themselves struggling to remain profitable. The primary providers of public cloud services are all financially stable entities generating significant profits. The risk of a service provider going out of business and impacting your business is significantly lower within the public cloud.

3. Faster response time (lower latency)

   The three largest public cloud providers operate in multiple locations within the United States and multiple countries globally. This means that you can put your product close to your customer and reduce the customer perceived response times of the solutions you create. Further, it reduces the friction of international expansion of your products and services by having a partner with whom you work in most any region from which you want to operate.

4. Fewer skills necessary to be successful.

   Whether you are a sub scale startup, fast growing scale up, SMB, SME or large enterprise, leveraging a public cloud can reduce the number of skills and therefore people you need within your combined product team to be successful. Systems administration tasks are handled largely by the cloud provider, as are the needs for patching most servers and equipment. You will still need people knowledgeable about these domains, but you don’t need as many of them on your staff. Successful public cloud implementations require fewer skills and people on staff to bring a product to market. Note – this does NOT necessarily mean that your costs go down – we address that under key points below.

5. Less infrastructure technical debt/end of life concerns

   Put simply, many of the housekeeping items necessary to run your compute operations are handled by the public cloud provider. That list of things that your CTO or VP of Operations always complains about like refreshing your aging computer infrastructure or patching operating systems is now handled by the provider. Let’s face it, your teams never had time to do it anyway because they were trying to push out new solutions to expand your TAM penetration.

6. Scalability and Elasticity

   If, and only if, you are properly architected you can have near limitless “on demand” scale. And if you make proper use of public cloud elasticity such scale can happen within minutes of you needing it rather than the days, weeks or COVID-era months waiting for new computers to handle the new demand. Be very careful with this however, as the key phrase is “properly architected”. No matter how great your team is, it’s always wise to get a third party to evaluate and validate your overall approach to make sure you are maximizing the benefits of elasticity.

7. Opex vs. Capex

   Your CFO will likely love the fact that your asset ledger will shrink significantly. This doesn’t necessarily mean that your overall costs will go down – it means that you are renting servers (or “capacity”) rather than owning them. You shouldn’t need to worry about amortization schedules, etc. Just pay your cloud provider bill and you are done.

Key Points for CEOs and Board Members

1. Align on a definition of cloud and use it consistently.

   Make sure there is one definition of public cloud, and that everyone knows what it is and is using it consistently. A failure to do so will foment conflict within your team. It’s a small thing to do – but one that is often overlooked. And when it is overlooked, it is often a point of friction and sometimes a reason for failure with public cloud implementations.

2. The public cloud requires investment to achieve appropriate availability.

   The public cloud is a public swimming pool and while lifeguards are present, they can’t be everywhere at once policing everyone’s children. There are many other users of the servers upon which your product resides. Unlike the case of self-hosting your solution, poorly constructed services from other companies and poorly behaving users of those services can all harm your operations. Commonly caused the “noisy neighbor effect”, these interactions can cause availability problems and slowness in the solutions your provide to your customers. It is imperative that your engineering team architect to try to isolate faults to offset the effect of noisy neighbors.

3. The public cloud requires investment to be cost neutral or to lower your overall costs.

   Unlike self-hosting your solution, there is now one or more entities providing services for your compute assets. Further, these providers expect to make margin on the compute resources they are reselling to you. While the probability is high that the providers have greater leverage in negotiating cheaper compute resources, and even accounting for high asset utilization resulting from higher tenancy levels, most companies find that porting their existing solutions to the public cloud results in higher overall expenses.

   The trick is to ensure that you invest appropriately to maximize the leverage offered by the elasticity of the public cloud. Your service footprint needs to be able to expand and contract relative to the demand placed on it. Doing so will often result in equivalent costs and potentially even lower costs once you account for staff reduction.

4. You may not have a choice for very long – you may have to go to the public cloud.

   As we’ve mentioned earlier, while not dead the colocation industry is shrinking. Even with increased demand overall for service providers, the public cloud providers are stealing market share on both a relative and absolute basis from colocation providers. While there are likely to be providers for quite some time, as the colocation industry shrinsk and consolidates we can expect prices to rise over time. At some point, it may even become difficult to find providers in the geographies in which you operate. https://akfpartners.com/growth-blog/is-the-co-location-industry-dying

5. Owning data centers is expensive – and you likely can’t do it well.

   Owning and operating a data center is a costly endeavor and should really only be considered by hyperscale, large enterprises. Even then, the effort necessary to keep these beasts current and the risk it presents to the enterprise is significant. While very large-scale companies can absolutely be more profitable by managing their own data centers, the risks and heartache often are not worth the small benefits to profitability.

6. The public cloud enables greater ownership by engineers.

   Famous researchers, theorists and authors Jim Collins and Peter Drucker have both indicated a commonality amongst failed companies is “distance from the customer”. Assuming you have the right processes in place, the ease of self service in the public cloud enables your engineers to be closer to the operations of the solutions they produce. This in turn can bring them closer to the customer by better understanding the failures (bugs, defects, etc) that customers experience. You don’t get this closeness for free, it requires changing the ways in which we work from on-premises self-hosted solutions often run by an operations team to public cloud hosted solutions maintained by the teams that produce your solutions. But the benefits of doing so are enormous.

7. Remember to remove or shift your headcount

   To minimize total costs, you should either reduce your headcount, by reducing the total number of people you have who now maintain the hardware upon which your services run or shifting that budget to engineering to further increase your capacity and delivery velocity. Failing to do so will likely cause two problems:

   1. Organizational conflict: One organization that now has less to do will no doubt continue to demand that the old processes that supported their employment stay in place. This will in turn keep you from benefiting from increased engineering ownership and will in fact eliminate the time to market benefit the public cloud offers.
   2. Costs: In order to remain cost neutral, we need to eliminate costs (remember the service providers are charging MORE) or shift those costs to create additional value. Failure to do so will almost certainly result in margin destruction.

8. Moving takes time, money and must be managed

   There’s nothing magic about moving to the public cloud; you can’t flip a switch and be there overnight. It takes:

   1. time to migrate services to the cloud. The movement has significant risk and must be managed and architected well to reduce that risk of movement.
   2. Investment to have a successful cloud-ready architecture. If your movement does not envision resources to architect to offset noisy neighbors and leverage elasticity you will not be happy with your results.

Common CEO questions about the Public Cloud

1. What is “Cloud Native” and does it matter?

   This frankly is an over used marketing term. Marketing teams position themselves as “cloud native” typically to indicate that they are differentiated from other competitors that weren’t “born in the cloud”.

   That said, the term has some value if it is focused on describing product attributes that leverage the benefits the public cloud has to offer, specifically:

   • Built to recognize the noisy neighbor problems in the cloud vis-à-vis appropriate fault isolation to offset the impact of lower availability within the cloud.
   • Built to leverage the elasticity of the cloud – especially in an automated way.
   • Built to be multi-tenant, thereby increasing the asset utilization of the compute resources that you rent.
   • Built to be appropriately monitored to identify faults and issues early such that you can limit the impact of failures.
   • Built for maximum possible speed to market, including ensuring that engineers can release directly into production with high quality through extensive automated testing.

2. What does PaaS mean and should we use it?

   Platform as a Service (PaaS) are bundled application and infrastructure components you can purchase in the cloud to fulfill your architectural needs. Contrast these with Infrastructure as a Service (IaaS), where you are only purchasing the compute resources or potentially an application resource that you must manage yourself.

   When purchasing at the IaaS level, you would first purchase an instance of compute (cpu, memory, storage, etc) and then purchase or self-install an application upon which you build your solution (e.g. database, application server, web server, etc).

   When purchasing at the PaaS level, these components are “bundled” and some of the maintenance activities are included within the price. For instance, you can purchase a PaaS database (e.g. Amazon Aurora) that includes the compute, storage, and database components. In return, Amazon manages the compute and database componentry thereby further reducing your maintenance overhead.

   The trade-offs of such a purchase tends to be lower flexibility in usage and a higher cost relative to purchasing the components individually. In return, you receive lower time commitments from your team for managing the assets themselves.

3. Will my costs to operate my solution go down in the public cloud?

   If you heed our advice and ensure your team builds to leverage the capabilities of the public cloud and you remove unnecessary skills and/or reorient that budget to development, then you stand a good chance of being cost neutral or reducing your costs. Further, you’ll gain several benefits as indicated above.

   If you do nothing and migrate to the public cloud, you will likely see a significant increase in costs overall. Remember – you will likely need to invest money to move to the cloud at similar or lower costs.

4. Will my service availability be impacted in the public cloud?

   If you properly invest to ensure that you have a highly available and fault isolated solution, you should be able to meet or exceed your current service availability. If you do not invest and engineer to offset the noisy neighbor effect, your availability will almost certainly decline.

5. Will the public cloud impact the security of my product?

   The public cloud will not negatively affect the security of your product. Many CISOs believe that the public cloud is less secure, but there is simply no evidence to support this claim. If anything, the data centers in which your solutions will be housed are likely physically more secure than the one in which you reside now. Your approach to architecture determines your overall security posture more than where you are hosted.

6. Do I have the right team and skills to migrate to the public cloud?

   This can really only be answered by having someone evaluate your team in order to determine if they have the right mindset, skills and experience to be successful. But if you haven’t ever operated in the public cloud, your current team likely needs to be augmented with the skills and experience of people who have operated successfully in the public cloud.

7. What is a Hybrid Cloud?

   This is more marketing speak, but generally a “hybrid cloud” consists of one or more elements of a public cloud, private cloud and traditional (on-premises or colocation based) hosting. Often hybrid cloud implementations are pathways to full public cloud implementations.

8. What processes need to change in my company and the engineering team to be successful?

   Changes necessary to be successful in the public cloud closely mirror those of transitioning from packaged software to selling your software as a service (SaaS). The following should all happen to maximize the benefit of the public cloud:

   • Architect for high availability to offset the noisy neighbor effect of the cloud
   • Architect to leverage elasticity
   • Extensively leverage automation for deployments to reduce time to market
   • Extensively leverage automated tests to increase quality
   • Increase release frequency and reduce release sizes to lower impact and decrease time to market
   • Architect to ensure that everything – including business metrics – are monitored in real time

9. How do you measure the benefit of time to market in the cloud?

   The best way to measure of time to market (the dependent variable, lagging indicator or business value we expect to achieve) is to use the independent variable of “velocity”. Velocity is an “earned value” concept within Agile methodologies that measures throughput within a team. Ideally, as you move to easier methods of product delivery (i.e. the public cloud), team velocity should improve. As velocity improves, time to market should decrease. Other metrics to monitor include:

   • deployment frequency (or period between deployments) with more frequent and lower period always being better
   • time from software completion to deployment (which obviously impacts time to value creation)
10. What is multi-cloud and should we consider it?

    Generally, "multi-cloud" means operating within multiple IaaS providers (e.g. Amazon AWS, Google GCP, Microsoft Azure). We highly recommend this for very large, multi-billion USD revenue companies to help create a BATNA (best alternative to a negotiated agreement) to provide negotiation leverage between the providers and to manage risk associated with a single provider. But for smaller companies (sub $1Bn USD in revenue), the dilution of focus and cost to be multi-provider often isn't worth the implied benefits.

What the Public Cloud is NOT

The public cloud is NOT a fix for availability or scalability. Absent significant investment in your solution to make it fault tolerant, the public cloud can in fact decrease availability. Absent similar work to enable the ability to scale “on demand”, the public cloud offers nothing for your scale needs.