Maybe if I could find the candle of thought to light this jargon I would put my mind at ease.
So, what does this buzzword mean? And where does this all fit into this new world of micro-services SAP is focusing now? Perhaps I am not the only one here thinking: "how on earth does these people come up with such names". Of course, I could just google for it and try to find a good definition that best fit it. But I wanted to understand it beyond the simple "mix of cloud providers" definition.
First, let me start by saying this is not a new term in the industry. Perhaps just for me in my humble small world. The first time I heard about it was after the release of SAP Cloud Foundry Services in SAP-CP (SCP).
Not trying to be the Mariner that stops a man who is on the way to a wedding ceremony, and begins to recite his story. Yeah, I could find a reasonable definition such as: "Multi-cloud computing is the use of more than one cloud environment to satisfy business requirements". Of course, this is the most obvious and perhaps the jargon make a bit more sense now. source
But that is just a very simplistic definition. I've found others and most say that it's a combination of either public and private clouds with several different IaaS providers. Simple, right?
Multi cloud is neither a single unique solution you can purchase from this or that vendor. It is in fact a strategy in which companies will use their software where they best fit. It does this by using one or more cloud providers (public or private) - hence the word "multi" - just as long as each provider can fulfill their specific requirements at a given time.
In other words, a company may use SAP-CP Cloud Foundry to deploy their NodeJS application using SAP HANA as big data processor, crunching the numbers, finding data patterns and predicting tendencies using machine learning, etc. But at the same time will use another specific service provided by another cloud PaaS/IaaS player that could add value to the overall solution. Reasons for that may vary from the inability to provide all requirements in a single PaaS to the a more complex approach like making your app resilient. But the point is that the final solution will use both clouds at the same time making up a single "solution".
Wait, is it really crawling in my skin? What about hybrid-cloud? You may have heard this term before as I did and thought: "to me it makes more sense!" Right? You had your cloud application running on a PaaS (hopefully SAP-CP) and this application connected to your S/4HANA running on HEC (HANA Enterprise Cloud) using SAP Cloud Connector. There you have it, multiple cloud solutions - no need for a "new" term.
Why use another now? The simple answer is that the term hybrid is also valid for multi-cloud. All multi-cloud based solutions do use a hybrid cloud approach. However, not all use-cases of hybrid are multi-cloud. Confused? Well, welcome to my world!
The S4/HANA example above is a perfectly good example of what isn't considered a multi-cloud solution. What makes multi-cloud a strategy is the ability to move this pieces of the puzzle around - from vendor to vendor - without disrupting the overall solution. If you were to move you NodeJS app it might be feasible, however to move an S4/HANA from HEC to a different cloud provider might not be as easy as it should - at least as of now.
This is exactly why I added the "at a given time" to my definition. This means that for an enterprise it makes perfect sense to move a piece of their solution to SAP-CP now simply because the circumstances have changed (i.e.: cost, technology, location, etc.). The flexibility to move this pieces of software around brings new and exciting challenges to the table. And to be able to comply with such flexibility, you will need a cloud that can support such "movement".
What we often see are software and hardware vendors trying to push solutions based on specific features - which promotes a software lock-down. There is a case in which no other vendor can provide a similar solution thus a lock-down becomes a necessity. However, chances are others are already offering a similar solution/service at either a lower cost, better integration options or even performance. SAP Cloud Platform - Cloud Foundry will enable such portability over technology lock-down. This is particularly true when you think about HANA Database offering. It might be considered a technology marriage. To the best of my knowledge, no other solution will offer the type of big data capabilities such as a HANA system. On the other hand, for all other use-cases you will find several database systems to choose from in a Cloud Foundry implementation.
Imagine yourself as head of a development team receive important information that your company's sales portal is being flooded by demand on a region during the weeks preceding Christmas. The system automatically informs you that the region is Brazil, but most of your order management system is running out of Oregon. The system tells you that you could re-route the requests coming from Brazil to another Data Center running out of São Paulo. And all you ever needed to do is to approve such change. The systems will automatically re-organize themselves to fulfill this requests.
I definitely don't recommend biting off more than you can chew. The good news is that all this technology is very near and you can start by designing your very own Multi-cloud strategy.
Some "pointers" on how to knit it all together:
All of this is somewhat inherent to the Microservices architecture and Cloud Foundry is just an enabler. SAP Cloud Platform is one implementation of the Cloud Foundry standard that could provide the grounds for you to trail. It is not a trivial and easy path, but it surly has its trade-offs.
Nevertheless, think of the above list as parts of your own to-be multi-cloud strategy. Yes, you will need to tweak it to become your very own Cloud strategy.
Enjoy!
So, what does this buzzword mean? And where does this all fit into this new world of micro-services SAP is focusing now? Perhaps I am not the only one here thinking: "how on earth does these people come up with such names". Of course, I could just google for it and try to find a good definition that best fit it. But I wanted to understand it beyond the simple "mix of cloud providers" definition.
First, let me start by saying this is not a new term in the industry. Perhaps just for me in my humble small world. The first time I heard about it was after the release of SAP Cloud Foundry Services in SAP-CP (SCP).
Rime of the ancient mariner
Not trying to be the Mariner that stops a man who is on the way to a wedding ceremony, and begins to recite his story. Yeah, I could find a reasonable definition such as: "Multi-cloud computing is the use of more than one cloud environment to satisfy business requirements". Of course, this is the most obvious and perhaps the jargon make a bit more sense now. source
But that is just a very simplistic definition. I've found others and most say that it's a combination of either public and private clouds with several different IaaS providers. Simple, right?
Standpoint
Multi cloud is neither a single unique solution you can purchase from this or that vendor. It is in fact a strategy in which companies will use their software where they best fit. It does this by using one or more cloud providers (public or private) - hence the word "multi" - just as long as each provider can fulfill their specific requirements at a given time.
In other words, a company may use SAP-CP Cloud Foundry to deploy their NodeJS application using SAP HANA as big data processor, crunching the numbers, finding data patterns and predicting tendencies using machine learning, etc. But at the same time will use another specific service provided by another cloud PaaS/IaaS player that could add value to the overall solution. Reasons for that may vary from the inability to provide all requirements in a single PaaS to the a more complex approach like making your app resilient. But the point is that the final solution will use both clouds at the same time making up a single "solution".
The Hybrid Theory
Wait, is it really crawling in my skin? What about hybrid-cloud? You may have heard this term before as I did and thought: "to me it makes more sense!" Right? You had your cloud application running on a PaaS (hopefully SAP-CP) and this application connected to your S/4HANA running on HEC (HANA Enterprise Cloud) using SAP Cloud Connector. There you have it, multiple cloud solutions - no need for a "new" term.
Why use another now? The simple answer is that the term hybrid is also valid for multi-cloud. All multi-cloud based solutions do use a hybrid cloud approach. However, not all use-cases of hybrid are multi-cloud. Confused? Well, welcome to my world!
The S4/HANA example above is a perfectly good example of what isn't considered a multi-cloud solution. What makes multi-cloud a strategy is the ability to move this pieces of the puzzle around - from vendor to vendor - without disrupting the overall solution. If you were to move you NodeJS app it might be feasible, however to move an S4/HANA from HEC to a different cloud provider might not be as easy as it should - at least as of now.
Flexibility
This is exactly why I added the "at a given time" to my definition. This means that for an enterprise it makes perfect sense to move a piece of their solution to SAP-CP now simply because the circumstances have changed (i.e.: cost, technology, location, etc.). The flexibility to move this pieces of software around brings new and exciting challenges to the table. And to be able to comply with such flexibility, you will need a cloud that can support such "movement".
Set phasers to stun!
What we often see are software and hardware vendors trying to push solutions based on specific features - which promotes a software lock-down. There is a case in which no other vendor can provide a similar solution thus a lock-down becomes a necessity. However, chances are others are already offering a similar solution/service at either a lower cost, better integration options or even performance. SAP Cloud Platform - Cloud Foundry will enable such portability over technology lock-down. This is particularly true when you think about HANA Database offering. It might be considered a technology marriage. To the best of my knowledge, no other solution will offer the type of big data capabilities such as a HANA system. On the other hand, for all other use-cases you will find several database systems to choose from in a Cloud Foundry implementation.
Beam us all up, Scotty!
Imagine yourself as head of a development team receive important information that your company's sales portal is being flooded by demand on a region during the weeks preceding Christmas. The system automatically informs you that the region is Brazil, but most of your order management system is running out of Oregon. The system tells you that you could re-route the requests coming from Brazil to another Data Center running out of São Paulo. And all you ever needed to do is to approve such change. The systems will automatically re-organize themselves to fulfill this requests.
Head over feet
I definitely don't recommend biting off more than you can chew. The good news is that all this technology is very near and you can start by designing your very own Multi-cloud strategy.
Some "pointers" on how to knit it all together:
- Test Driven Development is a must in the age of Microservices development.
- Think about how you can automate the build and deploy process to promote Continuous Integration capabilities in your organization. SAP provides an excellent tutorial on CI Best Practices .
- Consider not just the pieces of software that make up your overall solution, but also how they can be easily portable and how the several pieces of infrastructure will be impacted during changes.
- Plan a wide adoption of Microservices Architecture. Do it the right way by properly defining entities and how granular they need to be. There are good books to aid you with that task, such as Microservices: Patterns and Applications, by Lucas Krause and Building Microservices by Sam Newman
- Make your Microservices resilient and scalable and can be monitored in all aspects possible. Make sure you choose a robust Messaging Bus, like RabbitMQ and libraries such as Netflix, Spring and Akka - which are just some great examples provided by Open-Source Communities that will help you with the building of Microservices solutions. Grafana is also used to monitor the services. The key take away here is that you choose a library that both mature enough and your feel comfortable working with.
- Expect to trail unexplored arena and build your own reusable libraries. This blog exemplifies how you might feel once embarking on this journey - considering the libraries and platforms have evolved since then.
- Expect persistence to fail (even non-gracefully) and make sure your data can be consolidated later. Decentralizing your persistence objects while ensuring data integrity. Many of the above libraries already implement some sort of fail-safe net to start with.
- And please don't start with the monolithic app of yesterday. Get your monolith up-and-running but follow the domain-driven design patterns. Only then get a notion on how to refactor it for scaling and distributed systems.
- Last, but not least, chose a platform the is easy to manage via API's - after all the idea is to provide flexibility and automation.
All of this is somewhat inherent to the Microservices architecture and Cloud Foundry is just an enabler. SAP Cloud Platform is one implementation of the Cloud Foundry standard that could provide the grounds for you to trail. It is not a trivial and easy path, but it surly has its trade-offs.
Nevertheless, think of the above list as parts of your own to-be multi-cloud strategy. Yes, you will need to tweak it to become your very own Cloud strategy.
Enjoy!
- SAP Managed Tags:
3 Comments
