AI eats future of software — Part2
n the previous post, I discussed about core traits of an intelligent software application. You can read the post here.
In summary the intelligent applications will not only take instructions from users but over a period learn and become smart. So the applications transcends from just being a “program” to a “learner”. And then it can start performing tasks proactively instead of reactively, providing unprecedented efficiency boost both in personal and enterprise use cases.
In this follow up post, we will take a deeper look into the important architectural components of such an application.
Architecturally there are four critical pieces of an intelligent software.
A) Sensory block
B) Services Hub
C) Machine learning box
D) Handler block
This is how the rough skeleton looks like:
A) Sensory Block
Sensory block is what users interfaces with while interacting with software. Interactions are not just restricted to clicking or touching an interface. Interactions can encompass transferring structured text, shooting natural language based text or voice, sending images, flashing gestures as users are empowered by newer ways of interacting with machine. With the advent of AI (more specifically natural language processing and image processing) the sensory block of next generation software will support user interactions beyond just touch/mouse click. The development in field of Virtual reality and Augmented reality have also opened multitudes of use cases where users interacts with machine in ways those previously were unthinkable of.
Sensory blocks typically reside on smart or dumb endpoints of the stack. Previously it used to be just mobile devices but with IoT devices proliferating, we can expect to see screen enabled and screen less devices act as sensory blocks of future applications. Smart end points or edge are often in demand (see fog computing) as in many scenarios decisions are required to made by logic residing at the “edge”, saving crucial clock cycles in many mission critical applications.
B) Services Hub
Services hub hosts array of services that are exposed from machine learning models. The models will be part of machine learning box but the service end points will be made available through Services hub. The hub also can host user profile based services, event services and feature services.
Three broad choices for building services hub:
1. Container based
2. Microservices based
3. Serverless/function based
B.1 Container based
Containerization is an OS-level virtualization method for deploying and running distributed applications without launching an entire VM for each application. Instead, multiple isolated systems, called containers, are run on a single control host and access a single kernel. Because containers share the same OS kernel as the host, containers can be more efficient than VMs, which require separate OS instances.
See more on containers here: https://azure.microsoft.com/en-in/services/container-service/
B.2 Microservices based
Microservices have gained tremendous popularity in the last couple of years. Microservices is a variant of the service-oriented architecture (SOA)
architectural style that structures an application as a collection of loosely coupled services (inherently different from 3 tier legacy architecture).
Microservices will be a central theme of next generation of applications. With so much of heterogenous components sitting inside one stack, monolithic approach would hardly make sense. Microservice can give the desired modularity and ability to build applications that can scale. The architecture styles aim to reduce the time to market, allow to handle changing requirements with less effort and to lower the operation costs in environments with larger load.
The functional components of an application can be distributed across microservices that can interact with each other and external modules. For example the face detection micro services can operate separately from user authentication related services.
B.3 Serverless or function oriented
Server less approach is also rapidly becoming a go-to option. This provides a platform allowing the developers to execute code in response to events without the complexity of building and maintaining the infrastructure. Server less signifies, the organization or person doesn’t need to purchase, rent or provision servers or virtual machines to develop the application. That is a huge benefit. The code is guaranteed to have desired performance characteristics without developers explicitly breaking their head on what would be the underlying infrastructure.
Check out Azure Functions for more on this: https://azure.microsoft.com/en-in/services/functions/
How to choose between these three options?
Typically container based approach is more infrastructure oriented. And server less/function based approaches is more programming oriented.
In the next post we will cover the remaining two sections: machine learning box and handler block.
