Digital Transformation Blogs - Bigdata, IoT, M2M, Mobility, Cloud

Warning: mysqli_query(): (HY000/3): Error writing file 'C:\xampp\tmp\MY6B23.tmp' (Errcode: 28 "No space left on device") in C:\xampp\htdocs\blogs\wp-includes\class-wpdb.php on line 2345

Warning: mysqli_query(): (HY000/1021): Disk full (C:\xampp\tmp\#sql2664_1c28e_f.MAI); waiting for someone to free some space... (errno: 28 "No space left on device") in C:\xampp\htdocs\blogs\wp-includes\class-wpdb.php on line 2345

Warning: mysqli_query(): (HY000/1021): Disk full (C:\xampp\tmp\#sql2664_1c28e_10.MAI); waiting for someone to free some space... (errno: 28 "No space left on device") in C:\xampp\htdocs\blogs\wp-includes\class-wpdb.php on line 2345
Digital Transformation Blogs - Bigdata, IoT, M2M, Mobility, CloudDigital Transformation Blogs - Bigdata, IoT, M2M, Mobility, Cloud

IoT and Microservices Architecture


Warning: mysqli_query(): (HY000/1021): Disk full (C:\xampp\tmp\#sql2664_1c28e_12.MAI); waiting for someone to free some space... (errno: 28 "No space left on device") in C:\xampp\htdocs\blogs\wp-includes\class-wpdb.php on line 2345

Traditional IT architectures have always been upgraded and re-looked at with the advance of technology. The Service Oriented Architecture (SOA) was a term coined by Gartner in the Ninety’s. It was just another name for so many architectures which just meant the technique which decomposed the application functions of a large organization into a set of services which can be interoperated, and which can be accessed through network API’s. It was a pattern that included service as a sheet, where service was an individual functionality. What SOA essentially did was to bring together business users with Information technologies (IT). The SOA brought many advantages – speed, better workflows and extensibility, scope of re-use and longer life of applications.

As technology evolved, specifically with IoT gaining so much of traction, the expectations from the cloud based platforms have changed. Big Data became commonplace and the world started moving towards the API economy. This is where the Classic SOA started showing problems. It started proving to be too complicated, with hundreds of interfaces and impossible to define granularity. There was a need to look at the architecture again. This time it was from the point of view of creating applications that were developed around business domain components and that could be developed, handled and decomposed into services that communicated via APIs and network based messaging protocols. This is where Microservices Architecture was born. It is, in the words of Chris Haddad, VP of platform evangelism at WSO2 and a former Gartner Analyst, “a Business domain first look at the services portfolio” and it was about making SOA work.

The Microservices architecture adds agility to SOA and brings the much needed speed and efficiency when it comes to deployment and modification of systems. Microservices can define the size of a service and the manner in which they talk to other services. Microservice architecture brings in smaller services and lightweight protocols. The principle of the Microservices architecture is akin to the Unix principle “Do one thing and do it well”.

Microservices architecture has several key features that reduce complexity.  Each microservice runs as a separate process. It consists of data driven interfaces that typically have less than four inputs and outputs. Each microservice is self-sufficient to be deployed anywhere over a network as it contains everything that’s necessary for it to operate – libraries, database-access facilities and operating-system specific files. Each microservice is built around a single focused functionality; hence, it is more effective. Development, extensibility, scalability and integration are the key benefits offered by the Microservices architecture.

In microservices architecture, if we want one application to be put on steroids, it can be done without affecting other services. We can just start running this particular service on a stronger hardware. One single microservice can be updated in this architecture, without affecting others…the only condition being that the runtime system supports this. Each microservice in a platform can be developed in a different language – Java, C, C++, Python, etc. Granular governance is possible for each microservice because it has no dependency on another. It can be separately monitored and governed. This architecture de-centralizes data management as each microservice can store its data in a manner that suits it. Microservice architecture supports automation. It is possible to move entire assemblies of microservices from one deployment environment to another just by using the profile settings with a single click. They are far more resilient than traditional applications. This is due to the fact that one single application can be taken out from a bunch of microservices applications, as these are independent of one another.

The microservice architecture has its obvious advantages and that is the reason why so many prominent business and public services like Netflix, eBay, Amazon, the UK Government Digital Service, realestate.com.au, Forward, Twitter, PayPal, Gilt, Bluemix, Soundcloud, The Guardian, etc., just to name a few, have all graduated from monolithic to microservices architecture. Though this is the case, just like there is no perfect plan, there is no perfect architecture. What works under a particular circumstance might become the bottleneck in another.

Usually the microservices architecture eats up more memory. A lot of coordinated effort is needed between different teams in user cases that involve more than one application. This is a problem in itself.  While it brings in flexibility in terms of different programming languages, it also becomes a heady mix of applications some of which is written in a modern language and some in a language that is waning in its usage. Maintaining talent in all these is a huge challenge. This architecture brings in additional complications in terms of testing, network latency and enabling the different microservices to talk to each other.

Cloud-hosted microservices would create an IoT model that’s a collection of services, watch representing a specific function. For example, one set of functions would collect sensors and controllers and make them visible in the form of data rather than devices. The other set of functions could just process that data and apply some rules to that data. Yet another set of functions could fetch in data from 3rd party enterprise systems like CRM/ERP systems.

Microservices also offer a way of scaling the infrastructure both horizontally and vertically giving long term benefits to the IoT deployments. Each of the services can scale based on the needs.

Given the dynamism of deployment and scalability expectations which comes with IoT, Microservices need to become an important part of the overall IoT Strategy.

Post Liked   0

Archives

Categories