In previous talks and articles, I’ve talked and written about WHAT is ‘the cloud’ and WHY is the cloud such a blessing (and why not?). This article is about getting the most out of the cloud, because the cloud is so diverse that you can use it in many ways.
For me the cloud is hosting your software not yourself, not in the local cities’ datacenter but in the big global clouds as provided by for example Microsofts’ Azure, Amazon’s AWS and Google’s GCP. This has many advantages and makes me think that the cloud is the future.
THE CLOUD IS THE FUTURE
The global cloud is so big that it has different entry points. You can run your services as you would in a datacenter with virtual machines (Infrastructure-as-a-Service), you can make use of abstractions like a ready to go database or web app without actually maintaining the servers for that (Platform-as-a-Service) or you can go serverless and ‘just’ run the code without even thinking about apps or servers.
Depending on the entry level, your hosting provider will maintain the hardware and software such that you will always have the latest updates and versions. The huge scale of the cloud makes global coverage easy to set up and computing power is available with major flexibility. Getting charged per usage instead of buying or leasing an entire lifetime of a server surely has its benefits.
Finally, because the cloud is widely used a lot of integrations are now available to connect with other services. For example, monitoring and alerting is very easy to add to your portfolio.
But enough of the benefits of the cloud. Because you’re reading this article you are of course already convinced. The next step is going to the cloud instead of talking about it. How do you get there?
THE SEVEN MIGRATION STRATEGIES
The big research institute Gartner started with a handful of migration strategies. Then Amazon added some and now Team Rockstars IT has a bonus as well. It boils down to whether you want to reuse your current software or start over.
Here are the seven migration strategies or “the seven R’s” on how to move to the cloud: Rehost; Replatforming; Refactor or rearchitect; Rebuild; Replace or repurchase; Retire; and Retain.
Rehost and replatforming are lift & shift options: you package your current software and bring it to the cloud as-is (rehost) or with the least adaptions to get it working (replatforming). Following this chronologically is refactoring the codebase to be better fitted for usage in the quirks of the cloud. When for some reason the current codebase is not workable (or even available) anymore you can start to think about rebuilding from scratch with the cloud in mind.
These options are all inspired by classic inhouse software development. You can also look around and see if an off-the-shelve package has caught up with you. Replacing the old processes with bought software instead has the advantage that you do not maintain it yourself anymore. Software-as-a-service with for example a webbrowser to replace the classic native app also falls in this category.
In some cases, when you investigate the current state of your locally hosted software, you’ll find legacy applications that are from other times. Maybe the company stopped a certain workflow or product but the supporting software is still running. This is the time to retire the software and don’t replace it at all.
Finally, the time might not be right to make a decision right now. Software can be scheduled to be phased out in the near future or require very specific hardware. The Hybrid Cloud offers you something to retain your current hosting and move on with all the rest.
WE MADE IT TO THE CLOUD!
So we agreed to like the cloud, made plans to move to the cloud and then the final day arrives: we made it to the cloud! Time for relaxing and business as usual, that was a long trip!
But don’t be too excited and don’t quit the migration yet. There is more… When you chose for lift & shift with Virtual Machines in for example Microsoft Azure, you are not ‘working in Azure’. That is just datacenter-like which happens to be hosted in Azure instead of the local datacenter. Just reread the benefits I stated earlier: do you use the cloud with optimal configuration? Probably not! This is where the conversation cloud-ready vs cloud-native starts.
CLOUD-READY VS CLOUD-NATIVE
When reading into the matter you can define four phases of cloud adoption. My first introduction was this cool graph:
You start at Opportunistic with your existing applications and legacy apps. This step is mostly still on-premise. Next you’ll go to the cloud with the basic implementation called Cloud-first or Cloud-ready. You pay the cloud bill and stopped your own servers, but the developers start to improve the setup. Processes are changed, software is made resilient and every new feature is made with the cloud in mind. Now you are All-in: there is no way back and nobody actually wants to go back anymore.
The last term is the only one with general agreement on it. We all end up at Cloud-Native but the journey has lots of synonyms and definitions. Let’s just say that cloud-native is using the cloud with maximum benefits.
The common term for this scheme is a Cloud Maturity Model. There are many versions of this to try to objectively define the journey to the cloud. At the time of writing, I could not find a generic Cloud Maturity Model that has been wide spread, but we can still try to define cloud-ready vs cloud-native with this setup.
So, what is “Cloud-Ready” exactly? I found a nice definition in cutter.com:
“These applications can be moved to the cloud, but they do not fully utilize all features of the cloud environment”
For “Cloud-Native” I couldn’t find a catchy definition, but it would at least talk about how deeply rooted this is in design. Cloud-native is not just an extra sauce you pour on top your on-premise applications. To work right in the cloud, it must be made for the cloud. Examples often mention serverless, managed services and autoscaling. To top it off monitoring and alerting is also an important part in it.
The Cloud Native Computing Foundation (CNCF) states the following:
“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”
– cncf.io
What stands out to me in this definition is how closely related to the DevOps movement this is. Also, there is no one cloud-native package, they talk about ‘technologies’.
Microsoft also uses this approach and calls it ‘characteristics’ in their documentation pages:
I like this approach of defining Cloud-native as a set of characteristics instead of describing all as compulsory.
Scanning the documents on the internet about cloud native I came to the following characteristics:
Serverless design, managed services, autoscaling, horizontally scalable, monitoring/alerting, governance, microservices, API driven, stateless, retries/idempotency, cross platform, orchestrated (i.e., Kubernetes), containers (i.e., Docker), cost optimization, DevOps, Continuous Integration (CI), Continuous Deployment (CD), fault tolerant and fault resilient.
Of course, a lot of these characteristics stand for themselves. It is nice to have a checklist, but pick your favorites and don’t implement them all.