Architecture

Design/Architecture questions

1) How much distributed is the system? (Traffic Manager/Load Balancer)

2) Is it sync/async

3) Cache can be used?

4) Data is relational/non relational?

5) Authentication

6) Availability, Consistency, Scalability of UI/service layer

7) Backup strategies

8) Network-public/private/hybrid? – for each components

9) UI strategies, complexities

10) Notifications/report generations/analysis?

11) Crosscutting concerns – performance, logging

12) Database scalability, Partition tolerance, DR, Availability, Consistency4

 

Scaling:

http://highscalability.com/blog/2014/5/12/4-architecture-issues-when-scaling-web-applications-bottlene.html

 

Architectural frameworks:

TOGAF / Zachman / FEA / Gartner

 

EAI(Enterprise Architecture Integration) patterns:

http://www.enterpriseintegrationpatterns.com/patterns/conversation/

http://www.enterpriseintegrationpatterns.com/patterns/conversation/Lease.html

Ex: Lease used in Blob storage type

 

Architecture patterns:

https://www.safaribooksonline.com/library/view/software-architecture-patterns/97481491925409/part00.html

 

Distributed Architecture case study on image store:

http://www.aosabook.org/en/distsys.html

 

Application Architecture guidelines:

https://msdn.microsoft.com/en-us/library/ff650706.aspx

 

Application architecture guide Layer Diagrams:

https://visualstudiogallery.msdn.microsoft.com/237f823c-45b4-4f1f-b9e2-607fe66eaae7/

 

Polyglot persistence:

https://msdn.microsoft.com/en-us/library/dn271399.aspx

 

How MVC WebApi works:

https://msdn.microsoft.com/en-us/library/dn313276.aspx

 

Parallel Programming:

https://msdn.microsoft.com/en-us/library/ff963553.aspx

 

Claims-aware MVC app using WIF:

https://msdn.microsoft.com/en-us/library/hh291061(v=vs.110).aspx

 

Scalable web architecture and distributed systems – Principles of distributed system design:

http://www.aosabook.org/en/distsys.html

 

TOGAF study:

http://www.togaf.info/togafSlides91/TOGAF-V91-Sample-Catalogs-Matrics-Diagrams-v3.pdf

 

Cloud architecture for multi-tenant apps

https://msdn.microsoft.com/en-us/library/hh534482.aspx

 

Multi-tenancy challenges:

Partitioning, Extensibility, Provisioning, Testability and Customization

 

Convert ASP.Net MVC to Angular with WebAPI:

https://www.codeproject.com/Articles/1033076/Integrating-AngularJS-with-ASP-NET-MVC

 

Library vs Framework:

A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

 

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by sub classing or by plugging in your own classes. The framework’s code then calls your code at these points.

 

What is CGRA?

Coarse Grained Reconfigurable Architecture. CGRAs consist of an array of a large number of function units (FUs) interconnected by a mesh style network. Register files are distributed throughout the CGRAs to hold temporary values and are accessible only by a subset of FUs. The FUs can execute common word-level operations, including addition, subtraction, and multiplication. In contrast to FPGAs, CGRAs have short reconfiguration times, low delay characteristics, and low power consumption as they are constructed from standard cell implementations. Thus, gate-level reconfigurability is sacrificed, but the result is a large increase in hardware efficiency.

 

From <http://cccp.eecs.umich.edu/research/cgra.php>

Fine­grained vs. Coarse­grained reconfigurable architectures:

 

Tuple space:

A tuple space is an implementation of the associative memory paradigm for parallel/distributed computing. It provides a repository of tuples that can be accessed concurrently. As an illustrative example, consider that there are a group of processors that produce pieces of data and a group of processors that use the data. Producers post their data as tuples in the space, and the consumers then retrieve data from the space that match a certain pattern. This is also known as the blackboard metaphor. Tuple space may be thought as a form of distributed shared memory

 

From <https://en.wikipedia.org/wiki/Tuple_space>

 

Space based architecture:

Space-Based Architecture (SBA) is a software architecture pattern for achieving linear scalability of stateful, high-performance applications using the tuple space paradigm. It follows many of the principles of representational state transfer (REST), service-oriented architecture (SOA) and event-driven architecture (EDA), as well as elements of grid computing. With a space-based architecture, applications are built out of a set of self-sufficient units, known as processing-units (PU). These units are independent of each other, so that the application can scale by adding more units. The SBA model is closely related to other patterns that have been proved successful in addressing the application scalability challenge, such as shared nothing architecture (SN), used by Google, Amazon.com and other well-known companies. The model has also been applied by many firms in the securities industry for implementing scalable electronic securities trading applications.

 

3From <https://en.wikipedia.org/wiki/Space-based_architecture>

 

Secrets of Space Based Architecture

 

 

 

Key principles influencing large distributed systems:

Below are some of the key principles that influence the design of large-scale web systems:

• • • Availability: The uptime of a website is absolutely critical to the reputation and functionality of many companies. For some of the larger online retail sites, being unavailable for even minutes can result in thousands or millions of dollars in lost revenue, so designing their systems to be constantly available and resilient to failure is both a fundamental business and a technology requirement. High availability in distributed systems requires the careful consideration of redundancy for key components, rapid recovery in the event of partial system failures, and graceful degradation when problems occur.
    • Performance: Website performance has become an important consideration for most sites. The speed of a website affects usage and user satisfaction, as well as search engine rankings, a factor that directly correlates to revenue and retention. As a result, creating a system that is optimized for fast responses and low latency is key.
    • Reliability: A system needs to be reliable, such that a request for data will consistently return the same data. In the event the data changes or is updated, then that same request should return the new data. Users need to know that if something is written to the system, or stored, it will persist and can be relied on to be in place for future retrieval.
    • Scalability: When it comes to any large distributed system, size is just one aspect of scale that needs to be considered. Just as important is the effort required to increase capacity to handle greater amounts of load, commonly referred to as the scalability of the system. Scalability can refer to many different parameters of the system: how much additional traffic can it handle, how easy is it to add more storage capacity, or even how many more transactions can be processed.
    • Manageability: Designing a system that is easy to operate is another important consideration. The manageability of the system equates to the scalability of operations: maintenance and updates. Things to consider for manageability are the ease of diagnosing and understanding problems when they occur, ease of making updates or modifications, and how simple the system is to operate. (I.e., does it routinely operate without failure or exceptions?)
    • Cost: Cost is an important factor. This obviously can include hardware and software costs, but it is also important to consider other facets needed to deploy and maintain the system. The amount of developer time the system takes to build, the amount of operational effort required to run the system, and even the amount of training required should all be considered. Cost is the total cost of ownership.

 

From <http://www.aosabook.org/en/distsys.html>

 

Proxy and collapsed forwarding:

 

 

Four architectural styles:

• • 1. Layered architecture
    2. Event-driven architecture
    3. Micro kernal architecture
    4. Micro services architecture

 

Core considerations for better architecture:

• • 1. Overall agility
    2. Deployment
    3. Testability
    4. Performance
    5. Scalability
    6. Development
    7. Complexity
    8. Loose coupling

 

Sharding pattern:

https://msdn.microsoft.com/en-us/library/dn589797.aspx

 

Some key design aspects:

scaling

performance

resilience

backup strategy & DR

maintainability

complexity

loose coupling

deployment

development

testability

 

Reservation system case study:

http://www.ibm.com/developerworks/rational/tutorials/ar-designpat1/

 

Arhitectures:

Patterns   Action Domain Responder

 

 

Pros of MVC

• • 1. Controller not tightly coupled with views and models
    2. Unit Testing is easy

 

MVP:

• • 1. Only way presenter interacts with View is through a View interface. There is single view to single presenter that is possible.
    2. Don’t trust classes, use interfaces only for View interface. View must let the presenter tell what to be done. View lets presenter knows of any events it received.
    3. Presenter tells view and model objects what to do. Also handles events.

 

Architecture:

https://www.safaribooksonline.com/library/view/software-architecture-patterns/9781491925409/part00.html

 

API Registry:

http://wso2.com/blogs/architecture/2014/07/api-registry-and-service-registry/

 

Key Design Principles of Software Architecture:

Abstraction, Encapsulation, Cohesion, Coupling, Complexity

Separation of Concerns

SRP

Principle of Least Knowledge

Don’t repeat Yourself

Minimize upfront design

Design Practices:

 

https://msdn.microsoft.com/en-us/library/ee658124.aspx

 

MVVM:

WPF MVVM Step by Step ( Windows Presentation Foundation)

 

 

Diff between MVC, MVP and MVVM:

MVC,MVP and MVVM: A Comparison of Architectural Patterns

 

 

 

3 dimensions to scaling

 

In this model, scaling an application by running clones behind a load balancer is known as X-axis scaling. The other two kinds of scaling are Y-axis scaling and Z-axis scaling. The microservice architecture is an application of Y-axis scaling but let’s also look at X-axis and Z-axis scaling.

X-axis scaling

X-axis scaling consists of running multiple copies of an application behind a load balancer. If there are N copies then each copy handles 1/N of the load. This is a simple, commonly used approach of scaling an application.

One drawback of this approach is that because each copy potentially accesses all of the data, caches require more memory to be effective. Another problem with this approach is that it does not tackle the problems of increasing development and application complexity.

Y-axis scaling

Unlike X-axis and Z-axis, which consist of running multiple, identical copies of the application, Y-axis axis scaling splits the application into multiple, different services. Each service is responsible for one or more closely related functions. There are a couple of different ways of decomposing the application into services. One approach is to use verb-based decomposition and define services that implement a single use case such as checkout. The other option is to decompose the application by noun and create services responsible for all operations related to a particular entity such as customer management. An application might use a combination of verb-based and noun-based decomposition.

Z-axis scaling

When using Z-axis scaling each server runs an identical copy of the code. In this respect, it’s similar to X-axis scaling. The big difference is that each server is responsible for only a subset of the data. Some component of the system is responsible for routing each request to the appropriate server. One commonly used routing criteria is an attribute of the request such as the primary key of the entity being accessed. Another common routing criteria is the customer type. For example, an application might provide paying customers with a higher SLA than free customers by routing their requests to a different set of servers with more capacity.

Z-axis splits are commonly used to scale databases. Data is partitioned (a.k.a. sharded) across a set of servers based on an attribute of each record. In this example, the primary key of the RESTAURANT table is used to partition the rows between two different database servers. Note that X-axis cloning might be applied to each partition by deploying one or more servers as replicas/slaves. Z-axis scaling can also be applied to applications. In this example, the search service consists of a number of partitions. A router sends each content item to the appropriate partition, where it is indexed and stored. A query aggregator sends each query to all of the partitions, and combines the results from each of them.

Z-axis scaling has a number of benefits.

• • • Each server only deals with a subset of the data.
    • This improves cache utilization and reduces memory usage and I/O traffic.
    • It also improves transaction scalability since requests are typically distributed across multiple servers.
    • Also, Z-axis scaling improves fault isolation since a failure only makes part of the data in accessible.

Z-axis scaling has some drawbacks.

• • • One drawback is increased application complexity.
    • We need to implement a partitioning scheme, which can be tricky especially if we ever need to repartition the data.
    • Another drawback of Z-axis scaling is that doesn’t solve the problems of increasing development and application complexity. To solve those problems we need to apply Y-axis scaling.

 

From <http://microservices.io/articles/scalecube.html>

 

 

 

 

http://microservices.io/articles/scalecube.html

 

Diff between Layer and Tier

Logical layers are merely a way of organizing your code. Typical layers include Presentation, Business and Data – the same as the traditional 3-tier model. But when we’re talking about layers, we’re only talking about logical organization of code. In no way is it implied that these layers might run on different computers or in different processes on a single computer or even in a single process on a single computer. All we are doing is discussing a way of organizing a code into a set of layers defined by specific function.

Physical tiers however, are only about where the code runs. Specifically, tiers are places where layers are deployed and where layers run. In other words, tiers are the physical deployment of layers.

 

From <http://stackoverflow.com/questions/120438/whats-the-difference-between-layers-and-tiers>

 

Diff between Enterprise architect and solution architect:

Solution Architect is a project team role that is responsible for the system quality of the solution being delivered to the business. Enterprise Architect is a planning role that is responsible for identifying the future state of an organization’s IT environment and engage wherever and whomever necessary to help guide project team’s to deliver toward it.

 

From <https://blogs.msdn.microsoft.com/gabriel_morgan/2007/09/02/enterprise-architect-vs-solution-architect/>

 

 

 

ADM:

Architecture Development Model

 

The phases of the ADM cycle are further divided into steps; for example, the steps within the

architecture development phases (B, C, D) are as follows:

• • • Select reference models, viewpoints, and tools
    • Develop Baseline Architecture Description
    • Develop Target Architecture Description
    • Perfor m gap analysis
    • Define candidate roadmap components
    • Resolve impacts across the Architecture Landscape
    • Conduct for mal stakeholder review
    • Finalize the Architecture
    • Create Architecture Definition Document

 

What is TOGAF?

The Open Group Architecture Framework (TOGAF) is a framework for enterprise architecture that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture.[2] TOGAF is a high level approach to design. It is typically modeled at four levels: Business, Application, Data, and Technology. It relies heavily on modularization, standardization, and already existing, proven technologies and products.

 

From <https://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework>

 

What is Enterprice Architecture?

Enterprise architecture (EA) is “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes.”[1]

 

From <https://en.wikipedia.org/wiki/Enterprise_architecture>

 

What is Horizontal vs Vertical scaling?

Vertical scaling can essentially resize your server with no change to your code. It is the ability to increase the capacity of existing hardware or software by adding resources. Vertical scaling is limited by the fact that you can only get as big as the size of the server.

Horizontal scaling affords the ability to scale wider to deal with traffic. It is the ability to connect multiple hardware or software entities, such as servers, so that they work as a single logical unit. This kind of scale cannot be implemented at a moment’s notice. From <http://www.thoughtsoncloud.com/2014/04/explain-vertical-horizontal-scaling-cloud/>

 

Zachman Framework: Alternate to TOGAF

 

Design for performance:

https://msdn.microsoft.com/en-us/library/ff647801.aspx

 

Cloud Achitecture Patterns: https://msdn.microsoft.com/en-us/magazine/ee335719.aspx

 

Create architectural diagram for a marketing team which can raise tickets:

 

Case study for Twitter T-Flock:

Case study for Reddit:

https://www.reddit.com/wiki/index

Case study for Facebook TAO:

https://www.usenix.org/conference/atc13/technical-sessions/presentation/bronson

Idempotent Capability

This pattern demands that capabilities or operations are implemented in such a way that they are safe to repeat. From <https://msdn.microsoft.com/en-us/magazine/ee335719.aspx>

 

MVC vs MVP vs MVVM:

MVC,MVP and MVVM: A Comparison of Architectural Patterns

 

 

 

• • 1. Suppose there’s one web site from which we need to create multiple domain urls. How to do?

Use URL Rewriting in IIS. http://weblogs.asp.net/owscott/iis-url-rewrite-hosting-multiple-domains-under-one-site

 

• • 1. Creating business logic – db vs UI. Which is better?

It depends on the operations. If more data can be filtered from db, write them in SPs. Else, if there are more rules based on user inputs, which can restrict certain data from UI to db, restrict from UI itself.

DB horizontal scaling is difficult than UI layers.

It might be confusing to find logic in db, in UI, its easier to find it in BL

 

 

Layer vs Tier

Layer denotes software layers, Tier denotes physical seperation.

 

SOA webinar

https://www.youtube.com/watch?v=1KXKppaOgtY

 

Role of solution architect:

Understands business requirements as provided by Business Analyst

Produces high level solution designs to be fleshed out and implemented by development teams

Identifies existing/legacy components that can be re-used

Identifies new components  that need to be procured/developed

Specifies integration of existing and new components to meet business needs

 

 

Architectural Concepts;

Envision-Software architecture

Model-Design Patterns

Blueprint-Construction and design principles

Inspect-Construction patterns

Nomenclature-Terms to communicate intent

 

Software architecture:

Webserver-pipeline architecture

SOA-Component architecture

Client/server – layered architecture

Single Tier – Monolithic architecture

Cloud – a tier network architecture

 

Design Patterns:

Creations, Structural, Behavioral

Event driven – Observer

Plug-ins – Abstract Factory

Domain/Active Record/Table Module – Layer patterns

Algorithm – strategy

 

Design Principles:

Abstraction, Encapsulation, Cohesion, Coupling, Complexity

 

Construction Patterns:

Inheritance design, Component design, Layered design, Tier design, Delivery methodology, Software architecture erosion/decay

 

Who is Application architect:

Know all core areas, strong in construction patterns

 

Who is Solution/System architect:

Know all core areas, strong in design patterns and principles

 

Who is Enterprise architect:

Know all core areas, strong in architecture pattern and construction

 

Who is Cloud architect:

Know all core areas, strong in architecture, construction & tiers

 

Who is Infrastructure architect:

Construction patterns