Within the computer industry it is sacrilege to call a technology to be a game changer. The game changers are claimed everyday but seldom live more than a couple of years.

Some game changers, have been true to their name and have fundamentally changed the IT industry. This include microprocessors, which revolutionised and changed the direction of computer industry by bringing the ability to compute to the common masses. Another technology that had a similar impact is RDBMS. RDBMS removed the guesswork of how to choose a database and became and remained a standard for years to come. The internet, the web and other technologies have made similar impact.

This brings us to a little known PhD thesis “Architectural Styles and the Design of Network-based Software Architectures” by Roy Fieldings which came out in 2000. This dissertation defined a framework for understanding software architecture via architectural styles and demonstrated how styles can be used to guide the architectural design of network-based application software.

The web and http by its very nature are scalable, reliable and simple to use. Further the hardware, network and design by its very nature exists. It is only obvious to expose services over web using web standards. This is simply REST.

The author derives an analogy between REST and RDBMS, both have identical approach towards simplicity and provide similar set of problems. The problem of computer science has always been that of modelling data, algorithms and processes are usually a solved problem.

In design of a database it is normalization and creation of entities that is more of an art form while CRUD operations are standardised. On similar lines it is design of entity structure that is the complex piece; formation of nouns in the design space that is a challenge, once URI’s and resource representation is fulfilled, the remainder is simple operations like CRUD of a database.

It is the author’s opinion that REST is successful for the same reasons RDBMS are, they bring standardization towards sharing resources and processes. It naturally is decentralised and scales as web scales. Further most IT infrastructure allows http(s) hence REST needs no special privileges.

REST is a simple architecture pattern with most client systems allowing http access no special libraries or structures. It is allowed on both mobile and web leading to ease of consumption.

Some design principles of true REST are difficult to achieve for example from the original paper of Roy Fielding-

“communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.”(sic)

Most applications have a concept of a session and not all requests contain information for fulfilment.

Many clients do not allow PUT and DELETE verbs and some firewalls disallow them, which required creative solutions (for example X-HTTP-METHOD-OVERRIDE).

Further workflows don’t fall cleanly into the process of REST whose primary purpose is to expose resources over web.

As the article started with REST being a game changer, the author believes the same to be true and primarily because it has such a large usecase for implementation.

The shift to the cloud has brought about several solutions that make doing business easier. Whether it be cost savings, added flexibility or ease of use, companies are offloading workflows to the cloud and maintaining a competitive advantage.

It would not be an exaggeration to remark that cloud is one of the cornerstones that allowed the startup revolution.

In this article we will try not to discuss the benefits or cloud or define what cloud is, unless you have been living under a rock you surely know how wonderful the cloud is. We intend to highlight the scenarios that are not applicable for usage of cloud. All technologies have a place and something as wide as cloud computing has a large problem space, however there exist scenarios where cloud may not be applicable and under those circumstances it is prudent to use the proper tool and not blame the tool as poor craftsman.

#1 Software License

Clouds are best suited for open source deployments and this allows easy scaling out at a moments notice. This scenario changes when products like licensed databases or other proprietary softwares are used. The licenses prohibit such scale out leaving the cloud to be just another data center with licensing costs and cycles coming into picture. Under such scenarios it may not be prudent to use cloud. If the said software is available from vendor in their cloud, available on the cloud as PAAS (Platform as a Service), it should be considered. However using PAAS software has its own issues as described in the next point.

#2 Using PAAS software

One of the largest benefits of cloud is the PAAS software availability. Both open source and vendor specific technologies are available in a PAAS model. They have the benefit of being managed, aspects like daily backups, obtaining relevant statistics and even tuning are easily available and for a startup this means lower cost of staffing.

PAAS software can have potential issues like vendor lock-in if they are not available on other platforms. Similarly it can be hard to move large databases out of a cloud.

#3 Long term cost issues

Cloud obviously has a low cost of entry. Shared costs allow low cost of ownership to start with, there are no commitments to servers and billing can be as low as hourly, platforms may scale out or scale up on demand and for short durations during spikes.

However as predictability comes in and costs add up, cumulative cost of operating a cloud can be large.

A good strategy would be to plan long term move to data center.

#4 Data Security and Regulations

While cloud are secure but they may not follow all regulations, sometimes it is required that data resides in application providers data center. At times data may not be allowed to cross borders, these and many other regulations cause issues in using cloud. Odd strategies can come in place such as keeping data and application in separate physical data centers leading to issues that would be discussed in upcoming sections.

#5 VPN to a data center

At times clouds require access to applications within private data centers, to provide required layer of security the access is done over VPN. This however is a flawed strategy. In an increasingly microservice driven world it is prudent to access applications residing anywhere, but VPN is not necessarily the best approach. VPN’s tend to be slow and at times unreliable. They further need infrastructure and internal routers to be setup which can in a cloud only be done using software. This increases overall complexity and requires a team of network engineers to manage the application and should be avoided.

Prudent solutions to this case include building security over the application and exposing it over services. When such access is to be done over to consume a database, the challenges increase, under such scenarios it is recommended to not use cloud and deploy the application in a datacenter sitting next to a DB.

#6 Applications not designed for cloud

Cloud is designed to scale out, however many applications are not designed to scale up. At times products or softwares are not designed for cloud or the underlying system may not be available. Suitable precautions should be taken before committing to cloud.

Individuals have been known to build VM’s inside cloud VM’s, that is a strategy to fail.

Cloud like any tool has a set of use cases and when used in an unintended manner will only cause sorrow.

In the technical world, non-technical founders risk being seen as unqualified especially when dealing with matters related to technology. While there are many success stories of tech founders ( Google. Facebook, Amazon), there are also other companies which have succeeded without techie founders. Take the case of former English teacher Jack Ma & Alibaba; neuroscientist Rashmi Sinha who founded SlideShare, and product design student Evan Spiegel who created Snapchat.

When working with technology partners, you need to keep in mind that the success of a project depends more on you as funder than vendor. You need to be clear in your head. Ideas are seldom clear in the first go, they need multiple iterations to be finalized. As a founder remember you have an idea but it is not concrete so do not lose patience, on the other hand if a vendor informs he has understood everything after the first discussion, just walk away.

You should further educate yourself on concepts like waterfall, agile, risk

With this basic understanding that explains some aspects of being a successful founder let us get into top aspects to watch out for when looking for a technology partner.

#1. Own your source code, email and environments

Source code is your intellectual property and should remain with you. You as founder need to have complete control over it and be an administrator of the same, this allows you to change vendors at will remove access and be in absolute control. Similarly own the hardware, domain names (read website names), certificates(SSL) and others. These items and more should be paid by your credit cards and you should have commercial rights on them just as you would have on any trade mark.

Beware of deals too good to be true, avoid vendors who say they will manage and own everything in a package, these deals eventually milk you.

Further ensure you are the administrator on all these systems and your email id is the primary email on these systems. Amazon provides free hosting for small size environments for a year, this can reduce costs

Ensure you sign a contract along with a handshake and those clearly spell out that items like source code, environments etc will be your IP.

Readup on github, jira, godaddy, amazon AWS.

Go informed, go smart in discussions.

#2. Evaluate multiple technology options

“When the only tool you have is a hammer then all problem look like nails”

Technology is just a tool and you need to ensure your craftsman knows how to use more than one tool. Run away from shops that insist that there exists only one option for development. Ask for technology options, understand the design choices and short term and long term benefits and costs of each option along with risks.

You may not understand all the options but you could judge if the vendor does. Individuals who are one technology shops often fail in their projects, this is because may not use the best tool for the job.

Right choice of technology goes a long way to success.

#3. Steer away from WordPress, Magento & other in the box vendors

Ask yourself a basic question, as a startup are you not challenging the models of business, are you not building something new and something never done before? If that is true why would existing software and technologies work for you.

 This would imply heavy customization and unintended use of these platforms will be done and will lead to issues down the line.

It should be understood vendors who are incompetent building a solution from scratch and rely upon prepackaged solutions will not be able to run with you to new horizons.

#4. Understand commercial models

There exist various models of execution such as fixed bid where scope is fixed and risks are owned by vendor and time and material bid where you buy hours to get the job done. Ask for commercial proposals for both. It needs to be understood that software development is an art and contains many risks. Fixed big costs also incorporate cost of the risks a vendor who doesn’t understand these models and there differences has no experience in building systems.

#5. Fortnightly demos and define payment milestones

Once you are in a stage where scope is closed insist on a plan that allows fortnightly deliverables that may be demoed and be available for you to test. This will allow you to have private beta starting early on rather than something coming up later. This will also also allow you to give feedback and learn. Once these fortnightly sprints are tied to costing, pay up when the deliveries are met.

#6. Demand to understand project risks and issues on a weekly basis

Projects don’t slip by a month on last day, they slip one day at a time. This is a principle we have lived by. We have further learnt risks and issues when managed in time can have minimal impact on a project. Finally all projects have risks and issues, it’s just a question of managing them. Have risk and issues meetings every week this will allow finding and resolving them early on. If a vendor is not raising concerns then perhaps they are not managing them.

#7. Build a QA practice and tie payment milestones to them

Learn more about QA practices and learn to define bug priority. Insist on acceptance criteria based on bugs and have the vendor stick to them. Tie fortnightly payment milestones to the said acceptance criteria. This will ensure you have a greater predictability on product delivery.

#8. Have the team work from your site

Close collaboration is key to success, inistit that team works from your office with you.

#9. Estimate the project yourself

Instead of thinking prices are too high try an estimation exercise. Insist on detailed proposals and time taken for project with number of team members and their experience and skills. Then go find salaries of said people with given experience. Do a calculation and add a profit markup. If the vendor is not earning a decent profit they will not deliver your project.

The global robotic process automation (RPA) market is expected to reach $22 billion by 2025, according to a new Forrester report. Let’s look at how the technical and business aspects of RPA which makes it the new dominant technology in town and strictly stay away from ethical aspects around labour force reduction.

Robotic Process Automation is the use of software robots, or “bots,” to automate repetitive, rules-based tasks within or between computer systems. These tasks are rule-based and usually done manually, so RPA serves the goal of automating operations.

The bots perform this work through existing user interfaces, so there is no need to construct original software integrations. RPA hence is different from other automation technologies such that it is a client side technology and not a server side technology working against user interface and not server api’s. This allows use of existing technologies with no change.

The Technology Behind RPA

The software used to create the bots is called a RPA authoring tool. RPA authoring tools expose application UI model as interactable interface to author user workflow.

Although RPA is marketed as an end user and is designed to replace human interaction with computer it requires some degree of skill to customize and define a flow. This is especially true to build the tool that cater to error scenarios, configurability and high level abstractions, because end users are seldom trained for abstract computer modelling.

Attended RPA vs. Unattended RPA

A RPA bot can be attended or unattended, which depends on the use case. Attended bots require some level of human intervention. They are often used in the front office and work alongside human workers and can still be triggered by system events.

Unattended RPA bots, on the other hand, do not need human intervention to complete their tasks and can be triggered by system events or programmed to run on a schedule. These bots works on enterprise data behind the scenes on back-end servers.

Why RPA

With a better grasp of what RPA is and what skills are needed, we attack where in an organization would RPA be helpful. RPA may be used to do any repetitive task that a human does for example

• Downloading and sending reports in an email
• Copying files from a remote location
• Reset passwords on requests
• Doing repetitive manipulation for example in a spreadsheet
• Automating QA

While RPA tools allow simple decision making and flow control they are not currently suited for areas that require creative input or high level of intelligence.

RPA journey begins with business defining process and a detailed workflow with errors and exceptions and scenarios. The process is then automated using an RPA tool. RPA tools depending upon features allow to be installed and used across central databases. They may be scheduled and time shared for example during business hours the RPA tool may respond working a HRMS while late at night may work on end of day process and closing.

As RPA tools work against existing applications there is no need to reconfigure or do any development for the same. Existing application may continue to work as is. This brings to the notion that a RPA software is different from other applications as it consumes or uses existing applications.

What are the Benefits Of RPA?

RPA delivers value to any business by:

• Boosting Productivity : RPA allows employees to focus on high value tasks that only they can do while leaving the repetitive task to be managed by the bots.
• Improve Efficiency to Generate Savings : With RPA speeding up processing times and reducing costly errors, processing costs decline and per-employee output increases.
• Hit Accuracy Goals with Reliable Consistency : Achieving 100% error-free data accuracy is within reach by automation eliminating errors on repetitive tasks
• Better Business Data Security : RPA provides opportunities for reducing the number of human touches businesses require to process personal information keeping the data secure.
• Creating Opportunities for Scale: RPA is a particular advantage in workflows with irregular volume, with RPA ability to scale up and down instantly to handle any volume of work.
• A Better Customer Service Experience: Customer service is a high-maintenance, high-commitment process that requires a large amount of time and attention from employees. By spending less time on rote administrative tasks, staff can turn their attention back to customers.

The computer user interface has perhaps been the most frustrating aspect of technology adoption since the dawn of the computer age. Humans had to adapt to using a computer. Operators have moved from punch cards to keyboards, and mouse and finally arrived at a touch interface.

However, all such experiences required us to do something unnatural and the choice is guided and limited by how the application wishes the user to behave.

The new style of user interaction will not be an evolution of the usage of human hands but a revolution in how humans interact with computers and the good news is this is available today and now as commercially available technologies out of research labs. It now depends only on our will to exploit this.

In this article, we discuss consumer technologies and systems available to design what is possible today and something like surgical implants into cognitive processing.

This article forms an introductory discussion on the upcoming concept of Artificial intelligence. This article is not a discussion aimed toward various tools, techniques, and available technologies for AI but defines what intelligence is and how one could identify artificial intelligence.

The core of this article is around defining intelligence and the Turing test. The article also brushes topics around intelligence vs consciousness and concludes with an understanding of general AI.

Most of this article will involve thought experiments and present postulates on the case of machine intelligence.

Let us start with an argument presented in the book “Pensées Philosophiques” by “Denis Diderot” “If they find a parrot who could answer to everything, I would claim it to be an intelligent being without hesitation.”

If this argument is to be extended to machines would a machine that would answer everything as a human being would be intelligent?

If this is intelligence then is human and computer intelligence the same or is computer intelligence a simulation? Vs Is a human brain a computer?

Would a machine have consciousness and would it be able to feel? Is consciousness required for intelligence?

A final aspect to interpret intelligence is around dualism, it debates if the mind or intelligence is physical or if it has non-physical components.

These questions remain largely philosophical and are open to interpretation. They remain as yet unanswered and open to large interpretations.

Allen Turing was one of the first pioneers in the field of machine intelligence with a belief in intelligence being physical. He proposed “If a machine behaves as intelligently as a human being, then it is as intelligent as a human being”

This brings us to the definition of an intelligent machine vis A machine that can solve all problems a human can, this also forms the scope of artificial intelligence. To achieve this one needs to precisely define all aspects of learning and other features of intelligence so that a machine may be able to simulate it.

While the above definitions bring us a step closer to comparing machine intelligence and human intelligence they lack precise mechanisms for comparing the same.

Allen Turing in a paper in 1950 reduced the problem of defining intelligence into a simple question of conversation. The essence of this test is if a human interrogator is talking to either a human or a computer behind closed screens and is unable to distinguish between the human and the computer then the said computer is intelligent.

The consequence of this paper essentially boils down to if a machine can answer to a human as another human would then it may be considered intelligent.

One of the top criticism of the Turing test is the Chinese room test

Let us assume there exists a computer program that accepts input in Chinese and produces a response in Chinese. It further is capable of passing the Turing test and the interrogator believes that the response is from an intelligent human.

However, the question posed by the Chinese room test is does the computer program understand Chinese or is it simulating understanding of Chinese? If the machine understands Chinese then it is a Strong AI and if it doesn’t then it is a Weak AI.

This argument may be further extended to a human, let us assume that we replace the machine with a human being with an infinite library of all possible questions in Chinese with their answers, if such a human were to obtain a request and map it an appropriate answer, would such a human possess an understanding of Chinese? This brings the question of intelligence vs understanding.

There are further arguments towards the program itself in the Chinese test, what if the program in question maps and codes every neuron in a Chinese brain? Human intelligence works with a limited capacity however building programs executing such simulations virtually has infinite capacity. Would intelligence require functioning in limited capacity and resources?

While multiple arguments for and against have been made for this test for example

• Why should intelligence be defined in terms of human capabilities and limitations, should intelligence not be larger than human capacity?
• Human intelligence is driven by experience, instincts, and the unconscious mind that doesn’t follow any rules.
• The Turing test is unable to distinguish intelligence as defined by babies or children.

At the next level of the debate are Artificial consciousness and Artificial self-awareness. There is active research being done on these subjects however the subject material is beyond the scope of this article.

We wish to end this discussion to form a distinction between specialized AI and general AI. Systems such as machine learning and deep learning produce what is known as specialized AI. These systems are good at one thing they are trained to do for example playing chess or classification of images. Such a system would require to be retrained for a new class of problems.

Artificial General Intelligence is a creation of machine intelligence that could do anything that a human can do. This would involve capabilities to solve a large class of problems. This is an active area of research and requires an understanding of human intelligence before it may be synthesized.

In the world we live in computer technology is expanding at an unprecedented rate and doesn’t seem to slow down. Concepts old and new, from labs and the theoretical world, are making into mainstream consumer computing.
One such concept borrowed from the mainframe world is containers and it has taken the tech world by storm. In this article we explore containers.
To understand the concept of containers let us start with the concept of virtualization. Virtualization in terms of computer technology is the ability to create a virtual instance of a resource which might be hardware, device, operating system, and so on. This ends up covering a very large class of items that include virtualization of hardware in form of hypervisor (virtual machines) such as Oracle VirtualBox, abstract computers such as JVM and .net CLR, LPARs (dividing resources in a mainframe), and virtualizing the OS in form of container
On the face of it, these technologies may seem similar but they are not.
A Hypervisor essentially is a mechanism to virtualize the hardware. When one chooses a hypervisor they create virtual disks, CPUs, network interfaces, and others. These constitute the virtual machine. The virtual machine in turn hosts an operating system which in turn hosts the applications. Hypervisors can be of two types, Type1 or bare hypervisor run directly on the hardware. Type 2 Hypervisors require a host operating system to be installed and run on the same.
While Hypervisor try to share resources of underlying computers by providing virtual options, they still use the instruction set that of a raw machine. This allows standard software to run as is. Abstract computers like JVM or CLR essentially run inside an OS and provide a completely different instruction set than provided by the raw hardware. They are essentially programming models allowing software development to be friendly.
LPAR or logical partition is a mechanism is a technique to logically divide and provide resources of a mainframe. This allows virtualized separate computers that may host separate operating systems.
Containers are a bit different, while all the previous techniques tried to virtualize the hardware and as consequence had to install a copy of the operating system on each virtual computer. Containers virtualize the operating system. This mechanism of virtualization has many benefits.
Although we may continue our discussion in areas of various virtualization technologies, however, we would keep our interests only in the area of containers, specifically Docker.
Containers is operating system level virtualization. This is a mechanism in which the OS kernel allows the existence of multiple isolated user-space instances. They may feel like a real OS from the point of view of the container or the virtual instance but the OS will manage any competing resources. For example, each container would feel it has access to a root directory but in reality using chroot each container would be in a separate directory.
A visible consequence of this for example starting a docker container hosting tomcat
docker run -it –rm -p 8888:8080 tomcat:8.0
This means run tomcat, and we know tomcat by default runs on port 8080. While we are mapping it to port 8888 on a real machine. While in hardware virtualization no such mapping is required.
This allows multiple instances of containers to run within one OS each mapping physically to a different port.
Containers have several benefits over traditional Hypervisor. The most visible being each instance of a VM does not require a separate installation of an operating system. This in turn can save the cost of resources because memory and CPU footprint comes down, reducing the licensing cost of software like OS, antivirus, etc. This also speeds up the startup and shutdown process for no complete OS boot sequence is required. This makes launching a container an operation of a matter of single-digit seconds while VMs are in order of minutes.
Containers bring their own unique set of challenges such as the need for load balancers that can work on applications across different ports.
While in the VM world if one of the VM’s OS failed it did not bring down other instances and the use of Type 1 Hypervisor (standard in commercial cloud providers) minimizes the risk of an entire physical machine coming down. However with containers, if OS comes down, it may bring down multiple containers.
Containers like VMs require resource management and allocation to ensure no starvation occurs.
To improve the reliability of containers instances should be distributed across the separate physical OS. Multiple mechanisms exist to manage this for example CoreOS a distributed Linux OS manages containers across separate physical instances.
While containers provide very low overhead, however, one should not jump into them blindly. VMs allow a degree of isolation across machines which containers will not users managing containers would have access to all containers on a machine. Databases tend to be an area where containers seem to be hard to manage. Having that said containers are the future and are here to stay.
Enterprises should start investing in containers and take the first steps they took for VMs and clouds. This transition would however need a mindset change where DB, application, and network team would need to trust each other.
I would like to end this discussion with a quick discussion of how containers would make the deployment process seamless and in line with leading DevOps practices.
The primary benefit of a container is that guarantees configuration and software across instances. For example, a Tomcat 8 container with JDK 8 would be guaranteed across environments. There would be no instance of configuration mismatch. One could use this based image and modify it with an application of choice.
From a development and deployment strategy, the build process would prepare a container and the said container image will be deployed.
Before we finally leave this discussion we drive our discussion on a different tangent. Virtualization till now has been limited to servers, however as it stands new techniques now exist to virtualize the mobile ecosystem. This would mean a single mobile phone could have multiple mobile VMs running on them. This has far-reaching benefits such as having one phone for both homes and working with different images. Similarly, the development and testing of mobile devices can be brought down by building against a VM and having it deployed on any hardware.
Container virtualization is here to stay so start preparing!