The advent of cloud computing has not only geographically expanded the scope of service-oriented architectures (SOA), it also prompted the move towards numerous resource-related applications based in the cloud. Numerous businesses are popping up all over the world to take advantage of this new technology or help users harness it, like this one providing cloud solutions in London. As a result, SOA applications are the ones that can migrate most easily. This does not mean, however, that this migration is automatic.
The concept of SOA has been present for over 10 years. It was born of developers’ desire to create software from reusable components, and the need for companies to customize the behavior of applications in order to optimize employee productivity. The SOA infrastructure is divided into four basic components: Server for processing, OS and middleware storage, a mapping of users and applications, and load balancing. These are the four elements that make up the heart of any IT infrastructure. SOA nevertheless changes the way companies allocate their capacity in each of these areas to optimize availability and performance while keeping control on costs. This balance will depend a lot on the SOA architectural model chosen, and how applications are subdivided into different components and subsequently deployed.
The fundamental difference between a software architecture and “atomic” applications is its subdivision into components. The SOA applications that make good candidates are divided and assembled into functional components to form applications, which has a major impact on infrastructure:
- Each component can use more specialized resources than would entire applications. The SOA applications that perform analysis on a database can separate analytics and database functions into two separate components, one requiring significant computing capabilities, the other seeking the records. This separation can allow the selection of custom-made equipment at lower cost.
- Applications divided into smaller parts add a traffic “horizontal” between components “vertical” traffic between the application and the user. This change in traffic flows affects the data center network design and in particular favors “fabrics” at the expense of hierarchies between switches.
- The components can be replicated to increase their capacity to work. It will in this case use a set of specific tools, applying a set of rules based on cost/performance, will be responsible for assigning tasks to one of the sets of SOA components, allowing load balancing between components.
- The components “close to the user”, can be moved to be closer geographically and located next to the point of activity.
Plus: companies can approach the SOA infrastructure in terms of “resource classes” or a set of storage configurations that effectively support the majority of its SOA components. The number of resource classes depend on the range of SOA components required, but will probably include the following:
- Database servers and interrogation, designed to serve large databases using hierarchical storage principles. They will usually contain very large amounts of additional RAM, flash storage capacity, fast I/O interfaces for disk storage, high-performance network connections and modest computing capacity.
- Calculation servers and analytical designed to perform complex calculations, which will generally contain both memory RAM and a large amount of fast processors, or even possibly graphics processing units (GPU) to accelerate calculation functions.
- Distributed servers, to support the local treatment – creating user interfaces and processing of events. This can be done using microservers using technology ARM devices than on x86 classics.