Migration Into A Cloud

 

https://pywix.blogspot.com/2020/04/layered-protocols-in-distributed-system.html

////////////////////

The Seven-Step Model Of Migration Into A Cloud | Seven Step Migration | Cloud Computing

The Seven-Step Model Of Migration Into A Cloud | Seven Step Migration | Cloud Computing

The promise of cloud computing has raised the IT expectations of small and medium enterprises beyond measure. Large companies are deeply debating it. The key issues associated with decision makers, architects, and systems managers in trying to understand and increase use of cloud computing for their IT needs.
Some questions arises that are , when and how to migrate one’s application into a cloud; what part or component of the IT application to migrate into a cloud and what not to migrate into a cloud; what kind of customers really benefit from migrating their IT into the cloud; and so on. We describe the key factors underlying each of the above questions and share a Seven-Step Model of Migration into the Cloud. Typically migration initiatives into the cloud are implemented in phases or in stages.

• Assessment:-

The first step of the iterative process of the seven-step model of migration is basically at the assessment level. These assessments are about the cost of migration as well as about the ROI that can be achieved in the case of production version.

• Isolating:-

The next process step is in isolating all systemic and environmental dependencies of the enterprise application components within the captive data center. This, in turn, yields a picture of the level of complexity of the migration.

• Mapping:-

After isolation is complete, one then goes about generating the mapping constructs between what shall possibly remain in the local captive data center and what goes onto the cloud.

• Re-Architect:-

Perhaps a substantial part of the enterprise application needs to be re-architected, redesigned, and re-implemented on the cloud. This gets in just about the functionality of the original enterprise application. Due to this migration, it is possible perhaps that some functionality is lost.

Related Other Post

• Cloud Computing Introduction
• Vision of Cloud Computing
• Service Oriented Architecture
• Fault Tolerance in Cloud
• Cloud Characteristics
• Cloud Service Model
• Grid Computing

• Augment:-

In the next process step we leverage the internal features of the cloud computing service to augment our enterprise application in its own small ways.

• Validate:-

Having done the augmentation, we validate and test the new form of the enterprise application with an extensive test suite that comprises testing the components of the enterprise application on the cloud as well. These test results could be positive or mixed.

• Optimization:-

In the latter case, we iterate and optimize as appropriate. After several such optimizing iterations, the migration is deemed successful
XXXXXXXXXXXXXXXX

Migration Risks:-

The biggest challenge to any cloud migration project is how effectively the migration risks are identified and mitigated. In the Seven-Step Model of Migration into the Cloud, the process step of testing and validating includes efforts to identify the key migration risks. Migration risks for migrating into the cloud fall under two broad categories:

• the general migration risks
• the security-related migration risks.

In general migration risk we address several issues including performance monitoring and tuning. On the security front Issues include security at various levels of the enterprise application as applicable on the cloud in addition to issues of trust and issues of privacy.

///////////////////////////

Goals of distributed system

Goals of distributed system:-

 Just because it is possible to build distributed systems does not necessarily mean that it is a good idea. After all, with current technology it is also possible to put four floppy disk drives on a personal computer. It is just that doing so would be pointless. In this section we discuss four important goals that should be met to make building a distributed system worth the effort. A distributed system should make resources easily accessible; it should reasonably hide the fact that resources are distributed across a network; it should be open and it should be scalable.

1.Making Resources Accessible:- 

The main goal of a distributed system is to make it easy for the users (and applications) to access remote resources, and to share them in a controlled and efficient way. Resources can be just about anything, but typical examples include things like printers, computers, storage facilities, data, files, Web pages, and networks, to name just a few. There are many reasons for wanting to share resources. One obvious reason is that of economics. For example, it is cheaper to let a printer be shared by several users in a small office than having to buy and maintain a separate printer for each user. Likewise, it makes economic sense to share costly resources such as supercomputers, high-performance storage systems, image setters, and other expensive peripherals.

                However, as connectivity and sharing increase, security is becoming increasingly important. In current practice, systems provide little protection against eavesdropping.

2.Distribution Transparency:-

An important goal of a distributed system is to hide the fact that its processes and resources are physically distributed across multiple computers. A distributed system that is able to present itself to users and applications as if it were only a single computer system is said to be transparent. Let us first take a look at what kinds of transparency exist in distributed systems. Types of Transparency The concept of transparency can be applied to several aspects of a distributed system, the most important ones shown in Fig. 1-2.

The conclusion is that aiming for distribution transparency may be a nice goal when designing and implementing distributed systems, but that it should be considered together with other issues such as performance and comprehensibility. The price for not being able to achieve full transparency may be surprisingly high.

3.Openness :- 

Another important goal of distributed systems is openness. An open distributed system is a system that offers services according to standard rules that describe the syntax and semantics of those services. For example, in computer networks, standard rules govern the format, contents, and meaning of messages sent and received. Such rules are formalized in protocols. In distributed systems, services are generally specified through interfaces, which are often described in an Interface Definition Language (IDL). Interface definitions written in an IDL nearly always capture only the syntax of services. In other words, they specify precisely the names of the functions that are available together with types of the parameters, return values, possible exceptions that can be raised, and so on. The hard part is specifying precisely what those services do, that is, the semantics of interfaces. In practice, such specifications are always given in an informal way by means of natural language.

                Another important goal for an open distributed system is that it should be easy to configure the system out of different components (possibly from different developers). Also, it should be easy to add new components or replace existing ones without affecting those components that stay in place. In other words, an open distributed system should also be extensible. For example, in an extensible system, it should be relatively easy to add parts that run on a different operating system. or even to replace an entire file system. As many of us know from daily practice, attaining such flexibility is easier said than done.

4.Scalability:- 

Worldwide connectivity through the Internet is rapidly becoming as common as being able to send a postcard to anyone anywhere around the world. With this in mind, scalability is one of the most important design goals for developers of distributed systems. Scalability of a system can be measured along at least three different dimensions . First, a system can be scalable with respect to its size, meaning that we can easily add more users and resources to the system. Second, a geographically scalable system is one in which the users and resources may lie far apart. Third, a system can be administratively scalable, meaning that it can still be easy to manage even if it spans many independent administrative organizations. Unfortunately, a system that is scalable in one or more of these dimensions often exhibits some loss of performance as the system scales up.

////////////////////////////

Layered protocols in distributed system

Layered protocols in distributed system

Due to the absence of shared memory, all communication in distributed systems is based on message passing. When process A wants to communicate with process B,PYit first builds a message in its own address space. Then it executes a system call that causes the operating system to fetch the message and send it over the network to B. Although this basic idea sounds simple enough, in order to prevent chaos, A and B have to agree on the meaning of the bits being sent.
                Many different agreements are needed. How many volts should be used to signal a 0-bit, and how many volts for a 1-bit? How does the receiver know which is the last bit of the message? How can it detect if a message has been damaged or lost, and what should it do if it finds out? How long are numbers, strings, and other data items, and how are they represented? In short, agreements are needed at a variety of levels, varying from the low-level details of bit transmission to the high-level details of how information is to be expressed. To make it easier to deal with the numerous levels and issues involved in communication, the International Standards Organization (ISO) has developed a reference model that clearly identifies the various levels involved, gives them standard names, and points out which level should do which job. This model is called the Open Systems Interconnection Reference Model, usually abbreviated as ISO OSI or sometimes just the OSI model.
                        An open system is one that is prepared to communicate with any other open system by using standard rules that govern the format, contents, and meaning of the messages sent and received. These rules are formalized in what are called protocols. Basically, a protocol is an agreement between the communicating parties on how communication is to proceed. The OSI model distinguishes between two general types of protocols. With connection-oriented protocols, before exchanging data, the sender and receiver first explicitly establish a connection. When they are done, they must release (terminate) the connection. The telephone is a connection oriented communication system. With connectionless protocols, no setup in advance is needed. The sender just transmits the first message when it is ready. Dropping a letter in a mailbox is an example of connectionless communication. With computers, both connection-oriented and connectionless communication are common. In the OSI model, communication is divided up into seven levels or layers, as shown in Fig. 2-1. Each layer deals with one specific aspect of the communication.
                            In the OSI model, when process A on machine 1 wants to communicate with process B on machine 2, it builds a message and passes the message to the application layer on its machine. This layer might be a library procedure, for example, but it could also be implemented in some other way (e.g., inside the operating system, on an external coprocessor chip, etc.). The application layer software then adds a header to the front of the message and passes the resulting message across the layer 6/7 interface to the presentation layer. The presentation layer in turn adds its own header and passes the result down to the session layer, and so on. Some layers add not only a header to the front, but also a trailer to the end. When it hits bottom, the physical layer actually transmits the message, which by now might look as shown in Fig. 2-2. When the message arrives at machine 2, it is passed upward, with each layer stripping off and examining its own header. Finally, the message arrives at the receiver, process B, which may reply to it using the reverse path. The information in the layer n header is used for the layer n protocol.

The Physical Layer:-

The physical layer is concerned with transmitting the Os and 1 s. How many volts to use for 0 and 1, how many bits per second can be sent, and whether transmission can take place in both directions simultaneously are key issues in the physical layer.

The Data Link Layer:-

The physical layer just sends bits. As long as no errors occur, all is well. However, real communication networks are subject to errors, so some mechanism is needed to detect and correct them. This mechanism is the main task of the data link layer. What it does is to group the bits into units, sometimes called frames, and see that each frame is correctly received. The data link layer does its work by putting a special bit pattern on the start and end of each frame, to mark them, as well as computing a checksum by adding up all the bytes in the frame in a certain way. The data link layer appends the checksum to the frame. When the frame arrives, the receiver recomputes the checksum from the data and compares the result to the checksum following the frame. If they agree, the frame is considered correct and is accepted. It they disagree, the receiver asks the sender to retransmit it.

The Network Layer:

On a LAN, there is usually no need for the sender to locate the receiver. It just puts the message out on the network and the receiver takes it off. A widearea network, however, consists of a large number of machines, each with some number of lines to other machines, rather like a large-scale map showing major cities and roads connecting them. For a message to get from the sender to the receiver it may have to make a number of hops, at each one choosing an outgoing line to use. The question of how to choose the best path is called routing, and is the primary task of the network layer. The problem is complicated by the fact that the shortest route is not always the best route.

The Transport Layer:-

Packets can be lost on the way from the sender to the receiver. Although some applications can handle their own error recovery, others prefer a reliable connection. The job of the transport layer is to provide this service. The idea is that the session layer should be able to deliver a message to the transport layer with the expectation that it will be delivered without loss. Upon receiving a message from the session layer, the transport layer breaks it into pieces small enough for each to fit in a single packet, assigns each one a sequence number, and then sends them all.

The Session Layer:-

The session layer is essentially an enhanced version of the transport layer. It provides dialog control, to keep track of which party is currently talking, and it provides synchronization facilities. The latter are useful to allow users to insert checkpoints into long transfers, so that in the event of a crash it is only necessary to go back to the last checkpoint, rather than all the way back to the beginning.

The Presentation Layer:-

Unlike the lower layers, which are concerned with getting the bits from the sender to the receiver reliably and efficiently, the presentation layer is concerned with the meaning of the bits.

The Application Layer:-

The application layer is really just a collection of miscellaneous protocols for common activities such as electronic mail, file transfer, and connecting remote terminals to computers over a network

////////////////////////////

Service Oriented Architecture | SOA Architecture

Rahul Gupta-February 18, 2021

Service-Oriented Architecture (SOA)

• Service-Oriented Architecture (SOA) is an architectural approach in which application is develop using the services that are available on the internet.
• Services are provided to form application through internet.

Difference between SOA and web services:-

Service Oriented Architecture, as the name says is an architectural concept which focuses on having different services communicating with each other to carry out a bigger job. Thus, a web service is a basic building block in a SOA. When multiple services are combined, we have an application that falls under SOA.


Best example would be any big application which uses Amazon Web Services where you have distinct server instances for your business logic, data hosting and load balancing requests. Each instance provides its own unique service like load balancer distributes load, business logic transforms user input and processes it with its logic which in turn provides this transformed data to database instance for storing. Now if you look at how services work, you might have realized that data can be transformed when it enters each unique service. Thus, interfacing is most important aspect here and we use it in the form of APIs. Such architecture helps us modularize our application so that we can easily swap out certain services without affecting the whole application. So if service is a component, then SOA is the bag which holds such multiple components.

Example :-

Google Docs

(Google docs is a application , when we use this application it provide us several other services such as spell checker and other)

Advantages of SOA:

• Service reusability:- In SOA, applications are made from existing services. Thus, services can be reused to make many applications.
• Easy maintenance:- As services are independent of each other they can be updated and modified easily without affecting other services.
• Platform independent:- SOA allows making a complex application by combining services picked from different sources, independent of the platform.
• Availability:- SOA facilities are easily available to anyone on request.
• Reliability:- SOA applications are more reliable because it is easy to debug small services rather than huge codes
• Scalability:- Services can run on different servers within an environment, this increases scalability

Disadvantages of SOA:

• High overhead:- A validation of input parameters of services is done whenever services interact this decreases performance as it increases load and response time.
• High investment:- A huge initial investment is required for SOA.
• Complex service management:- When services interact they exchange messages to tasks. the number of messages may go in millions. It becomes a cumbersome task to handle a large number of messages.

There are two major roles within Service-oriented Architecture:

• Service provider:- The service provider is the maintainer of the service and the organization that makes available one or more services for others to use. To advertise services, the provider can publish them in a registry, together with a service contract that specifies the nature of the service, how to use it, the requirements for the service, and the fees charged.
• Service consumer:- The service consumer can locate the service metadata in the registry and develop the required client components to bind and use the service.

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////

////////////////////////////