The Three Types of Cloud Infrastructure

In the cloud, everything has a cost. One small tweak in your cloud configuration here can cause a massive butterfly effect on your cloud bill down the line. For example, let's say you decided to switch to cheaper VCPUs and as a result your app loading times increase drastically, leading to a Twitter dog pile up and a PR nightmare for your company. Or on the other hand, maybe you save millions by switching to a serverless architecture, allowing you to scale indefinitely to account for any increased demand on your booking portal. To balance cloud computing costs, service levels and innovation speed, organizations, engineering, IT finance and development teams get together behind closed boardroom doors to discuss, debate and test these different cloud and app architecture strategies to see which is best and most cost efficient for their enterprise. These architecture flavors are known as Cloud Enabled Cloud, Native Cloud and Cloud Agnostic. Let's take a look at them. But before we go any further into this video, check out our cloud architecture strategy map in the description below which lays out visually how each strategy looks like in different types of organizations. It also helps explain how these companies use microservices, open source software and even their on premise apps to operate the most effectively as possible. Come and check it out for free. Now let's roll that intro Foreign. But before we go any further into this video, let me clarify one thing. Cloud Native, Cloud enabled and Cloud Agnostic can also refer to ways in which developers create software and applications for the cloud. However, in this video we're talking about them as overall IT infrastructure methodologies. More specifically, we'll look at why is everyone moving to the cloud? What's Cloud Native? What's Cloud Agnostic, what is Cloud enabled, and the pros and cons of each of them. Now why would you want to move to the cloud in the first place? I mean, you've probably heard all about moving to the cloud is the next best thing since sliced bread. But truly, can we believe what we hear? Well, let me tell you a little more about it. Through lifting and shifting assets from the classic on premises based architecture to cloud based architecture, organizations can tweak the parts under the hood of their software, apps and services on the fly, or even swap the whole engine to a new vehicle if needed, making it faster and cheaper to keep their businesses agile in case of, well, pandemics, earthquakes, civil unrest, and most importantly, to keep up with the ever changing market. This gives companies who play in the cloud a huge operational advantage to those who are stuck on premise as they can get their products to the market faster and keep them running there no matter what happens in the world sounds perfect, right? Well, not exactly. It's not all fun and sun in the cloud paradise. Moving your data IP business process all over to the cloud willy nilly can be a little bit dangerous in a business sense too. To for example, you could inadvertently lock yourself into dealing with one vendor for a very long time and it can get hard to switch out of that vendor if you needed to. This would make you vulnerable to their price increases and their underhanded business practices if any came up. Enter the Cloud Agnostic, Cloud enabled and Cloud Native IT architecture strategies which all play around cloud providers and service providers strength and weaknesses to help the enterprise organization operate efficiently in the cloud. Let's take a look at them. First is the infamous Cloud Native architecture. Being cloud native means that your apps and workloads are built in such a way that take advantage of one single cloud vendor's services. But you may be thinking, jordan, didn't you just say that's a little dangerous and not that smart of a business move? And the answer is yes. But it does have a lot of benefits as well. Essentially, being cloud native allows companies to take the best advantage and get the best deals possible by showing their loyalty to that single cloud provider. Using a cloud native architecture has benefits like faster scalability and ease of creating more resilient cloud architecture. Cloud native solutions often come with better performance and better efficiency, free load balancing features often the cheaper option since you will be licensed based on use and storage needs and there are no software or hardware installations needed. Compared to on premises, it's usually easier maintained, allows enterprises to bring new innovations to the market faster, decreases management costs and oversizing updates and patches can be implemented quickly and easily. Now let's take a look at a couple of the drawbacks of cloud native Taking the leap and switching over to cloud nativity as a whole can be a long and complex process. If you're originally on premise, there's a high chance that your development team overhead will increase. Your existing apps could have to be re architected to live and work on the cloud, and it also comes with a lack of portability, meaning you want to stick to mostly Azure but move a few of your infrastructure parts over to AWS or Google Cloud platform. You may run into some issues and they might not want you to do that, costing you another can of worms down the line. In conclusion, Cloud native, although at the cost of freedom, allows organizations to tap into the premium benefits, speed and agility that sticking with a native cloud partner can offer. Now let's talk about Cloud Agnosticism at its core, cloud agnosticism is the art of not being locked in to one single cloud provider for your cloud IT architecture solutions. It also heavily uses open source technologies and portable components make the entire system run as efficiently as possible wherever it needs to. Becoming cloud agnostic is an enterprise strategy that revolves around on not being reliant on one single cloud vendor. Instead, you stack together multiple smaller solutions such as monitoring, compute, power, storage and backup to put your cloud agnostic infrastructure altogether as one. Unlike cloud native, being cloud agnostic allows your company to switch between cloud providers whenever it wants to. And if you really wanted to, it would even allow you to use multiple cloud providers at once. Let's take a look at the cloud agnostic benefits. When you're cloud agnostic, it'll be easy to migrate from one cloud provider to another. You can expect a consistency of performance when moving between the platforms. You're able to maximize your redundancies. You can use open source technologies and avoid licensing compliance cost costs and can run a tailored cloud infrastructure which can potentially be cheaper than cloud native in the long run. Cloud Agnostic cons you are responsible for managing all of the small moving parts in your infrastructure, which could increase management costs. It requires a higher investment in developer resources, potentially higher upfront costs, and you may miss out on some of the benefits cloud native companies enjoy giving their customers like Azure's Cosmos DB or even Amazon Serverless computing. However, unlike cloud native, Cloud agnostic gives you the freedom to forge your own path in the clouds. All right, now it's time to talk about what cloud enabled means in an IT architecture sense. Cloud enabled is often a misused term. Well, this is because cloud enabled is often used to describe types of apps that were originally built and forged in the real steel IT on premise servers and infrastructure there and were just ported over to work in cloud or were just tweaked a little bit to work with the cloud. However, in this video, since we're talking about the overall IT architecture strategies, Cloud enabled IT infrastructure means you're using a mix of the maximize efficiencies. An example of a cloud enabled infrastructure bit from a cloud enabled IT infrastructure. This is so that you can run scalable data distributing workloads to get your data analysis done fast and cheaply in the cloud while your in house compatible benefits include reduced cost of managing on premises physical IT systems, you can keep components like data storage in a secure on premise environment, increase your business continuity, upgrade your collaboration and reduce administration hassle for some of your IT processes. Cloud enabled cons include if something goes down on the physical side of things, the cloud will have trouble communicating back and forth with it, which means it's susceptible to Internet outages or any service outages like that. It's costly to configure. You start going into an ongoing cost model and it can be complicated to manage the costs. Jumping neck deep into the world of clouds can be an icy plunge that you don't want to take alone. However, to warm yourself up, I want you to download our Cloud Infrastructure Strategy Map that outlines how the biggest enterprise companies in the world piece together their cloud infrastructure for maximum operational effectiveness. Link in the description below. Whether you're migrating your workloads, apps, or just doing some cloud research for your organization, we made this video to help you get a deeper understanding and the different ways you can jump into the cloud or just dip your feet in if you so please. However, one thing's for certain before you start spending the big bucks on your new cloud project or initiatives, one thing I'd always recommend is talking to a cloud architect or a software licensing expert to make sure you're not crossing any wires in your organization's legal department and finance department as well. If you have questions about which cloud strategy would work best for your environment, our experts can help answer those questions. Feel free to send them a message here or contact them by clicking the other link in the description below. Now, if we missed anything, feel free to let us know in the comments below. And as always, don't forget to hit that subscribe button, smash the like button, and as always, keep your software safe and your assets managed. I'll see you next time.