Application Architecture and Design (and cloud aspects)

 Let's say you work for some organization and there is a need for a new application.  If you are responsible for the architecture / design then 

My initial post was going to end up being a "ancient" IT history book with some extra stuff. I decided that wasn't very helpful - not many people want to read a book in a "blog format".

I'm condensing the content down to the following. 

• Use standard practices for
• project management
• design techniques
• Understand the reasons/basis for soft/hard requirements - This covers why a requirement exist and why a specific requirement was chosen over other similar prospective requirements.
• Examples reasons are;
• development / operational / infrastructure costs
• time to market /  speed of handling requirement changes
• maintainability
• performance / scalability / availability
• Carefully evaluate technology choices.
• Consider the risk of using any technology that could become unsupported before the end of the useful life of your application. New "amazing" technologies may only be around for a short period of time before something new replaces it.
• Make plans to keep 3rd party frameworks, libraries and languages/run-times up-to-date with regard to the most current versions.
• Consider the risk, for example, of using early versions of SpringBoot such as 2.1 which are not maintained now - if a new security flaw comes up, it may be very hard to fix the issue.

With regard to standard practices, use whatever is appropriate for your organization and the project need. Many organizations are trying follow "Agile" practices but that doesn't mean that "Waterfall" is always bad to use. Use what is appropriate for the situation.

Understanding the reasons used for requirement selection helps to keep requirements aligned with each other and provides useful context for handling business changes over time.

Technology comes and goes.  Don't love or hate particular technology - it is a tool.  Use appropriate technology and if needs change then consider more appropriate technology.  Don't select technology just because it is considered "great" by any person or group - consider the positive and negative aspects in-depth for your use-case.  

Small example of considerations - given a service expecting high transaction rates; what technology stacks might be considered and what are the trade-offs?

1. Python
1. Positives
1. Increasingly used in enterprises
2. OpenSource
2. Negatives
1. Library ecosystem isn't as mature as for Java
1. You want a library to help with web requests?  Which option do you pick? What version of Python are you on?
1. https://pypi.org/search/?q=web+requests&page=1
3. Considerations
1. Security
1. https://www.theregister.com/2021/07/28/python_pypi_security/
2. https://medium.com/ochrona/arbitrary-code-execution-during-python-package-installation-3a60990350ef
3. https://snyk.io/blog/python-security-best-practices-cheat-sheet/
2. Some libraries need local compilation
3. Cross-version compatibility
4. Transitive dependency handling
5. Long term maintenance questions
1. https://medium.com/codex/python-4-0-will-never-arrive-3d994dce54f1
6. Runtime aspects
1. Python global lock
1. https://wiki.python.org/moin/GlobalInterpreterLock
2. Memory management - also consider context including containers
1. https://www.askpython.com/python/examples/memory-management-in-python
3. Threading
1. https://docs.python.org/3/library/threading.html
2. Java
1. Positives
1. Heavily used in enterprises
2. Generally has useful features and reasonably performance
3. Many enterprise level libraries and frameworks
2. Negatives
1. New version every 6 months by Oracle can cause some thrashing of work
2. OpenSource vs Oracle licensing
3. Considerations
1. Alternative JDK / JVM / run-times
1. Oracle JRE
2. OpenJDK
3. Azul
4. IBM OpenJ9
5. Eclipse Temurin
6. Amazon Corretto
2. SpringBoot vs JEE
3. Cross-version compatibility
4. Transitive dependency handling

I highly recommend reading about and understanding the runtime aspects of Python. Consider the effects of memory pressure within and across container instances (i.e. Docker, Kubernetes, etc) - especially in a cloud environment and / or where you are cost / latency sensitive. 

Regarding compatibility and transitive dependency handling - I've had people with architect and team lead titles make comments to me along the lines of:

• "Java versions are backward compatible so keeping up with current versions isn't important."
• "We are pinning the SpringBoot version at version 2.3 instead of upgrading to 2.7+ because it improves stability by preventing changes."

I believe these statements reflect some general misunderstandings or lack of knowledge. There are very instances of 100% cross-version compatibility for operating systems or programming languages over significant spans of time. You also have to clarify whether you are talking about things like source code / binary compatibility and forward / backward version compatibility. Try running a bunch of games written for Windows 95 on Windows 11 - how many will work?  In my opinion - likely few.  For operating systems, computer languages and frameworks - features are added and deprecated / removed across releases.  API's change due to needs such as performance, security, new features, etc. If OpenSource is brought up as a solution to these type of issues - I'll claim it isn't reasonable.  There are support matrices for most major OSs, computer languages and library / frameworks - they don't maintain old versions forever. If you are outside a support matrix - you have no guarantee that anything will work and getting help will likely be somewhere between hard and impossible. Needing help for a major security issue or something that breaks a critical system is not the time you want to find out that no one can help you or can't help you quickly. Some common support / compatibility matrices below..

• OpenJDK support matrix from RedHat
• https://access.redhat.com/articles/1299013
• SpringBoot support matrix
• https://spring.io/projects/spring-boot#support
• SpringBoot / SpringCloud compatibility matrix
• https://spring.io/projects/spring-cloud#overview
• Django support matrix / roadmap
• https://www.djangoproject.com/download/
• Nx / NodeJS / TypeScript compatibility matrix
• https://nx.dev/packages/workspace/documents/nx-nodejs-typescript-version-matrix

Thanks,

Scott