Introduction:
If a Connected Vehicle could talk, it will say “AV, you complete me!!” Welcome the Connected Autonomous Vehicle world (CAV) where the Connected Vehicle is all about supplying useful information to a driver or to the Autonomous vehicle to help make safer or more informed decisions. CAV has high demands on the exchange of data and files between the connected car on the road, and a variety of scalable and agile services in the backend. This results in a software services life cycle where in which the deprecation and deployment of new services must happen on a frequent basis. To solve these upcoming challenges, a scalable and flexible architecture is required. Choosing Microservices as an architectural paradigm will enable us to achieve scalable and agile CAV backend that provides with increased operational efficiency and code quality.
CAV-Architecture Building Blocks
When it comes to connecting drivers and technology, the auto industry has a longer and richer track record than any other sector. Although turning “connected car” into a significant revenue generator had remained sketchy, its role in the AV (Autonomous Vehicle) world is pivotal and will make the car safer, faster, and more efficient. Furthermore, virtually all autonomous vehicles will require connectivity to ensure that its software services and data sets are current. While the CAV has been the most prominent example of IoT these days, the cars as such are increasingly becoming software driven and the real cloud based IoT developments in the auto industry are happening behind the scenes.
OEMs or the solution provider must address the complexity of behind the scenes software development requirementswith IoT centric use cases in mind. Some of the key points include:
- Scalability: Some software components are more often used and/or more resource intensive than others, resulting efficient ways to replicate specific components necessary.
- Loosely Coupled: Components in major software solutions can quickly become outdated So it is important to find a way of exchanging a component easily without affecting other components
- Reuse: Many projects use similar software features to work within the cloud. So a set of standard services used among multiple projects must be identified.
- Continuous Integration and deployment: Features that are added to a service must be visible at once, so that compatibility with other services can be tested automatically.
- Code quality: The same code is used in different projects. So the demands on software code quality and genericity have increased.
What are MicroServices?
Over the past decade, most applications were deployed using monolithic architecture design principles. This means in an application all modules, libraries, and inter-dependencies that exist in a single code base is deployed and, importantly, scaled as a single unit.
This architecture concept created a significant impediment in the emerging IoT world. For ex: If a small piece of the application needs a change, the whole application has to be compiled, tested and deployed again. This means that all parts of the application have to undergo the software development process even though most of the modules don’t experience any changes. This comes at big costs taking manpower, time and IT resources and in most cases lead to delays. In addition, a monolith makes it difficult to ensure:
- Scalability
- Be Highly Available
- Agile
- Continuous Service Delivery
To meet these challenges the application architecture must change from a big blob of monolith to an architecture design where complex applications are composed of small, independent processes and services, each organized around individual capabilitiesand communicate with each other via language-agnostic Application Programming Interfaces – APIs. This software architecture design pattern commonly called Microservices, where these services are primarily small and focus on completing singular tasks.
In microservices architecture, one single MicroService can be updated and deployed in a stronger hardware without affecting other services. Also each MicroService can be developed and deployed in a different language – Java, C, C++, Scala, Python, etc. Granular governance and decentralized data management where each MicroService label and handle data separately is also possible.
Microservices architecture supports automated, integration with Continuous Integration (CI) and Continuous Delivery (CD) pipelines allowing developers to safely and frequently evolve the application and scale-out to be nearly instantaneous, allowing an application to adapt to changing loads. Their loose coupling also means that each MicroService can scale independently and can move entire assemblies of Microservices from one deployment environment to another there by achieving infrastructure portability
MicroServices in the IoT Automotive World
In an IoT Automotive world the “Things” are most of the times the small machines with their own processor, operating system and sensors and contain some (hard-wired) logic. They can be communicated using some lightweight APIs. They are completely autonomous, run in their own process space and deliver a small service which means a “Thing” is the ultimate incarnation of a MicroServices living inside the car.
Automotive IoT generates certain types of workloads that promote the adoption of MicroServices in a container instead of virtual machines for a lightweight, loosely-coupled deployment. Containers encapsulate discrete components of application logic provisioned only with the minimal resources needed to do their job. Unlike virtual machines (VM), containers have no need for embedded operating systems (OS) and calls are made for OS resources via an application programming interface (API). So when viewed through the lens of IoT requirements both Containers and Microservices have a high degree of relevance to be applied for the future IoT systems design.
When an automobile manufacturer rolls out one or more connected car models, each car may have several user apps (Navigation, etc.), as well as several sensors that upload telemetry data to the manufacturer’s cloud. Also the manufacturer may want to update the software on a frequent basis. In this type of situation we can use containers and microservices and reap the benefits of instantiating one container (container in auto scaling group) per car. Furthermore, the OEM backend can even have one MicroService per individual sensor since the container technology can rise to this challenge, of scaling to hundreds of thousands of cars. If there is one MicroService per sensor, then an intelligent integration infrastructure that manages the telemetry messages and compress them, to optimize message traffic is required, since the communications link between the automobiles and the cloudis limited and is relatively expensive.
Achieving MicroServices
While Microservices are a product of software architecture and programming practices, the potential mistake in developing Microservices is ignoring the impact that Microservices can have on Operations. Microservices architectures typically produce smaller, but more numerous artifacts that Operations is responsible for regularly deploying and managing. These deployments are called microdeployments.In order to accelerate the development and bridge the gap between microservices and microdeployments every OEM must nurture a DevOps culture within the organization. DevOps is not a role. DevOps is a term that describes the mindset and the organizational structures that are required to deeply integrate Development and Operationsfor developing MicroServices based Applications.
At present, many Auto makers including Ford, Mercedes-Benz, and VW are actively adapting Microservices/Container architecture principles in developing IoT enabled apps for their vehicles. So with a bright future on the horizon, let’s welcome the software assembly to the Vehicle Production Assembly Line!!
Authored by-
Ragu Sivaraman, Founder, MacMetry
Ragu Sivaraman was instrumental in launching MacTrac a two wheeler tracking product that augments a rider, a Dealer and/or Fleet provider to manage and monitor motorcycles in real time using tracking device, mobile app and a cloud hosted reporting solution.
