There are three cloud architectures – cloud ready, cloud agnostic, and cloud native – with most organizations ideally seeking a combination of all three, and a component of cloud native, for optimal cloud solutions.
Have you started to implement your cloud strategy yet? Are you confident you are realizing the full benefits of your existing cloud strategy? If you answered “no” to either question, you are not alone. According to Gartner, by 2025, 95% of digital workloads will be deployed on cloud native platforms (up from 30% in 2021).1 However, as of now, OutSystems reports that only 53% of tech leaders surveyed claim to know what cloud native means.2 O’Reilly recently published a report stating only 30% of the people they surveyed currently used cloud native features.3 In my opinion, you aren’t receiving full benefits from your cloud strategy unless you have optimized your cloud native spend.
To frame it up, there are three typical cloud architectures: cloud ready, cloud agnostic, and cloud native. The optimal solution for you may include some combination of all three and most likely will contain some component of cloud native to be considered optimal. To be sure we align on the terms, let me describe each of the three architectures.
Cloud ready workloads are workloads running in the cloud that weren’t necessarily originally designed for it. Rather, they are “cloud compatible” and typically result from a “lift and shift” deployment from an on-premises solution. Creating Virtual Machines (VM) in the cloud for computing and database workloads is an example of a cloud ready approach. This is the onramp for most companies to the cloud, but hopefully is just the beginning as running virtual machines in the cloud can be expensive, does not scale as easily as other solutions, and puts most of the responsibility on you to maintain the operating system through updates and patching.
Cloud agnostic architecture is designing cloud services that are portable between the cloud, on-premises, or hybrid. This is the holy grail for many organizations. They believe that if their cloud solutions are truly portable, this is the optimal solution for them. For some companies who dynamically port their workload from provider to provider based on cost, that may be true, but that’s not true for most companies. Containerization, Kubernetes, or Terraform are some of the many tools you can use to achieve this. The idea is to be able to move a container that contains your applications and/or data to other cloud providers without change by manipulating the configuration settings on the target providers. These configuration tools can provide scale, but the management of scaling the architecture is still mostly on you. A cloud agnostic approach may be more cost-effective than cloud compatible; however, it is certainly more expensive and challenging to maintain than a cloud native solution. You should determine if the benefits of “vendor lock-in” mean more to you than the freedom to port your workload with fewer changes.
Cloud native architecture is building and running applications to take advantage of the distributed, scalable architecture offered by the cloud delivery model. In this approach, whether you are hosted by Microsoft Azure or Amazon Web Services (AWS), you take advantage of the first-party tools provided by the vendor to host your workload. You must make a conscious decision at design time to architect your applications to use resources such as the provider’s managed database service, web application services, hosted functions, and service bus. Azure and AWS both have native tools for managing and sharing application containers. With cloud native, you presumably give up the ability to easily migrate away from the vendor’s platform in exchange for a lower cost, highly elastic, and possibly more secure solution.
Maintaining compliance/security in the cloud is a shared responsibility between you and the vendor. As you move more toward the managed, native features of a cloud provider, the work shifts more toward the provider to patch and upgrade components with no downtime, scale the solution, provide multi-region disaster recovery services, and maintain regulatory compliance. Ultimately, the responsibility of performance, reliability, and regulatory compliance lies with you, but the maintenance of each can become more manageable at scale using cloud native features.
“As you move more toward the managed, native features of a cloud provider, the work shifts more toward the provider to patch and upgrade components with no downtime, scale the solution, provide multi-region disaster recovery services, and maintain regulatory compliance.”
Besides the vendor lock-in concern, early adopters of cloud native architectures were also faced with limited feature sets and observability. When cloud providers are slow to create features that most companies need, you may need to use third-party tools to bridge the gap. The gap continues to close as major providers have matured their platforms over time. There is much parity between the major providers as the head-to-head competition for your business is stiff. However, you will find that you prefer the features of one provider over the other with time.
Observability is an example of a feature that has recently improved in cloud native workloads. When early adopters deployed their code using native functions, it was difficult to observe what was going on inside the running applications due to restricted access to the managed log files. Azure Monitor Logs/Log Analytics and AWS CloudWatch/CloudTrail have evolved to the place where developers can take advantage of the same robust features used by system administrators to monitor the platform. Developers can now output exceptions to centralized logs that can be searched for debugging purposes. First-party monitoring and alerting tools make this even more appealing.
In conclusion, I believe most organizations will utilize some combination of cloud ready, cloud agnostic, and cloud native architectures. I also believe that as cloud native features continue to evolve, organizations should be more proactive about utilizing them where it makes sense. The optimal approach will involve evaluating each use case and determining which architecture makes the most sense. For any new development, it is worth pausing to ask, “Is there a cloud native solution for this that would increase my speed to market, provide better performance and scale, reduce my costs, or make me more compliant?” If you need assistance determining how to optimize cloud native features in your cloud strategy, contact our Applications Team. We are happy to help!
1 Gartner Says Cloud Will Be the Centerpiece of New Digital Experiences by Gartner, November 2021
2 Cloud-Native Development: Ready or Not? by outsystems
3 55 Cloud Computing Statistics That Will Blow Your Mind (Updated 2023) by CloudZero
Think Digital. Embrace Clarity. Increase Advantage.
Written By:
Rob Wilson
Principal Consultant, Southeast Region
Applications Solutions Group
