Thursday, May 13, 2010
Yet Another Cloud
Early next year the internet giant Yahoo! intends to open source its cloud infrastructure. This infrastructure is described as something between Amazon EC2 and Google App Engine. While Hadoop, Traffic Server and some other projects well known in the community were born at Yahoo! form the basis of a application level scalability the Yahoo! Cloud will provide the missing bits. Rather than offering raw virtual machines as Amazon EC2 does it provides pre-configured containers of server power. Amazon EC2 is identified as IAAS (infrastructure as a service) and Google App Engine more as PaaS (Platform as a Service) it is interesting to see where will Yahoo! Cloud finds its identity. It is also to point out that with this decision Yahoo! is really standing out because neither Google neither Amazon has open sourced their cloud implementation.Google has published a document about Map Reduce which subsequently was the basis for Hadoop. On the other hand there are open source cloud implementations like Eucalyptus project which recently gathered momentum but no one of them has been proven in the scale Yahoo! Data Centers has. From the developer blogs of Yahoo we can see that there are also other projects related to the cloud namely Sherpa and MObStore. Sherpa is scalable key value store similar to Amazon Dynamo and MObStore is analogous to Amazon S3 and Facebook's Haystack. So I am personally really curious to see Yahoo!'s Cloud implementation.
Thursday, April 1, 2010
Day 1, MeeGo
MeeGo Day 1
Yesterday 31st of March was Day 1 for MeeGo. One can download from MeeGo repositories operating system base from the Linux kernel to the OS infrastructure up to the middleware layer. The downloadable images available now will boot from a CD or from a USB stick, but since the MeeGo User Experiences for the usage models are not yet included in today's MeeGo core, these images will boot into terminal.
Intel Atom-based netbooks
ARM-based Nokia N900
Intel Atom-based handset (Moorestown)
These days the market of mobile phones is heavily overcrowded. Among the Android there is also Samsung's Bada, and also Meego. Meego is a product of merging the two linux based projects, one headed by Intel - Moblin and another one headed by Nokia - Maemo. Maemo has completely different ideology than Android which has basically managed UI based on dalvik virtual machine. Meego on another hand is based on native code and the UI layer is based on Qt . In this way Meego is running native apps.
There is a trend that vendors like Nokia and Samsung are trying to make, different platforms, they have similar for developers. This is the case with Nokia Qt which is available on Symbian as well as on Meego. Qt should be available on both platforms and the developers need lower level Symbian specific API's only for very specific activities.
Samsung's Bada on the other hand claims that the operating system kernel could be based on Linux or some real time OS. While real time OS is suitable for the lower end devices, Linux will be installed on higher end. Fortunately this diffenrece is not visible to the application developers as they are working against the SDK.
Let me wish all the luck and success to the people behind this project!
Enjoy the mobility and all the new possibilities created by it!!!
Yesterday 31st of March was Day 1 for MeeGo. One can download from MeeGo repositories operating system base from the Linux kernel to the OS infrastructure up to the middleware layer. The downloadable images available now will boot from a CD or from a USB stick, but since the MeeGo User Experiences for the usage models are not yet included in today's MeeGo core, these images will boot into terminal.
Intel Atom-based netbooks
ARM-based Nokia N900
Intel Atom-based handset (Moorestown)
These days the market of mobile phones is heavily overcrowded. Among the Android there is also Samsung's Bada, and also Meego. Meego is a product of merging the two linux based projects, one headed by Intel - Moblin and another one headed by Nokia - Maemo. Maemo has completely different ideology than Android which has basically managed UI based on dalvik virtual machine. Meego on another hand is based on native code and the UI layer is based on Qt . In this way Meego is running native apps.
There is a trend that vendors like Nokia and Samsung are trying to make, different platforms, they have similar for developers. This is the case with Nokia Qt which is available on Symbian as well as on Meego. Qt should be available on both platforms and the developers need lower level Symbian specific API's only for very specific activities.
Samsung's Bada on the other hand claims that the operating system kernel could be based on Linux or some real time OS. While real time OS is suitable for the lower end devices, Linux will be installed on higher end. Fortunately this diffenrece is not visible to the application developers as they are working against the SDK.
Let me wish all the luck and success to the people behind this project!
Enjoy the mobility and all the new possibilities created by it!!!
Thursday, March 11, 2010
HTTP caching and REST of us.
Imagine you want to create a web service to query some of your domain objects.
Definitely this can be done with SOAP over HTTP.
POST /person HTTP/1.1
If there appears that your application is under heavy load and has many customers it can happen that your application can not handle it. Ofcourse it is very dependent on the design you are using, other techniqeus you are using like second level cache like EhCache or maybe you are using NoSql or mixed solution . Here I will isolate all this points and will focus just on a http path botleneck. This botleneck can be solved by using a caching reverse proxy. BUT!!!
imagine we need to cache the result of the above mentioned query. The proxy needs to check if the HTTP request is a SOAP request and the and then check if it contains the personQuery operation. If it finds this one extract the personId and use it as a key in it's own cache. It appears that this proxy is completely unique and made for specific operation if you change the name of the operation or the ID field or add another operation you will have to change the proxy. In order to use generic proxy all od the operations need to have additional metta information like if they are read-only and what are
their target objects.
Method: READ
Target: example.com/person/1234
Actually this is very similar to standard HTTP operations which would look like
GET /person/1234
Host example.com
It is not a coincidence that HTTP operations are designed for such a great scalability. If you represent web service operations as one of the HTTP verbs you will use this scalability if
you configure properly HTTP reverce proxy.
I have been using these design not only for HTTP but also with ICE (Intenet communication engine) from ZeroC. ICE is modern RPC style midleware similar to CORBA but much more sophisticated
and efficient. Usually you need midleware like ICE if you need fast, scalable, low latency communication with very low memmory footprint. What we have created is a REST style facades and expressed all of the CRUD
operations on a objects trough those BaseFacades. The base facades contains operations similar to the HTTP methods. This way we achieved scalability, caching and flexibility of the midleware
intermediate components. In the next topics I will present how we have using Varnish (HTTP master piece reverse proxy with caching and load balancing capabilities and many more) to achieve scalable
REST services.
Definitely this can be done with SOAP over HTTP.
POST /person HTTP/1.1
If there appears that your application is under heavy load and has many customers it can happen that your application can not handle it. Ofcourse it is very dependent on the design you are using, other techniqeus you are using like second level cache like EhCache or maybe you are using NoSql or mixed solution . Here I will isolate all this points and will focus just on a http path botleneck. This botleneck can be solved by using a caching reverse proxy. BUT!!!
imagine we need to cache the result of the above mentioned query. The proxy needs to check if the HTTP request is a SOAP request and the and then check if it contains the personQuery operation. If it finds this one extract the personId and use it as a key in it's own cache. It appears that this proxy is completely unique and made for specific operation if you change the name of the operation or the ID field or add another operation you will have to change the proxy. In order to use generic proxy all od the operations need to have additional metta information like if they are read-only and what are
their target objects.
Method: READ
Target: example.com/person/1234
Actually this is very similar to standard HTTP operations which would look like
GET /person/1234
Host example.com
It is not a coincidence that HTTP operations are designed for such a great scalability. If you represent web service operations as one of the HTTP verbs you will use this scalability if
you configure properly HTTP reverce proxy.
I have been using these design not only for HTTP but also with ICE (Intenet communication engine) from ZeroC. ICE is modern RPC style midleware similar to CORBA but much more sophisticated
and efficient. Usually you need midleware like ICE if you need fast, scalable, low latency communication with very low memmory footprint. What we have created is a REST style facades and expressed all of the CRUD
operations on a objects trough those BaseFacades. The base facades contains operations similar to the HTTP methods. This way we achieved scalability, caching and flexibility of the midleware
intermediate components. In the next topics I will present how we have using Varnish (HTTP master piece reverse proxy with caching and load balancing capabilities and many more) to achieve scalable
REST services.
Wednesday, March 10, 2010
TEM 2.0
Being the last 4 years involved in TEM (Telecomm Expence Management) business, I see natural step that the industry is moving towards TEM 2.0. The main new point are metrics which are very important part of TEM solution to measure how good is your TEM vendor actually. This video http://www.accelacast.com/programs/gartner_947_cerylion/ related to TEM 2.0 business presented by Gartner and sponsored by Cerilyon presents the actuall evolution points. I am preparing a post to describe my vision on how I see the perfect TEM solution, what technical tools I see using is beneficial, how to solve the biggest problem of TEM actually the handling of enormous amount of data and how to please the customer with your technical solutions. Last but not least I will post my vision for cost reduction by using high quality open source tools and frameworks which are proven in Fortune 2000 companies using them in TEM 2.0 solution. So until then stay tuned :) .
Sunday, March 7, 2010
Subscribe to:
Posts (Atom)
Posts
