2012/08/16

One cell is a tissue



When the first cell of a tissue starts, we already have a tissue, this tissue does not have some expected characteristics like resiliency and fault tolerance, but implements some basic services needed for tissue grow.

To one cell be started is should have at least three parameters available:

  • the tissue name, to join to an specified tissue, or an empty tissue name to join the first tissue it founds.
  • the cell name, to identify itself , this name maybe tissue generated in the time of tissue registration.
  • the tissue DNS servers, the IPv4 or IPv6 address to the DNS that provides tissue services name resolution:
    • the DNS servers could be provided by three ways
      • command line at cell startup
      • cell.xml configuration file.
      • broadcast on local network work DNS query (like DHCP broadcasting)
Cell startup general steps:
  • if a cell starts and cannot locale the tissue DNS in any way and have a tissue name defined it assumes being the first cell in the tissue and:
  • starts the tissue catalog service
    • this services holds the catalog of services and ip addresses where are running
  • starts the tissue DNS service
    • this service queries the catalog to resolve hostnames for services (where the service is running)
  • starts the tissue DHCP service
    • this service listens for broadcast queries for tissue DNS service, specific or not and answer with the DNS IP address.
  • the cell looks a hostname called dna.<TissueName> to reach the tissue catalog service.
  • when the cell have a tissue catalog service available it registers itself in the tissue
    • it provides information about itself 
  • once registered the tissue provisions all cell services to the cell, and ask the cell to start them all.
  • services the any cell should have:
    • cell self monitoring service.
    • cell tissue DNS pooling against tissue catalog service.
    • cell tissue ask for change service.
  • once with core services up and running the cell is able to receive queries about the ability to receive tissue services.
    • the tissue can ask the cell for external resource accessibility, like databases and application servers or even being in and specific network segment.
    • the tissue can deploy service code to the cell, enabling the to receive that service instances.
    • the cell can receive temporary services to help the tissue to achieve the minimum service level requirements.

2012/08/07

The tissue computing and ubiquitous computing

With the dynamic behavior of tissue computing another "by design" feature is to use very different devices for processing services. In one side we can have cell phones as clients or using components that are integrated with the tissue, like identity or single sign on agents or XACML PEPs, or one tight integrated agent for any kind of service (the tissue does not force any kind of client software but protocols like HTTP, STMP or other proprietary protocols). In other side we can rent anonymous machines processing power, in private set of machines or in a public set of machines.

Renting processing power example:

Imagine that one government geographic system needs to calculate the area from many polygons. This is a massive processor computing task, instead of allocate a high performance machine to do this task a tissue of area calculating services can be allocated to do this work, this tissue can be located inside a department desktop machines or over the internet, the requests can be done in a way that do not exposes sensitive data to the service. With a simple relation between number of polygons and the medium time to calculate each one is possible to calculate how many cells is needed to reach a response time for the whole task. Many other activities can be done in this way, like CERN experiments processing or geological information processing (there is already many examples working). This creates the possibility of people renting its home desktop and internet connection while not at home and earn money with this and in other hand peak demands being resolved without acquiring more processing power to the computing environment.

The bigger concern is about data security over anonymous processing power rental, but this I will talk about in another message.


2012/08/04

The tissue computing and processing capacity management

The problem:

From the firsts centralized, "dumb" terminal based interfaces to the actual cloud computing with rich interfaces almost everything changed, interfaces, database software, operating systems, computer architecture layers, communication protocols, but in my point of view the big change is how users have access to the system functionality. In older mainframes someone that wants to run a program and receive the output as a printed list, should submit a batch request and way for free machine time to run, forms are written in paper sheets and then typed into system screen by computing skilled people. With the evolution of technology, part of the computing power goes to the user desktop, with client-server architecture but it still need software installed in his machine by some skilled person, this takes time and generates complexity in the environment and now we have the HTTP protocol that change radically how user obtain access to some system, he just need a network connection and a very generic software, one internet browser software.

So the mainframe architecture provides a very predictive demand planning, only those connected terminals can generate processing demands on the server, with the "opening" of the systems more users can easily reach the system and use it when it needs, this, in the user point of view is much better than job schedulers, but to the administration point of view generates lots of problems, with one internet open system is no more possible predict how many users will use the system in certain point of time, how much processing power will be needed to handle all requests, a concept of capacity planning becomes more and more important. Companies that handle with global customers does anymore nightly maintenance, always is day somewhere.

Proposed solution:

The tissue computing paradigm addressed this problem by design, the idea of a system that grow by demand and learn with his own history, ensures that the management of processing capacity is no more a (humans) system administrations but a system function, the tissue should be able to detect and react or forecast and prevent processing shortage and processing wastage situations.

Using this approach for system paradigm is feasible use big datacenters and rent resources for many tissues that coexists time-sharing resources as needed. Some classical cases that this is very useful are season changing behaviors like hotel systems and commerce system just before Christmas. Or some "sun following" systems that have more usage while this in its timezone and less while night.

The key features to solve this question are service migration, service scaling and service high availability in the  tissue.