As tried to keep connected to the social media platforms in light of the Ugandan government shutdown possibly based on basic filters, I also accessed google search engine through the same approach. Interestingly after returning the search results, google was so confused because it kept asking me to refill the CAPTCHA (an acronym for “Completely Automated Public Turing test to tell Computers and Humans Apart”). Indeed google failed miserably to tell that I was a human being so they refused to load any link to the search results.
Then I tried gmail to access the emails, they also presented the CAPTCHA. Still google was not very sure, so they asked me to unlock my Techno F6 Phone! And I did before I could access the mail. So how did they know that I own a Techno F6 Smart phone? How did they confirm that I had unlocked it? And how much else do they know?
As an IT professional and expert at that, I am aware of some of the answers. I access gmail through my Techno Phone, so google took the liberty to keep all this information. Each time, I unlock the phone, google get to know, because the gmail application contacts them.
I don’t want to suspect that because Techno F6 is an android phone and google are the developers of android, then google might have extra tricks built in the android operating system it self.
If you think this is a simple subject, then follow the links for extra information
1,861 total views, no views today
Over the last couple of years, there has been renewed energy in the subject of service oriented architectures. The invention of term ‘micro services’ has warranted a immense interest in the subject of service oriented architectures.
Despite the initial contention on the difference between SOA and the already mature Component Based Software Engineering (CBSE), there is consensus that SOA improves the key attributes of software such as agility, cost to market, flexibility, inter-operability and many others. A service in SOA is now understood as an autonomous software unit that can be used programmatically across the network. Services can interact regardless of the underlying technologies for as long they expose their interfaces for use by other entities.
The size of a service — how much functionality can be bundled into a single service unit is a issue of design left to programmers and software architects. Of course services are compositional – i.e. two or more services may be combined into a new service in its own right. Practice and programmatic recommendations suggest that a service should bundle a business functionality. And SOA in is traditional form has been largely conceived to be applicable at the business level.
Microservice advocate a new way of building systems with more fine grained service units. Simple low-level core functionality can now be exposed as services for use in building high-level systems. A micro service may be as large as a function in a functional language or method in Object oriented Language. Microservices should not be equated to functions or methods because a service is an architectural unit.
Whereas micro services raise the level of flexibility, they increase the number of ‘moving’ parts – each service is autonomous, deployeable in an independent process. This comes with well known challenges of distributed computing. Obviously we have come to learn that in software architecture there is need for trade-offs. It may be very hard to optimize both flexibility and reliability.
The level of granuality and new usage scenarios for microservices, require new support tools for designing, monitoring, provisioning, management of microservice based systems.
2,850 total views, no views today