As stated in his , “[when] it comes to the cloud, best-of-breed wins.” James also discussed how the quest for best-of-breed will drive multi-cloud adoption, giving the example of how a Microsoft-centric enterprise may choose Azure for their apps, while choosing Cloud Platform (GCP) or Amazon Web Services (AWS) for data analysis jobs. Indeed, 98% year-over-year growth in Azure revenues, which implies that AWS is no longer the only game in town. James Markarian recent Infoworld article Microsoft Google Microsoft recently reported The multi-cloud concept continues to come up in our conversations with forward-thinking industry professionals. But here’s a critical question that the industry still needs consensus on: With many companies choosing to run application stacks across public cloud environments that are potentially spread geographically, what is the right Internet-facing entry point into your application? More specifically, how does an API/microservices gateway, which is typically deployed in front of all of our microservices, evolve to meet the needs of multi-cloud applications? Let me elaborate with an example: A modern application (app.company.com) happens to have two critical components: 1) An authentication service used to validate a registered user’s identity before the user can start using the service; and 2) An image upload service that receives an image and carries out deep learning to determine whether the image has a cat or a dog in it. The application owner wants to run the authentication service in AWS because they prefer to use to store user account information, etc. They name it login.app.company.com. RDS Separately, the application owner wants to run the upload service in GCP because they prefer to use for image processing. They name it upload.app.company.com. ML Engine In this scenario, what is the right place to deploy the API/microservices Gateway? If the gateway is deployed in either GCP or AWS, you’ll be able to simplify service naming (login.app.company.com → app.company.com/login and upload.app.company.com → app.company.com/upload), but will see traffic tromboning between GCP and AWS, and your end customers will suffer poor performance. If gateways are deployed in both locations, you’ll solve the performance issue but will have to invent a complicated solution for single sign-on (SSO) between the two services, including secure distribution of private keys across clouds. I would argue that in a multi-cloud world, the entrypoint (API/microservices gateway) should reside within a neutral/agnostic entity that is not tied to a geo-location. And having said that, I would further argue that the industry needs to rethink cloud-native architectures in the multi-cloud world. At , we have developed a strong thesis on the right way to build out multi-cloud applications. If you would like to learn more about how Team Rafay can help you scale your applications across the globe to achieve improved performance, we’d love to . You can also sign up for . Rafay talk to you updates about our company by clicking here

Stacks

Amazon

Google

Microsoft

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Rethinking Cloud-Native Architectures In The Age Of Multi-Cloud

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

Haseeb Budhani

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Rethinking Cloud-Native Architectures In The Age Of Multi-Cloud

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

Haseeb Budhani

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES