Cloud Computing vs. Cloud Native: The Difference Revealed!

Though the terms are often confused, cloud computing and Cloud Native are two entirely separate entities!

Cloud computing -- often referred to simply as “the Cloud” -- is the on-demand delivery of infrastructure (hardware/servers), storage, databases and all kinds of application services via the internet. Frequently these are delivered by a cloud services platform like Amazon Web Services, Google Cloud or Microsoft Azure, with metered pricing so you pay only for resources you actually consume.

Cloud Native is the architecture for assembling all of the above cloud-based components in a way that is optimized for the cloud environment. It’s not about the servers, but the services. So Cloud Native is also a destination: the ultimate goal line for enterprises looking to modernize their infrastructure and process, and even organisational culture, carefully choosing the cloud technologies that best fit their specific case.

There! That was easy.

Perhaps too easy, actually. After all, there are innumerable paths for reaching your Cloud Native migration destination. Identifying, provisioning and then deploying the just-right combination of services to best take advantage of this very new, rapidly evolving world amongst the clouds? It’s easy to get lost.

For enterprises ready to undertake their own cloud migration, staying on track means starting with the “A” in Cloud Native Architecture: understanding and prioritizing design before jumping into full-on implementation and deployment.

In three years of guiding enterprises onto the cloud, Container Solutions engineers have learned a thing or two...or three...about helping each one find their own optimal route. We are most definitely not prescribing any “top down” one-size-fits-all solution -- far from it! However, we have by now collected enough data, through observation and experience, to identify the elements to draw at least the initial broad roadmap.

It's All About Services

• Infrastructure-as-a-Service -- off-premises hardware, data storage, and networking -- is the obvious one.
• Platform-as-a-Service then can be hired to manage and maintain all that virtualized infrastructure from a web interface, greatly reducing the load on your ops team.
• Software-as-a-Service lets you pick and choose component applications, everything from traditional business software (think MS Office 365)  to virtual infrastructure management tools, all delivered via -- and operated over -- the web. The provider ensures security, availability and performance.
• *-as-a-Service: if you can dream it, if your business requires it, there is probably a service for it. If there it doesn’t exist right now, just wait a month or two.  Database-as-a-Service, Functions-as-a-Service…

Cloud services arrive pre-built and ready to wire up with any other services, so you can get right to work more or less instantly. However, in order to use them effectively, you must begin from the right architecture!

Containerisation: The second pillar of Cloud Native architecture. Once you’ve defined your service-based architecture, it only makes sense (for just about everybody, everywhere) to containerise them. Containers isolate an application and its dependencies, even its own operating system,  into a self-contained unit that can run on any platform, anywhere. Meaning that you can host and deploy duplicate containers worldwide (thanks to your IaaS!) so your operations are flexible, reliable and fast.

Microservices: use microservices to break up a monolithic entity into smaller distinct pieces. Ideally, some of these parts can then be acquired as an on-demand as-a-service in the cloud.

Automation:  Simply put, if you don’t have automation then you are rapidly going to get yourself in a mess. Enterprises typically come to the cloud to deploy more quickly and frequently. If you haven’t fully automated your deployment processes, then suddenly your ops staff are spending all that time they save by no longer managing those on-premises servers to instead manually deploy your new, expedited production cycle. More frequent deployments also mean more opportunities to screw up every week; putting things into production faster and scaling them faster also means generating bugs faster. Automated deployment takes the grunt work out of constant implementation, while automated testing finds problems before they become crises.

Orchestration: Once microservices architecture is in place and containerised, it is time to orchestrate the pieces. This is where Kubernetes comes in, and it is one of the very last things to be done in a Cloud Native migration: see  When is the WRONG time to use Kubernetes?

The Executive Summary

In short: to get the best from the cloud, use Cloud Native architecture. Microservices, containers, orchestration, automation. Since the first three may introduce new problems, automation should be among the very first things put in place -- you want the sanitation system laid down before you build your city in the clouds.

Microservices and Cloud Services are key to truly harnessing the power of cloud operations. On the surface, the win might look like getting rid of physical machines -- but the true win is accessing all the extraordinarily sophisticated services. Specialized software as a service, turn key and ready to hook into your application. With cloud and microservices in place, you’ll be ready to iterate and deploy quickly and more often, which is where automation and orchestration come in. It can be complex, yes, but orchestrators exist to optimize all this -- and these days you can simply hire those as a service as well!

We saw this beautifully illustrated by ASOS, the online fashion retailer. ASOS’ big win in the cloud was the ability to choose a different database for every piece of data they had -- without the need to manage the complexities of different databases.  With microservices, Asos could make their apps smaller and specifically tied to a particular database optimized for that exact use case. A relational database for some, key/value store for something very fast, but in every case it is state-as-a-service. Even better, they could buy off the shelf from the provider, and they don’t need specialists to run it all. Not one giant monolith that talks to one giant relational database, but many smaller microservices each talking to their appropriate DB counterparts. By contrast, in the old days if you wanted to run a Cassandra database you also needed a really expensive DB expert. Now you can get them on command from your provider!

Cloud Native is a powerful, promising (and, alas, much-hyped) technology. Enterprises are understandably eager to get there as fast as they can. But reaping the full benefit of the cloud means first taking care to build a solid foundation based on the principles of Cloud Native architecture.

Want to learn more about Cloud Native? Check out our free eBook below: