What are the key principles for designing cloud-based applications?

Just don’t make the granularity too fine. You’ll end up with a distributed monolith. With lots of tiny components talking to each other you’ll have more network load and more latency. Try to find the sweet spot. Advance analysis before you start developing can help. Especially sequence diagrams to show the interactions between planned components. Take a look for example at TM Forum ODA component architecture, and see IG1882 for examples of sequence diagrams between components.

Loosely coupled design in cloud applications prioritizes component independence, leading to: - Scalability: Independent components can expand individually, catering to specific needs without affecting the entire system. - Flexibility: Swift modifications and updates can occur. - Resilience: Component malfunctions don't necessarily cause total system failures. - Cost-Efficiency: Resources are allocated minimising unnecessary overheads. - Security & Integration: Isolated components bolster security, and standardized APIs simplify system integrations. In essence, this design ensures cloud applications remain adaptable, scalable, and robust in a dynamic cloud landscape.

In my experience, once you have a clear bounded context, and applying transactional boundaries, the services become more manageable and less chatty.

It’s helpful to take things in stride. Properly designed cloud solutions are flexible—you don’t know what you don’t know when first starting a project. Flexible designs allow you to be agile and adapt as the project evolves. Also try to use some form of repeatable deployment, like templates for the chosen cloud, or a general solution like Terraform or something. That way you can iterate and still maintain your infrastructure history in a code repository like Git. Finally, be security minded. Don’t be in the news because you left something open and unprotected!

When designing cloud-based applications, modularization is key. Adopt a microservices architecture to break down your application into smaller, independent units. This approach aligns with the 12-factor app principles, emphasizing loose coupling and high cohesion. It enables seamless deployment, scaling, and testing of individual components. Moreover, it offers the flexibility to employ diverse technologies for each microservice. This not only enhances reusability but also simplifies maintenance and extensibility.

In the world of everything needs to be automated, capturing telemetry at every stage of the automated deployment is very critical. Moving from traditional dev, test and deployment teams to Devops model, developer, tester roles are interchangeable. Developers should be thinking with the operational mindset, plan for failures and provide the mechanisms to quickly identify and resolve the issues. Enable meaningful logging, metrics and alert conditions that can reduce the time taken to recover from the failures.

In addition, you should test the backup and disaster recovery plans implemented. If you just have a principle without testing, on mayhem day, you will start from scratch to bring services back online resulting in long downtime . So test.

One important consideration during software development in a cloud environment is to have a strategy for handling transient exceptions . These are exceptions in which a retry can cause success . Reasons could be many including throttling of requests or temporary unavailability of resources. Access to databases configured for High Availability and API's hosted on the cloud can display these errors For the application to be resilient first identify application area's vulnerable to transient errors .Implement retry strategies such as retry with exponential backoff or circuit breaker with use of resilience libraries such as Polly for .Net applications using the transient error codes identified . This will improve resilience and availability.

Embrace Redundancy: Use techniques like multi-region deployment, load balancing, auto-scaling, and, from my notes on modularity, statelessness to aid in redundancy. Plan for Data Consistency: In a distributed system, data consistency can be a challenge. Understand the trade-offs between consistency, availability, and partition tolerance (CAP theorem) and design your data strategy accordingly. Failures are inevitable, but not an excuse for inconsistent data. Learn from Failures: When a failure occurs, conduct a thorough post-mortem analysis to understand its root cause. Use this knowledge to improve your system and prevent similar failures in the future.

In cloud-based application design, planning for failure is crucial. This aligns with the resilience and robustness aspects of the 12-factor app methodology. Implement strategies like retry logic, circuit breakers, and fallback mechanisms to handle potential errors and outages. Employ monitoring and logging tools to track performance and set up alerts for immediate issue detection. Regular data backups and disaster recovery plans are non-negotiables to ensure business continuity.

Although HA is highlighted here, the notion that the cloud will never fail because the application is in HA is an illusion. To accomodate sudden, unexpected or even expected traffic spikes, consider implementing traffic throttling mechanisms (at the ingress) to protect the application and other components from overload. This helps ensure the promised SLA for the majority of users, internal or external, and minimizes those that may experience service degradation.

Performance goes deeper. It is in High level Design and Low level Design of a system. A simple miss in the indexing could cause a robust system to throttle. Setup alerts and distributed logging along with latency in each layer. With regular monitoring you can find bottlenecks and improve your system performance. Computing speed, I/O blocking, Network latency, Time Complexity of the code are important things to look for.

Autoscaling / Serverless: Unless you're building a very specific use-case, it's rare you can outperform the experts at [insert your favorite cloud platform here]. If not going completely serverless, be sure to take advantage of autoscaling. It's always more optimal than a static instance. Implement Database Sharding: Database sharding is a type of database partitioning that separates very large databases into smaller, faster, more easily managed parts called data shards. This can significantly improve the performance of your application by reducing the response time for database queries.

Adopting proven cloud deployment best practices helps in improving the overall security posture of your cloud-based workload. Cloud service providers often provide their own unique set of guidance on security best practices. For instance, the Security Pillar of AWS Well-Architected Framework is a good starting point in understanding AWS security offerings and how to adopt them in your deployment. Community driven guidelines from Center for Internet Security (CIS) can be a useful benchmark to adhere to when it comes to securing your cloud workloads.

Security is non-negotiable in cloud-based applications. Adhering to the 12-factor app guidelines, use encryption for data, both in transit and at rest. Implement authentication and authorization protocols, and employ firewalls for network security. Utilizing frameworks like AWS Lambda can streamline these processes, offering built-in security measures and compliance checks. Regular security testing identifies vulnerabilities, ensuring robust protection against breaches and unauthorized access.

Avoid exposing your services to internet as much as possible. Use secret manager for critical information like hostnames and passwords and rotate them on regular basis. Never put sensitive information in code base, logs, console. Scan for open ports exposed to wide range of connections. Always tighten access with strict firewall rules. Encrypt data as a principle.

Privacy by Design: Consider privacy at the initial design stage and throughout the complete development process of new products, processes, or services. This can help ensure compliance with privacy laws and regulations, and necessarily is more secure. When in doubt, encrypt (always consider performance, but most often, even 512-bit encryption is a trivial latency hit when implemented correctly). This is my top tip, not *THE* top tip. SDLC >> SDL: I often use SDLC still, but really, we should all be using SDL, or Secure Development Lifecycle. Similar to "Privacy by Design", this incorporates security as the foremost thought throughout the entire application design process. Just like TDD helps reduce bugs, SDL helps reduce vulnerabilities.

The automation is important for many reasons and provide many benefits. Some of the most important are: - Reproducibility of Deployments - Minimized Human Errors - Handling Complexity - Scalability - Automated Testing - Ease of new Cloud/Region Onboarding

IaC, CI/CD gives changelogs which gives more visibility on releases. Automating will help to release, scale up, scale down and migrate with consistency and less to No errors. It gives full control and visibility on operations.

Have a bias for cloud-managed services when breaking down your application into modularized components. Use the services the way they were intended to be used and take advantage of their features. Simply moving your app to the cloud without re-architecting the application leads to inefficient design. All you end up doing is shifting complexity from one place to another while never fully realizing the true potential of the cloud.

Need to be cautious while using the cloud managed services as many things are managed under the hood and we might have less control over it. This also includes cost implications as well.

Following cloud-native standards helps to reduce friction in integrating new features/components into existing cloud deployments and Cloud Service Providers often make it a rather "hassle-free" experience. For example, it is pretty easy to add AWS WAF to your AWS API Gateway for your workload deployed in AWS. It can potentially reduce any unwanted integration complexity and cost when introducing new features/components into your existing deployment. The only downside I see is the potential of vendor lock-in.

It's important to make the difference between the classical cloud delivery model in which you rent compute resources from a cloud provider and the serverless model in which the cloud provider will automatically allocate resources based on the number of executions or duration of execution (by execution I mean stateless functions which are being triggered by specific events).

Although being cloud native helps harness the most of the offerings by provider, the system however should be designed for portability. Else, there is lot of power handed over to provider which could bite later when there are better options available with other providers.

There are many managed services are being added with solution to existing problems on cloud platform. We should evaluate them thoroughly for our use case. The service might be solving a problem but it might have other limitations which can cause issues in our use case.

Key consideration is favor managed services. Cloud is more than just infrastructure. Most cloud providers offer a rich set of managed services, providing all sorts of functionality that relieve you of the headache of managing the backend software or infrastructure. However, many organizations are cautious about taking advantage of these services because they are concerned about being 'locked in' to a given provider. This is a valid concern, but managed services can often save the organization hugely in time and operational overhead.