L02 What is Software Architecture?
4 likes•1,261 views
The document discusses software architecture, notably emphasizing Conway's Law and its implications in organizational design and technical debt. It compares monolithic architecture with service-oriented and microservice architectures, highlighting the challenges of scaling and deploying applications, as well as the necessity for clear terminology and definitions in software engineering. Additionally, it covers the benefits and drawbacks of various architectural approaches and the importance of layering in managing complexity.
L02 What is Software Architecture?
- 1. HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015 L02 WHAT IS SOFTWARE ARCHITECTURE?
- 2. Agenda Conway’s Law Architecture in the Post-PC world Technical Dept Architecture Scaling Applications Service Oriented Architecture Layering
- 3. Reading Brown 1-7 Pattern: Monolithic Architecture Conway´s Law Decomposing applications for scalability and deployability The Scale Cube
- 4. Conway’s Law
- 5. Conwey’s Law Organisations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations From a 1967 paper “How do Committees Invent?” by Mel Conway
- 6. Conwey’s Law In an organisation with three departments you end up with three parts of the software applications Due to communication and power structure - people want to control their schedule and not depend on others Directly leads to technical dept This leads to the saying: “There are not technical problems, only management problems”
- 7. Architecture in the Post-PC world
- 8. Monolithic Architecture Traditional Web Application Architecture All code is built into a single application that is deployed Simple to develop, test, deploy, scale Clear layering: Presentation, Domain, Data Source Tomcat ApacheBrowser WAR Web Components Customer Wallet Data Source DB WAR file = Web ARchive Tomcat = web server for Java Servlets (web components)
- 9. 9 Trends in Architecture Traditional Web Application Architecture using “monolith” is not a bad way to build software However, some things become hard in this architecture with scale and frequencies of changes Demand today is very much agile The monolithic architecture becomes a problem in particular in scaling and organising teams
- 10. Chris Richardson Decomposing Applications for Scalability and Deployability
- 12. Monolith Architecture Bookstore UI Accounting Payment Shipping SQL Web Browser Web Server Apache
- 13. ▪ Benefits – Simple to understand – Straightforward to develop and test – One release and deployment – All linking is a compile type – Scaling is simple - just duplicate the system and use a load balancer Monolithic Architecture
- 14. Monolithic Architecture ▪ Drawbacks – User interface challenge – old style UI architecture – Real-time applications (like node.js) don’t fit in easy – Obstacle to frequent deployment – fear of change – Overloads your IDE and container – slow build, development – Obstacle to scaling development teams – Locks down the technology stack – long term commitment
- 15. Demand for Rich Interactive User Experience Web based request response model is fine for normal content However for dynamic and interactive experience, for example streaming events to the browser this becomes difficult From Richardson’s video
- 16. Big Deployments Need to redeploy the whole application for small changes Any change requires knowledge of the whole system Deployment becomes risky Need lots of planning Become infrequent due to fear Code waits a long time before its deployed From Richardson’s video
- 17. Container Overload Overloads your IDE Takes long time to start the containers Slows down development From Richardson’s video
- 18. Communication Overload Changes in component might affect other components Unwanted dependencies happen - technical dept Teams need to plan and coordinate From Richardson’s video Scaling the development becomes difficult
- 19. Stuck with the Technology Stack Monoliths require long term commitments to the stack New technology is difficult to adopt Different problem domains require different stack From Richardson’s video Any changes in the technology stack become difficult
- 20. Can Result in Technical Debt Maintenance becomes difficult People don’t want to work on the code Company is not competitive System becomes obsolete Cost of Change (CoC) becomes too high
- 21. Technical Dept
- 22. Big Ball of Mud “A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and- baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair.” — Brian Foote and Joseph Yoder, Big Ball of Mud
- 23. Technical Debt Concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution Small decisions that accumulate over time - “I’ll fix this later” Hard to see until any small change is extremely expensive (CoC = Cost of Change), and then Conway’s Second Law applies If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on
- 25. Why does it Happen? Lazy programmers? Sloppy programmers? Inexperienced programmers? No power to say no?
- 26. Source: Baruco 2012: Micro-Service Architecture, by Fred George https://www.youtube.com/watch?v=2rKEveL55TY Fred George Micro-Service Architecture
- 28. Good design and architecture turn out to be not so good Using the wrong tools Shortcuts - “I’ll just inherit this class and change a method” Calling methods you should not call It was a good idea at the time, for example God Objects Bad organisational structure (ignorance of Conway’s Law) No ownership of code No restrictions - “we’re agile, anybody can change any code” Lack of understanding of the design of the code Code guidelines and principles forgotten or do not exist Putting code in wrong place due to lack of understanding Why does it Happen? Other reasons:
- 29. Why does it Happen? Or maybe… University Teachers that teach about concrete inheritance Object Oriented progamming is good but can be misused
- 30. Conwey’s Second Law There’s never enough time to do something right, but there’s always enough time to do it over
- 31. Architecture
- 32. Problem with Software Engineering People see the same thing differently or have the same opinion on different things The results are that people that really agree, don’t agree and people that agree, do not really
- 33. Problem with Software Engineering This leads to bad design and implementations Result is technical debt
- 34. Clear Up a Few Things Terminology needs to be defined People must have the same understanding of terms used Define and document We work in a complex industry - sometimes its good to ask “what do you mean when you say X”
- 35. Architecture Means different things to different people Big picture, things difficult to change, a plan, a blueprint…
- 36. Architecture - noun The decomposition of a product into a collection of components/modules and interactions Structure
- 37. Architecture - verb Understanding what you need to build, create a vision and making the right decisions vision
- 38. A component is a software building block that is independently replaceable independently upgradable Component
- 39. Types of Architecture There are many different architectures ★ Network, security, data, hardware, enterprise… All have structure and vision ★ All have multiple constraints such as cost, time, legal, regulatory
- 40. Application Architecture Application is the focus ★ Contains classes, components, design patterns, frameworks, libraries Lower-level aspects of software design ★ Concerned with sign technology stack and layering Technology stack Layering Client REST service EJB Hibernate Oracle Presentation REST service Service Layer Domain Layer Data Layer
- 41. System Architecture ▪ Focus on multiple applications across a number of tiers and technologies ▪ Interactions between applications ▪ Overall structure of the end-to-end software system at high-level ▪ Mix of software and hardware
- 42. Software Architecture ▪ The combination of application and system architecture ▪ Includes the technical practices to build the software – Design Principles, Programming language Design patterns, Unit testing and much more… ▪ Must also include aspects like – Cross-cutting concerns such as logging and exception handling Security, Performance, Audit Requirements, constraints, and much more…
- 43. Enterprise Architecture ▪ How the enterprise is broken up in groups/departments ▪ Business processes used ▪ Workflows used ▪ May not look at technology in detail rather how to us technology across the organization to get work done
- 44. Agile Architecture ▪ Agile refers to a methodology of building software – moving fast, embracing change, release often, feedback cycles etc. ▪ Does agile development team then build agile architectures? ▪ Agile architecture means it can react to change, is easy to change, is extendable
- 45. Agility ▪ Agility means you can use the OODA loop How Spotify builds products Observe Orient Decide Act
- 46. Which of the following architecture descriptions would be concerned with interactions between applications A) Application Architecture B) System Architecture C) Software Architecture D) Enterprise Architecture QUIZ
- 48. Monolithic Architecture Traditional Web Application Architecture All code is built into a single application that is deployed In today’s environment might not be the best approach Tomcat ApacheBrowser WAR Web Components Customer Wallet Data Source DB
- 50. Scaling Applications In the Internet world you want to build web sites that gets lots of users and massive hit per second But how can you cope with such load? Browser HTTP Server Application Database
- 51. Scale Cube X scaling: duplicate the system Z scaling:Partition the data Yscaling:PartitiontheApplication
- 53. Trends in Architecture Service Oriented Architecture (SOA) dates back to mid 1990s Web Services meaning XML and SOAP using an Enterprise Services Bus Confusions on terminology SOA is overload term - useless Means different things to different people Implies Web Services using SOAP
- 54. Trends in Architecture SOA as in Web Services using SOAP
- 55. Bezos’ Mandate (from Yegge’s Rant) 1. All teams will henceforth expose their data and functionality through service interfaces 2. Teams must communicate with each other through these interfaces 3. There will be no other form of interprocess communication allowed 4. It doesn't matter what technology they use 5. All service interfaces, without exception, must be designed from the ground up to be externalizable. No exceptions. 6. Anyone who doesn't do this will be fired.
- 56. Service Oriented Architecture SOA actually means that components of an application act as interoperable services, and can be used independently and recombined into other applications. Engineering Software as a Service by David Patterson and Armando Fox
- 57. Microservices In recent years a new term has emerged, Microservices: The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. From the Lewis & Fowler article
- 58. Martin Fowler - Microservices https://www.youtube.com/watch?v=2yko4TbC8cI Martin Fowler Microservices
- 60. Definition of SOA is useless because it is so overloaded Microservice architecture is better but needs to be clarified Service Architecture
- 61. Service Oriented Architecture Software Architecture where all components are designed to be services Applications composed of interoperable services Easy to build new services, easy to change Parts of the systems need to change more than others
- 62. Single Responsibility Principle (SPR) states that a class should have one and only one reason to change, that “reason to change” is its responsibility.
- 63. Monolith Architecture Bookstore UI Accounting Payment Shipping SQL Web Browser Web Server Apache
- 64. Service Architecture Bookstore Service Account service Payment service Shipping service Bookstore UI Web Browser
- 65. Partitioning the Monolith into Services From http://www.manning.com/rotem/SOAp_SampleCh01.pdf Arnon Rotem-‐Gal-‐Oz’ SOA Patterns figure 1. One way is to go from Object soup to Services along domain seams to microservices
- 66. Microservices or microapps ▪ Each service can be around 100-200 LOC (lines of code) – Size not the deterministic factor – Don’t fix it – rewrite it ▪ Microservice can have embedded web server – Totally independent
- 68. Drawbacks
- 70. Which statement is not true about SOA? A) SOA does not affect performance B) No service can access other service data except using APIs C) SOA improves productivity though reuse D) Monoliths system must deploy all components QUIZ
- 71. Layering
- 72. Layering • Software systems can get complicated • Abstractions are needed • Layering provides abstraction by separating computer systems in layers • Higher layers use services from lower layers • Each layer has dedicated tasks and hides complexity from upper layers
- 73. Benefits of Layering • You can understand a single layer as a coherent whole without knowing much about other layers • You can substitute layers with alternative implementation of the same basic service • You minimize dependencies between layers • Layers make good places for standardization • Once you have a layer built, you can use it for many higher- level services
- 74. Downsides ▪ Layers encapsulate some, but not all, things well – Cascading changes – For example adding a field in the UI requires changes on each layer ▪ Extra layers can harm performance – At every layer things typically need to be transformed from one presentation to another
- 75. The Three Layers ▪ Presentation – User’s interface to the system – User can be another system – Accepts input, displays views ▪ Domain – The Application of the system – The “Business logic” – Tends to creep into presentation and data source ▪ Data Source – Connection to the database – Also Persistence
- 76. Summary Conway’s Law explains a lot Architecture in the Post-PC world means scaling Big complex system can accumulate Technical Dept Architecture defined How to Scale Applications What is Service Oriented Architecture Layering is the oldest trick in the book