Hot questions in this board:
Hot questions in other boards:
Multi vendor cloud deployments
We have this scenario and we have been using it effectively. It is a common practise especially in big firms that do a lot of acquisitions or firms that have multiple technology departments catering to different business units. The major challenges are:
- Cross BU application development
- Security/ SSO handling and managing user permissions across cloud domains.
- Ownership and service seggregation
- Deployment issues
- Technical knowledge within development teams
We overcome most of the challenges by following Microserices based architecture. Being an enterprise architect its my duty to ensure the cross communication between platforms is seemless. Please let me know if you are looking for something specific
The biggest problem posed by having multiple vendors is the proprietary nature of each deployment model. For example is you script up on Amazon AWS you are tied into the Lamda scripting language and deployment of AWS. It is not transferable to other clouds.
IBM Bluemix abstracts out so many deployment models/scripts, that you need to spend a lot of time to deploy on another service.
Overall just understanding the vernacular between the products is tough. And so switching from one to another, or running some on one vs. the other introduces so many variables that you have no chance to optimize services and people applying them so managing them ends up being a higher cost that standardizing on a single service.
SSO among the multiple services requires a team to construct microservices across the services, thus contibuting to higher costs, upfront and over time.
Lastly backup and overall maintenance is complex as each is different. This is like using multiple OS's to deliver similar services. Costs, training and deployment are more expensive and take longer. Multiple clouds happen because of mergers/acquisitions, multiple departments ordering on their own. You can deploy with the least common denominator that works across all services, but you are not able to take advantages that are inherent on each of these platforms. The result is you must try to managing multiple clouds and make the best of an incompatible mess.
From administration standpoint, Azure offers a variety of options to simplify management of Azure and AWS simultaneous deployment. This link might be helpful: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-amazon-web-service-tutorial
I also ran across information somewhere about Azure offering a consolidated billing platform for both services, but haven't checked it out yet.
Microsoft and Amazon are also collaborating on integration of Alexa and Cortana (https://www.nytimes.com/2017/08/30/technology/amazon-alexa-microsoft-cortana.html).
Both companies are pursuing the open collaborative approach into the readiness the for Industry 4.0 related space. Sure, there is a lot of overlap, but they also have unique and complimentary strengths which, when combined, will create a tremendous synergy. This makes them a serious contender with Google or IBM, which lack the reach into either enterprise or consumer space.
Because of this openness, it is easy to use AWS services where Amazon shines along with other services where Azure may be a preferred choice. For example one may prefer to use Azure for big data, including (MongoDB, Cosmos DB, MS SQL for Linux, Hadoop....) and its virtualization/containerization in conjunction with AWS Lambda or any other component of their serverless event driven architecture.
Integration of the two is of secondary importance as it all boils down to writing some JSON code, or some such silly thing. There is no real overbearing benefit to sticking with one over the other when we can use the best from both.
Harpreet makes a good point about the focus on microservices. Tech is moving farther away from monolithic architecture and into agile microservices deployments.