How can you design cloud computing software that is testable, maintainable, and improves over time?

A modular and decoupled software architecture enables easy testability. Small services with clean APIs can be easily integration tested. Emitting events, which are fire-and-forget, instead of API calls, reduces the necessity of mocking.

Event based microservices aren’t the panacea that’s being sold. Gains in modularity and “scalability” come at real costs of adopting intractable distributed systems problems: - transactional integrity becomes a nightmare when your request spans 5 services. - fire-and-forget events can fail for validation errors (among others) and never be processed, creating manual work to try to resolve data conflicts on data that should have never been accepted into the system. - added strain on both developer and operational time. make sure you have lots of extra team bandwidth to handle the extra overhead of work to manage infrastructure management requirements that come with this system (even in the cloud).

Designing cloud computing software requires careful consideration of several factors in which to make it testable, maintainable, and be able improves over time. Let's review some of the key principles and practices to follow: Modular and decoupled architecture, Automation and continuous integration, Scalability and elasticity, Monitoring and observability, Configuration management, Version control and deployment automation, Documentation and knowledge sharing

While applying well-known cloud-native principles like microservices architecture, containerization, dynamic orchestration, immutable infrastructure, statelessness, API-based communication, observability, and monitoring, it is critical to be aware of some relevant caveats that make things over-complicated if you think you must follow whatever guide you are trusting in. Relevant caveats are: the distributed nature of microservices creates much [unnecessary] complexity, like handling data across distributed systems and consistency, security risks, performance optimization, and cost management. Also, please know how much your vendor is locking you in. You need to balance between a pure-microservices approach and a legacy monolithic one.

A modular architecture makes testing simpler. Decoupling and following a well documented architecture pattern makes maintainability easier

We follow Rest architecture for crud APIs. Rest design patterns ensure uniformity, statelessness and intuitiveness of endpoints. Rest is a better option for advanced object manipulation than GraphQL because of its explicit and uniform nature that helps ensure highly testable, reliable and maintainable services. GraphQL architecture is excellent however for fetching data. It offers advanced search and browse capabilities which aid in the performance, flexibility and extensibility of services.

Design patterns used to be pretty popular in monolithic enterprise architectures. In modern microservice architectures, they lost importance since decoupling can be done by microservices, event brokers etc.

design patterns are even more important to microservices as you’re taking on all the data integrity problems yourself, and without good patterns you’re going to create an unmaintainable rube goldberg machine. Some patterns of note are: - two-phase commits - back-pressure - event sourcing - CRDTs - request atomicity and idempotency - transactional outbox - event log/append only log and that’s just to start. If you can save yourself the trouble, avoid the problems these patterns are solving by building a monolith, or at the very least, make bigger microservices.

In cloud systems, the use of the mentioned design patterns have been somehow "replaced" by others that use the cloud components to leverage scalability. For example, the use of queues and pub/sub to help amortize a peak in requests perminute, conceiving async systems that will quickly reply with an acknowledgement but will process the requests and return the response later using a callback, integration with data warehouses and designing event based systems. Code quality is of course still important, but when applications grow to a large audience it is common to sacrifice some patterns to gain on performance (and scale).

Please use the programming language where the mentioned design patterns are baked into the language design. However, I recently found a useful Fluent Builder Pattern.

Automate testing as much as possible so tests can be applied frequently also protecting against regressions, but make sure that tests do not cover trivial happy cases only (pair programming etc.). Consider where to invest most: test pyramid is not always the best answer, there's test trophy and other approaches - your mileage will vary. Don't delegate test implementation and execution to separate teams - testing is integrated part of the dev process. Make user / customer experience part of testing - offer them a preview on iterations so they can see if this helps them to be successful.

Having the right testing strategy for your application is essential. The biggest misconception to avoid here is to aim for code coverage since this usually leads to a large amount of unit testing while neglecting other kinds of tests that might be much more beneficial, such as integration, contract or security tests.

Testing in cloud systems becomes a challenge, specially when we deploy continuously and have a large team, because it is very hard to fully isolate one environment (e.g.: some cloud components do not have a docker emulator) and there are many configurations to the cloud provider that pass unnoticed in unit and integration tests.

I agree with some of the other comments here in that getting the right balance in testing is difficult. I would lean away from heavy handed unit test more in favour of system and integration tests. I have found that following a carefully crafted Test Driven Development approach such that the automates tests are updated prior to feature development help focus the mind of the developers but more critically keeps the test suite up to date.

The biggest problem in Software Industry is testing a service when something changes outside of code. For eg. dynamic config changes which can disrupt the availablility of your high traffic service. 1. For testing and mantaining high availability in events of such changes, create a client testing stack or service which mimics your real customer. 2. Create this Testing service possibly in same tech stack, environment, network scope where your real customers lie. 3. Call your service under test from this test service, every X seconds or minutes and emit success or failure metric. This would give you real time availablility metric and catches problem even before your customer catches it.

Shorter iterations provide groups of developers reasonable targets for completing units of work while acknowledging that, especially in more complex systems, change is inevitable. Cloud computing, like any other type of computing that produces units of software that must integrate seamlessly with other units of software, benefits from the ability to adjust to changing requirements and assumptions in shorter cycles. Sprints can be any length of time that works for a team, often averaging around a month. In this amount of time, individuals can focus on the plans for the current sprint, being somewhat sheltered from the chaos that could ensue from continuous adjustments to those plans, and allows for pivots in the next sprint.

Agile methodologies and test automation go hand in hand since they encourage and enable each other. Well-tested code can be changed in an agile, iterative way, while small, iterative changes can be tested in an automated manner more easily.

Rethinking Agile & Scrum: Is it all hype? These methodologies emerged as alternatives to the rigid waterfall approach, aimed at streamlining processes. But have they become over-marketed buzzwords? Aren't testing, CI/CD, and incremental delivery just common sense in software engineering, practices we've been using long before these terms were coined? Let's focus on outcomes, not labels. What's your take - essential methodologies or common sense with a fancy name?

Agile's focus on collaboration, adaptability, and customer feedback is crucial in a field that's rapidly evolving and highly customer-centric. Implementing frameworks like Scrum, Kanban, Lean, and XP offers a comprehensive approach to managing various aspects of software development. Scrum's iterative process is excellent for quick, incremental releases. Kanban's emphasis on workflow visualization and managing work in progress is key for efficiency. Lean's waste reduction principles and XP's values like simplicity and continuous feedback are vital for creating high-quality, responsive software. Overall, these methodologies align well with the demands of cloud computing, ensuring software that is robust and maintainable.

In addition to the maintenance of the automated test suite, the following feedback mechanisms should be mandatory : - Peer reviews / pair programming - Team retrospectives - Customer/stakeholder demo - Security tests

Here are some best practices to guide you in designing an ERP database for complex reporting and analytics: Work closely with stakeholders to understand reporting and analysis requirements. Normalize the database to eliminate redundancy and maintain data integrity. Create pre-aggregated tables to store summary data. This can significantly improve the performance of complex analytic queries, especially for large datasets. Design the database with scalability in mind. As the volume of data increases, the database should be able to handle the increased load without significant performance degradation. Regularly monitor and tune database performance. Identify and resolve any bottlenecks or performance issues immediately.

The emphasis on seeking feedback and improvement in cloud computing software development is spot-on. It acknowledges the dynamic nature of software engineering, especially in cloud environments, where continuous evolution and adaptability are key. Leveraging diverse feedback sources - from user experiences to peer code reviews - not only enhances the quality and relevance of the software but also fosters a collaborative, learning-oriented culture. This approach, especially the integration of performance metrics and customer insights, is crucial for iterative development and maintaining a competitive edge in rapidly evolving tech landscapes.

It is all about metrics. You should define and monitor on regular basis the metrics of your solution in order to be capable to improve and develop it constantly.

Create monitoring and evaluation patterns for validating software, user and cybersecurity problems continously, analyze those, and create patterns for ML/AI improvement suggestions from software monitoring. After software changes use monitoring and evaluation patterns to validate effectiveness of improvement suggestions and the ML/AI quality.

Cloud computing is great, but it comes with its own bag of challenges. Couple of aspects which are important as per me: 1. Observability(super set of monitoring): be it application, or security, or network, or compliance, or even cost observability. With microservices there is an increased challenges of monitoring a request end to end. That is where 'traces' comes to the rescue (if not everywhere, but at least for synchronous services and somewhat in event driven services) 2. Automate new environments: In the cloud world, we have seen an environment hitting its scale limits. That is where cell based architecture, or dynamically created environments comes handy.

To ensure cloud computing software is testable, maintainable, and capable of improvement over time, consider the following key practices: - Modular, scalable design - Automated testing frameworks - Continuous Integration and Deployment (CI/CD) - Comprehensive documentation - Version control systems (like Git) - Robust monitoring and logging - Regular user feedback integration - Adherence to security best practices - Regular code refactoring - Adoption of microservices architecture (where appropriate)

consider building a monolith. - all your code is in one place - it’s easy to understand - allows a smaller ops team - allows devs to collaborate more - enables quicker iteration as you can change all parts of the system together - removes duplicated process from managing many repos. - uses tested and tried databases with transactional integrity while avoiding the more difficult distributed systems problems. When your team outgrows the monolith, build macroservices: a few select services grouped around the their business domain. In my experience, you’ll never regret building the monolith first, but you’ll likely regret building microservices first.

Depending on the vendor relationship you should either design on top of a 'single' platform and leverage native and integrated services as much as possible, or design in an agnostic way, where you can pivot between vendors and only use 'general' services and abstractions. Depending on the service pricing strategy, you will need to balance trade-offs in your design.

The best thing about cloud computing is that I don't have to manually unplug the server cable, instead I can pay someone to unplug me