What are some common architecture decision drivers and trade-offs for cloud-based solutions?

For cloud solutions, constraints should probably include the topology of the cloud itself: most of the infra is software defined (to the end user), placement of underlying HW components (and critical infrastructure software) in racks, buildings, data centers, zones and regions adds various amounts of latency. One approach could be to run test workloads and compare results to onprem to establish new baselines. These baselines can be used in future cost estimates. A more complex existing solution onprem will translate to a proportionally complex cloud solution. Simpler apps/services will be easier to shift to a cloud model with easier translation of requirements and constraints.

There are often inherent organisational requirements (known as non functional requirements) which will be common across all applications or projects. These will often be poorly documented and just taken for granted but need to be understood and catered for. This can fall into environment related, industry related, legislative requirements relating to the nature of the project or application and the data that is being handled.

A single pattern might not be appropriate for every situation. It is important to understand when and how to mix and match patterns. For example, requirements might include cyclical/periodic billing for subscribers with off-cycle billing for terminating accounts. A batch pattern might be more appropriate for the cyclical billing where many invoices need to be generated on a single day. While a messaging pattern might be appropriate for the on demand requirements

There are many other considerations that factor into the architectural solution that is fielded on behalf of the customer: - Are they seeking to deploy an on-premesis, private cloud solution, due to the sensitivity of the data? - What is their current operational environment? If they are migrating from on-prem to a cloud architecture, might they need to transition in phases? - Would it be better to upgrade portions of the system, cyclically migrating individual sites as part of a geographically distributed architecture? - Is there a need to run the new solution in tandem with the legacy system? Data transformations and data flow between them would add another layer of complexity.

Ensuring data security and compliance is a primary concern for enterprise solutions in the cloud -- and quality control of data is crucial. Storing sensitive data in the cloud can provide robust security features, but it also introduces potential risks. The trade-off lies in finding the right balance between leveraging the cloud provider's security measures and taking responsibility for your own data protection. While cloud providers offer strong security, compliance requirements might necessitate additional security measures, leading to increased complexity and costs.

Code for concurrency and then test for concurrency. This should be very important architectural principles - often overlooked though. Failing to do so can cause very severe downstream integrity and consistency issues especially for data driven applications.

Cloud platforms offer the ability to scale resources up or down to meet varying workloads. This can result in cost savings as you only pay for what you use, and it allows your solution to handle traffic spikes. However, over-provisioning resources can lead to higher costs, while under-provisioning can impact performance during peak loads. Therefore, careful monitoring and resource allocation are necessary to strike the right balance.

Latency and Geographic Distribution: If your solution needs to serve a global audience, you'll need to consider data center locations and content delivery networks. The trade-off involves optimizing for low latency while controlling infrastructure costs. Monitoring and Management: Choosing the right tools for monitoring and managing your cloud resources is essential for maintaining operational efficiency. Trade-offs may involve cost, complexity, and the ability to diagnose issues effectively.

In the world of solution architecture, it's all about balancing these factors to create a cloud-based solution that best meets your organization's needs. The right choices will depend on the specific requirements of your project, and it's often a dynamic process that evolves as your solution grows and changes.

When moving to the cloud, include these on your list: - understand that major gains, for CSPs, are coming from “economy at scale” not by offering some intrinsic tech that’s not available onprem. - nothing is free. - if you have apps that do not follow healthy design principles onprem, don’t expect miracles by simply moving to the cloud. - same NFRs that are challenging onprem, will be challenging in the cloud, especially when network latency is a critical factor (distance is real and fiber optic networks didn’t make any dramatic breakthroughs yet) - attention to fault tolerance, cloud components will fail out of your control; don’t try to avoid infra failures, try to live with them, tolerate them. - try to scale horizontally, if possible.

Data Management: Storing, retrieving, and managing data efficiently is a key consideration. You'll need to choose between various database options (relational, NoSQL, etc.) and data storage solutions. The trade-off lies in finding the right balance between data consistency, flexibility, and cost. Vendor Lock-In: Locking your solution into a specific cloud provider can limit your flexibility. Deciding whether to use cloud-agnostic technologies or embracing the unique offerings of a particular provider is an important consideration. The trade-off is between flexibility and the benefits of specialized services.