Achieving Cloud Scalability with Microservices and DevOps for Connected Cars: Page 2 of 5

July 14, 2016 // By Tobias Schneider, Elektrobit
Achieving Cloud Scalability with Microservices and DevOps for Connected Cars
The connected car business has high demands on the exchange of data between the car and a variety of services in the backend. To solve current and upcoming challenges, a scalable and flexible architecture and team setup is needed. The paper has its background in the automotive IT industry at Elektrobit (EB) and describes our starting point, challenges and practical experiences. We have chosen microservices as an architectural paradigm in order to be able to replicate granular services for scalability, and to easily replace a deprecated service. For the development and operations of the services, we decided to have one team which is responsible for the backend infrastructure in the cloud. Also a DevOps culture was established. This allows us to deploy services with increased operational efficiency and code quality.
  • component easily without affecting other components (loose coupling).
  • Reuse (T3): Many projects had a similar feature set for software to work with the cloud. For this reason, a set of standard services to be used in multiple projects was identified.
  • Continuous deployment (T4): A feature added to a service must be visible at once, so that the compatibility with other services can be tested automatically.
  • Code quality (T5): The same code shall be used in different projects (T3). Thus, the demands on quality and genericity have increased.

From an organizational point of view, the following points had the strongest impact:

  • Working mode (O1): Is the development in a cloud environment compatible with agile methods, or is another working mode needed?
  • Team Setup (O2): Do the team members have the right skills? Are specialists within the team or specialized teams needed?
  • Self-Service (O3): In cloud computing, an instance or repository must be available at once, so no additional tasks in the process are acceptable.
  • Configuration Management (O4): For every solution in the cloud an infrastructure is set up which needs to be reproducible for quality and control.
  • Cost controlling (O5): The scaling in cloud computing comes with new demands on cost controlling as instances are paid on an hourly basis and services like AWS Lambda [AC15] are payed according to usage.


The microservice architecture is defined as developing an application as a set of small independent services, where each of the services is running in its own independent process [NS14]. Services communicate with some lightweight mechanisms like HTTP [FL14] and are deployed independently [NS14]. The key reason to decide on an architecture based on microservices was the ability to replicate on demand across servers [FL14], which targets directly requirement T1.

The possibility to exchange components easily
without affecting other components is of vital importance
in a cloud environment


Moreover, an architectural paradigm with microservices enforces the single responsibility of

Design category: 

Vous êtes certain ?

Si vous désactivez les cookies, vous ne pouvez plus naviguer sur le site.

Vous allez être rediriger vers Google.