Serving Cloud-Native (and Other) Applications

In a previous article I discussed considerations when ‘Thinking Cloud-Native’. I am switching gears in this article to talk about infrastructure attributes to consider to best serve Cloud-Native applications. This article is intended for those intending to evaluate their options for cloud native and general applications as well as business and IT executives interested in options beyond the older cloud first model.

Before I jump in, let's discuss this article by Niel Nickolaisen from issue 1.0 of the NEXT magazine, titled 'Decision Framework for Purpose Alignment’. Originally published a few years ago, the article is still relevant today. It covers how to handle functions by considering its strategic impact and criticality. Think of it as a framework to decide what to do with your applications. I always recommend they leverage this framework to customers as way to decide where to invest in transformation and innovation. Building your applications’ and innovation roadmap with options like outsourcing, retaining or maintaining, rehosting, replatforming, or rewriting are simplified using this multidimensional framework.??

Back to the intended topic of attributes, it is important for cloud and infrastructure teams to understand their importance and how various options stack up in serving the needs of Cloud-Native applications. The practice of finding the right fit for applications based on these attributes is a core tenet of a cloud smart approach, an evolution of the one-size fits all ‘cloud-first’ push the industry saw in 2010s.?

Here is the list of the top attributes to consider when evaluating where an application will be hosted.

• Application functionality, criticality, and users —decide whether to outsource, retain as is or invest — related to the article above.?
• Deployment model– as a container, a virtual machine, or on bare metal.
• Requirements for specific infrastructure and IT services–compute, GPU, storage, network, etc and services–data, network, security. The latter is especially important for cloud native apps.?
• Performance and capacity needs–current needs, utilization (sustained & periods of peak usage/bursts), and growth.
• Development and lifecycle considerations–collaborative & agile development,? streamlining development using continuous integration/continuous deployment.?
• Regulatory and compliance requirements–including access control, change management, logging, and more.?
• Upfront and ongoing costs considerations–funding for hosting, operations, maintenance,? and innovation.

There may be other considerations related to cloud native application. These attributes are universally applicable to both traditional and cloud native workloads. On the cloud and infrastructure side, organizations have choices as a function of these attributes. These choices will lead IT to the appropriate options for hosting and running their cloud native applications.

• Choice of Owning, renting/hosting, or a mix of both: There are plenty of reasons why you should consider renting vs owning. For example, how you want to organize your infrastructure spending – either as periodic operating expense payments or as capital expenditure. The latter would involve allocating capital or finance. Renting infrastructure as facilitated by service providers including hosted, managed, or cloud services providers enables consumption-based models. For many this aligned their infrastructure spending with their needs.?For example, hyperscalers and service providers may be able to burst up and down infrastructure and associated bill based on the needs. Now-a-days we are also seeing organizations using a combination of both owning some infrastructure or locking themselves into long term contracts for better pricing and renting infrastructure for areas like disaster recovery, bursting, development, etc. The choice of owning vs. renting is also made easy if the applications your teams are supporting are use services like DBaaS, IaaS, etc.? Attributes that can influence the choice of owning vs. renting include costs, application functionality (ex: maintain vs. innovate), and infrastructure and services requirements. Cloud-Native applications requiring access to IaaS and PaaS services can influence this choice.?
• Choice of Dedicated (private) or shared (public) infrastructure: This is coupled to the choice of owning or renting. Private clouds are defined as a setup where infrastructure is assigned to specific end users. There may be situations where a provider assigns their end users designated infrastructure from a pool, but that is the exception. On the flip side, public clouds are almost always based on shared infrastructure where multiple end-users share the same (multi-tenant capable) compute, storage, and networking resources. There is a common misconception that public clouds are only offered by the hyperscalers. Service providers can also deliver their own version of public cloud services.?Attributes that can influence the private vs. public debate include end-user's performance and capacity needs, regulatory and compliance requirements, infrastructure and services requirements, and costs. Access to services like DBaaS and network services like application load balancers etc are also relevant for cloud native applications.?
• Self managed vs 3rd party managed infrastructure: the last one from my list is for the most part related to private cloud. The core infrastructure comprising of compute (including virtualization and containers layers), data storage (VMs, containers, structured and unstructured data), networking (connectivity and services), and security (network, application, data etc) may be managed the end-users or by a 3rd party service provider/system integrator. In public cloud deployments, the management choice comes down to whether end-users consume basic infrastructure building blocks (example: VMs and containers, file services or buckets) or use native services and functions (functions and services like DBaaS). Attributes that can influence this choice include application functionality (ex: maintain vs. innovate), and infrastructure and services requirements. Cloud native applications tend to use a higher level of abstraction like Platform as a Service functions.

I believe this guidance can help guide platform engineers and cloud and infrastructure teams to make the right choices for their cloud native (& and other) workloads. In the next article in the series I'll discuss how the various infrastructure choices fare for cloud native applications. As always, keep your feedback and comments coming. How do you see your teams choosing infrastructure for cloud native applications.