architecture and distributed systems, web distributed systems design

Web Distributed Systems

Web Distributed Systems Design

Principles

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.

So , how to start?

Oracle, JBoss, REST, NoSQL, Spring, Clusters, VMware???

Stop, Stop, Stop!!!

Technologies First???

Architecture First !!!

First step-> B2B or B2C???

Business-to-business (B2B) or Business-to-consumer(B2C)?or

B2G(Business-to-government)?

May be O2O? - a new Model for the Developmentof E-Commerce

Online2offline?

Let’s Start

We need architecture which support –Flexibility, Scalability , ManageabilityBut what is Software architecture?

Architecture is the fundamental organization of a systemembodied in its components, their relationships to each

other, and to the environment, and the principles guiding its design and evolution.

A system is a collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product

lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulfill one or more

missions in its environment.

The environment, or context, determines the setting and circumstances of developmental, operational, political, and

other influences upon that system.

A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives.

A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a

system.

A component is a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type, whose conformance is defined by these

provided and required interfaces (encompassing both their static as well as dynamic semantics).

The software architecture of a system or a collection of systems consists of all the important design decisions about the software structures and the interactions between those structures that comprise the systems. The design decisions

support a desired set of qualities that the system should support to be successful. The design decisions provide a conceptual basis for system development, support, and

maintenance. [McGovern]

One component example:MessagingService

SOA!!!Service-oriented Architecture

Principles Of SOA Design

Principles Of SOA Design

Principles Of SOA Design

Principles Of SOA Design

Principles Of SOA Design

Principles Of SOA Design

Principles Of SOA Design

Principles Of SOA Design

Principles Of SOA Design

Principles Of SOA Design

Principles Of SOA Design

Forgot about global data model

Choose Service model

Relations

One RED Wrong Relation

Say no to RED!

Java EE – EJB3.2, JSF2.2, JMSREST

NoSQLSQL

WILDFLY

Technologies?

Slides source: www

Linkedin : https://www.linkedin.com/pub/armen-arzumanyan/4/b24/605Blog: https://armdev.wordpress.com/Github: https://github.com/armdev

E-mail: armen.arzumanyan@gmail.com

Slides author: Armen Arzumanyan

Discover Armenia!

Discover Armenia!

Discover Armenia!

Discover Armenia!

Discover Armenia!

Discover Armenia!

Discover Armenia!

Discover Armenia!

Discover Armenia!

Discover Armenia!

Discover Armenia!

Discover Armenia!