Achieving Cloud Scalability with Microservices and DevOps for Connected Cars: Page 4 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.
to be performed at once when they are occurring (e.g. the outage of a server). In Scrum, activities need to be planned. This is not possible with these kinds of tasks. Kanban makes it possible to immediately work on high priority targets and to include feature development. Every DevOps team has the right to start and stop instances and services in their respective stage, which allows controlled self-services on cloud resources (O3+O5).

With this arrangement, the next step is to set up a continuous deployment process (T4). In this case, automation is the key for quality and efficiency with techniques like infrastructure as code [LM12] being the key factors. EB is successfully working with AWS CloudFormation [DP15] to have the infrastructure as code, which makes the configuration reproducible (O4). Code can be deployed directly to test instances from the build server (T4). Only the release needs manual interaction.

Software reuse with inner source

One key decision to enable software reuse (T3) is the adaption of open source techniques into our development processes. Here, EB follows the inner source (IS) approach [CR15] by establishing a software forge where the source code was made available to all developers. A forge is a central place where a well-documented code base is kept forever with the possibility to search [CR15]. This allows all developers to use and review the code. Following Linus´s law “Given enough eyeballs, all bugs are shallow” [RE01] a higher code quality can be achieved (T5) than with the common four-eye principle alone. Experience showed that the code quality improved and that teams were starting to work together, especially on common tooling. A set of microservices is available via the forge, enabling software reuse in other projects and improving the overall development time.

Summary

With the current setup, EB has begun to improve and create new environments by changing the culture in software development from a classic agile setup to a

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.