How can you ensure your cloud apps are portable across platforms?

Winglang offers a solution to this through its standard cloud library. The library offers a set of cloud primitives that are available across all providers. When a Wing app is compiled, the compiler consults a “platform provider” which implements these primitives as through concrete cloud resources. This allows Wing applications to be compiled to any supported platform as well as to run inside a local simulator for development and testing ??

1. Containerization 2. Kubernetes orchestration 3. Multi-cloud strategy 4. API standardization 5. Microservices architecture 6. Cloud-native development 7. DevOps practices 8. Infrastructure as Code (IaC) 9. Platform-agnostic configurations 10. Cross-platform testing 11. Compliance with industry standards 12. Use of open-source technologies 13. Vendor-agnostic solutions 14. Continuous integration and deployment (CI/CD) 15. Stateless application design 16. Data portability considerations 17. Cross-cloud networking solutions 18. Load balancing across platforms 19. Monitoring and logging standardization 20. Encryption and security protocols 21. Auto-scaling mechanisms 22. Cloud-agnostic database solutions

1)Use technologies like Docker or Kubernetes to allow your application to run consistently across multiple platforms. 2)Choose a platform-independent programming language. 3)Breaking up your application into smaller, loosely coupled services increases portability. 4)Use tools that are designed to work across multiple cloud platforms. (Ex:Terraform,Ansible). 5)Utilizing open standards and APIs can reduce the risk of vendor lock-in and increase portability. 6)Avoid the use of cloud-specific features that can't be easily replicated on another platform. Remember, that while portability is important, it's also crucial to balance it against other factors such as performance, cost, and the specific features offered by different cloud platforms.

1. Containerization 2. Orchestration with Kubernetes 3. Adherence to Industry Standards 4. Decoupling Dependencies 5. Cloud-Agnostic Code 6. Use of Cloud-Agnostic Services 7. Testing Across Platforms 8. Multi-Cloud Strategies:

Docker, AKS cluster with Terraform is one of the solutions for .NET microservices with Azure. Microsoft does have a very good documentation on this as well.

This as a principle is right but as you get into implementation logistics, point to consider would be the need for custom operators to support common cloud infra, which can lead to maintainability issues as well.

Using a Docker container helps us create a package along with the required libraries for the app. In that way, it is always easier to move across platforms, installing them as a go. Creating images is one of the best approaches followed by Tech teams to package and distribute software.

Avoid direct calls to cloud provider APIs within your core logic. Instead, create a thin intermediary layer. On one end, design this layer to offer an intuitive API for your core logic, while on the other, it adeptly translates and handles calls to the respective cloud provider's API. This intermediary doesn't necessarily have to be a full-fledged microservice; it can be implemented as a library. Do not depend on this layer but rather on the interface provided by the layer. This way you will be able to provide different implementations for different cloud providers or even run on a local host.

This can quickly bloat into lot of micro components that one needs to maintain as well. Loose coupling is spot on but over engineering modularity will increase dependency touch points as well.

Avoid hard coding credentials and config?! Merely ‘avoid’?! Hmmm. Such malpractice should be _strictly forbidden_ in any serious system implementation or software engineering organisation, acting as employee, part, or service provider to, government or corporation.

One of the approach is to have a centralized config manager along with a third party secret manager, so that you have a single placeholder for all your configurations for different applications and a single secret store for all the app credentials . Example - config server/manager on GitHub along with HashiVault for credential management.

A good practice is to use the environment variables or configuration files for credentials. Hard coding not only makes it difficult for developers but also introduces huge security risk.

If you have access to secret management services, use them they also make it easier to share different credentials among different teams.

Config and creds should be stored in cloud. You can use SSM for configs and secret manager in case of AWS. Key-Vault in Azure is also great for storing creds. Basically hard-coding the config and Creds makes the code redundant, vulnerable and less-secure. Best approach is to avoid them as much as we can.

Testing apps on different cloud platforms is useful when combined with automated functional, integration, performance, and chaos tests that are administered on these platforms.

When writing tests focus on what varies. The core logic remains consistent across different clouds. Thoroughly test this core logic in a local environment. The key variations arise in the "anti-corruption" layers (designed to shield the core logic from cloud-specific APIs) and timings. Emphasize extensive testing, including load testing, for these layers. Unlike core logic, "anti-corruption" layer code undergoes fewer changes, reducing the need for frequent cloud-based testing. Simulate diverse scenarios in the cloud and gather data. Use gathered data to simulate different clouds in your local settings. This not only accelerates engineering processes but also results in cost savings.

While the article's points align effectively with portable Infrastructure-level components across various cloud vendors, challenges emerge with the consumption of Platform as a Service (PaaS) offerings like #Azure #Cosmos or Amazon #DynamoDB. It's crucial to consider the substantial advantages these PaaS services offer when contemplating portability across different platforms.

There are some other ways where we can use Terraform to move across different cloud platforms. It is similar to cloudformation stacks where you can move across AWS, GCP or Azure to easily create the resources from scratch.

Using dedicated servers on a cloud should make things much easier for migration, but might be much harder to start. It’s a trade-off.

In my experience, the software stack you build on is just as important as the infrastructure it runs on. For example, I have chosen to use dart and flutter because of its support for virtually any device. We are even one of the first companies to use a full stack dart and flutter application so our back end front end is even built in the same language streamlining everything.