What strategies can you use to ensure cloud-based software design is interoperable and portable?

1. Container based architecture decisions like Kubernetes over ECS or Bean Stalk 2. Infrastructure as Code over Cloud Native changes 3. Microservices driven isolated architecture decisions 4. Standard protocols like HTTP(s), gRPC over abstracted architecture choices 5. Multi-Cloud strategy 6. Cloud Agnostic tools

Portability isn't a binary property. That's our computer science fallacy to think everything is ones and zeroes. Portability aims to reduce or minimize the cost of moving your system to another vendor/cloud/architecture/location. If the chances of that happening are non-zero, then your software carries a liability that can be expressed as the migration cost times the likelihood that it'll happen.

1. Don’t fall in built trap Cloud formation or Bicep, go to native as much possible terraform 2. Use Restful API integration as much possible 3. Use Infrastructure as code and should limit manual steps as minimum as possible 4. Containerization technologies such as Docker and Kubernetes promote application portability by encapsulating applications and their dependencies into portable, standardized units. 5. Portable setup documentation should not not be more than 1 page ??

In my experience, interoperability is critical for seamless system integration. One time at work, ensuring our AWS service could exchange data with a CRM on Azure highlighted interoperability's role in multi-cloud environments. One thing I have found helpful is viewing portability as safeguarding our cloud investments. When we migrated an application to a hybrid cloud, the portability of our design minimized code changes and disruption, underscoring its value for business agility.

Utilizing standard tools ensures solution interoperability: APIs (REST or GraphQL) for seamless communication. Message brokers for distributed processing. Standard data formats (JSON, AVRO, XML) for compatibility. For portability: IaaS: Own infrastructure, limited cloud migration practicality. PaaS: Cloud-native, with concerns about vendor lock-in. Mitigate with the 70:30 rule. Containerization: Higher cost but optimal portability, enabling consistent deployment.

In the cloud landscape, choosing IaaS is like custom-building a car; it requires more effort but offers full control and a custom journey. PaaS is like riding a train on a fixed track—easier, with less control, but efficient. SaaS is like taking a cab—no driving, direct to your destination, yet entirely in the driver's hands. Each choice balances control against ease, shaping your cloud adventure.

"The less I use from the cloud, the more portable I am" is a common misconception. Kubernetes and many managed open source services (e.g. managed Kafka, Cassandra etc) are not IaaS but more portable than VMs. Even if you build everything yourself, you'll have migration cost. I know enterprises who spent millions migrating their custom software from Java 6 to 8!

1.Defining and designing applications with Open API standards. 2.Choosing the right orchestrating stack for application & Infra which enables you to orchestrate applications and infrastructure no matter where they run. ( Crossplane ). 3.Defining standard interfaces of provisioning & deployments. 4. Plan for simplicity.

The choice of cloud service models—Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS)—determines your level of control and customization. IaaS offers high flexibility but requires more effort, while PaaS limits choices to the provider's tools. SaaS provides a ready-to-use application but restricts customization. Each model varies in interoperability and portability, with lower-level models offering higher flexibility and responsibility, and higher-level models reducing customization options. When deciding, consider your need for control, the level of effort, and the desired level of customization versus ease of use.

This choice is usually based on the scale of the teams. Extremely large organizations who can afford to have a platform engineering teams can do IaaS, most teams will end up using the cloud as PaaS, run what we want on a managed stack. This will approach doesn't look to change anytime soon. SaaS is slightly different from this choice matrix, as these are mostly accelerators. Taking a simple example of an IAM solution its a choice between a Auth0, Cognito, run open source like keycloak or build one on our own., The bottom line is that its based on the teams skill, knowledge and the bandwidth they have to do something that may not be a direct value add to the business.

We had to get different cloud systems to talk to each other smoothly. My go-to move? Use the common tech "languages" that everyone knows. I've found that sticking to popular tech standards – like using HTTP/HTTPS for sending messages across the web, or JSON for packing up data – is like using the same plug fits into any socket, anywhere. A handy tip? Stick with REST for joining up different web services. It's like having a universal key that unlocks doors across various cloud platforms, which keeps things simple and avoids being tied down to just one company's way of doing things.

Embracing standard protocols and formats is like speaking a universal language in the world of cloud software. It's akin to using a common dialect everyone understands, ensuring smooth communication and compatibility between different platforms. Think of it as having a passport that allows your software to travel freely across various cloud environments, preventing the hassle of reconfiguring or rewriting when changing providers.

In my experience using a standard protocol/format helps integrating discrete pods more effectively and helps you adhere to SOLID principles from a System/Product design perspective. This becomes an foundation layer to design the various microservices you may eventually need to integrate with each other. Defining a contract/API also eases in testing and rollouts of the applications and also assists in identifying problem areas within the application workflow quick.

Protocol standards have been a huge booster for our industry. Can you imagine not having HTTP? They allow you to interconnect diverse components and thus are great for interoperability. As always, keep in mind that abstractions cannot overcome physical limitations like latency, unreliable networks, or egress cost.

Use of standardized formats, protocols, and communication methods like JSON, HTTP(S), APIs. Enable devices, applications, or systems to understand and interpret each other's data, commands, or functions, fostering a common language for interaction.

Microservice Architecture is an excellent Domain Driven Design approach, it is more of an art than science. While MS offer great flexibility, the biggest challenge organizations must consider - How many micro services do we need for a particular product/platform and who owns each service (domain expert and not IT)? Most often the MS design teams lack domain experts and comprise of IT teams. Hence the design team has to play catch-up while defining the bounded context of a microservice during every phase of delivery, this is because requirement is never described fully. As with every product, features and functionality evolve constantly, the designers must design microservices with finely ingrained flexibility of configurable outcomes.

Breaking down the monoliths into effective microservices helps give you greater visibility into the entire application landscape and assists in making effective choices for various software components and design. In our microservices architecture the disaster recovery and auto scalability helps deliver functionality to our customers better and also limit the risks associated with adding new features to the application. A blue green deployment methodology can also help us carry out experiments in production and faster rollbacks in case of untoward incidents.

Microservices break down complex applications into smaller, independent services, much like how a team of specialists works better than a single generalist in tackling various tasks. Using microservices allows each part of an application to operate on the most suitable cloud platform, like how travellers might choose different modes of transportation—air, road, or rail—based on the terrain. This ensures that each service can be developed, scaled, and maintained in isolation, streamlining updates and maintenance. Adopting this approach provides a resilient structure where each service is a self-contained unit, capable of being moved, improved, or repaired without disrupting the entire system.

Although I am generally a big fan of micro service architecture, I must emphasise the importance of aligning the ambitions with the overall business goals. Before jumping straight to the “best practices” I recommend any team to think about what scalability, performance and availability requirements you have. Furthermore, what is the a realistic team size and ability to find the right competencies in the market. Introducing too many services with e.g. CQRS pattern might as well increase complexity, and coordination requirements, hence it might slow down the pace without increasing the team capacity and competence.

Microservices architecture is like having a toolbox filled with specialized tools for different tasks. It breaks down software into smaller, manageable parts that work independently but together seamlessly. This approach not only enhances flexibility in deploying services across various cloud platforms but also simplifies updates and troubleshooting by isolating and modifying specific services without disrupting the entire system. It's like a modular design that allows for diverse languages and technologies, fostering adaptability and scalability in a constantly evolving cloud environment.

The combination of containerization and orchestration has been a cornerstone for achieving fluid cloud software designs. Think of containerization as creating a detailed model kit of your application—every piece needed to build the model is in the box, ready to be assembled anywhere, anytime. Then, orchestration is the process that comes in like a skilled project manager, ensuring that all these model kits are assembled in harmony, in the right order, and with the right configuration, regardless of where the construction site is located. Using tools like Docker for containerizing applications, and Kubernetes for orchestrating these containers, has allowed us to deploy complex software systems across various cloud platforms with ease.

Another great aspect of containerization and modern orchestration platforms is the ability to decouple application-specific pieces of the solution from the underlying infrastructure. Encryption, secrets management, observability, authentication, load balancing, and other low-level aspects - all these can be delegated to specialized software components (by implementing sidecars, for example) that do only one job and do it well. While the application, running inside the container, will focus only on the business aspect of the solution without being tied to the specific underlying technology

Containerization and orchestration act like a perfect duo, akin to packing items into a versatile, standardized box and then having an expert organizer set everything up seamlessly. Containerization encapsulates software and its dependencies, making it easily transportable across various environments. Orchestration, like a master coordinator, automates and manages these containers across different platforms, ensuring they work together harmoniously. Using tools like Docker for containerization and Kubernetes for orchestration makes your software a portable, consistent entity, capable of running on any supporting cloud platform. It's like having a well-organized, adaptable system that can thrive anywhere.

One thing I have found helpful is eBPF. While containers and orchestration offer a power combination as an application delivery method, as you scale and balance IO/perf, security and IP management, it can quickly become out of control like a wild fire. I look at K8's similar to multi cloud networking, starting with a flat topology helps think about the solution organically and can help avoid engineering around problem statement that have a tendency to lead to technical debt buckets filling rapidly.

Containerization and an orchestration layer like Kubernetes provide a fantastic abstraction layer between your application and your cloud provider. All major cloud providers have managed Kubernetes engines, but you can also run your own too! For this reason, if you’re focusing on portability, Kubernetes and containerization can help you be ready for a shift to a new cloud provider with minimal fuss. That being said, Kubernetes isn’t the best solution for everything. Serving static assets out of Kubernetes (perhaps with an Nginx container) is more portable but also far more costly than leveraging your cloud providers file storage solution and a CDN. With all architecture decisions, evaluate the tradeoffs and align with the business goals.

Testing and monitoring your software is like regularly checking the pulse of your creation to ensure it's robust and adaptable. It's akin to quality assurance, ensuring your software performs seamlessly across diverse cloud environments. Regular assessments not only help identify and fix issues but also offer insights for enhancing interoperability and portability. By using various tools and methods to evaluate functionality, performance, security, and reliability, you're essentially fine-tuning your software to meet expected standards, making informed adjustments based on collected data. It's like maintaining a well-tuned engine, ready to adapt and perform optimally in any given cloud landscape.

The ultimate goal should always be to have fully automated testing and monitoring. This is required to achieve top engineering performance and hence faster time to market with new functionality. An issue I often see is the lack of understanding in organisations of how important it is to invest properly in an automated CI/CD pipeline. My recommendation is to measure engineering performance automatically and use that as motivation and argumentation for investing even more in automation.

In my experience, fully embracing the principle of "you build it - you own it" pays off in the long run. Monitoring (actually, the best term is observability) is an integral part of this principle and it is extremely important that the team who built the component - is responsible for monitoring and supporting it, not an external team. This way the engineering team will pay attention to the right signals and make more accurate prioritization and improvement decisions.

While this is already established that testing and monitoring of your software is a must have, a lot of thought should be given to the choice of tools. You would want to keep your observability system which can work with your software, especially in multi-cloud or hybrid systems. This will not only keep the observability not only cloud agnostic, your observability team will have to upskill in lesser number of tools and it will be easier to manage.

Be cautious to not trade productivity for portability! If you're not productive (and someone else is), you may not have anything to port!

Interoperability is a must in today's world and more or less universally accepted, however when it comes to portability, one should always ask the question: Why. Why do you need your cloud application to be portable? Is it because of regulatory reasons, high availability reasons, costs, fear of vendor lock-in, or just because of aspirational reasons? If you have real reasons for your application to be deployed on multiple clouds and that brings a distinctive advantage to your business then only you should invest in making your applications portable as it will need a lot of investments and adds another level of complexity. Always ensure that you are building portability in your application for business reasons.

Something that is missed in the suggestions is the debate on being cloud native fully. In my experience while this is an easy way to start and scale, people normally miss the costs from the decision making process and it almost always comes back when re-architecting isn't a choice anymore. The world will catch upto FinOps practices, while it does, its the architects / leads responsibility to instill the same.

Cloud agnostic design requires a proper use case and requirements in my perspective else we might simply complicate the design and won’t use the native tools or pass services which each cloud vendors are offering. But if we have such requirements we may can use open source container platform which is vender neutral or you could cross platform solutions such as VMware cloud on Aws/ azure / GCP .

Looking to use managed versions of popular open source software is also a good approach. You get the benefit of strong community, broad tooling and integrations with other software, plus the high liklihood that the service is available in other cloud providers (albeit with different infrastructure provisioning) or you can self host in the worst case.