an individual service and modularity via loose coupling (T2). The modularity of the service is also the key to reuse (T3). The requirements in different projects are similar most of the time, but very seldom are they exactly the same. Additional requirements and features can be easily integrated into a microservice or outsourced into another service. When and how to perform this is the crucial architectural design decision.
was motivated by the ability to replicate on demand across servers
DevOps
Cloud computing changes the way a team cooperates within itself and interacts with other teams. The deployment of software is an essential task in every release of a software component. Features which were formerly provided by the IT department are now directly part of applications via infrastructure as code [LM12]. This is blurring the line between traditional software development and operations. There are different setups to target this:
- Close collaboration between the operations team and the development team
- Developers and operators in one team
- Every team member performs operations and develops software
EB has decided to follow the latter approach for teams working primarily with connectivity and backend infrastructure. The reason behind this is that cloud computing and connecting things are the key expertise of the employees working on connectivity solutions. In this context, every software developer needs to be familiar with these techniques (O2) and needs knowledge in performing operations. In bigger projects, several teams are working together. In this case, one team takes over the DevOps. The cooperating teams concentrate purely on software development. Microservice architecture, in this context, means that every service has a single responsibility, although the algorithm behind the service might be more complicated (e.g. a routing algorithm).
within itself and interacts with other teams
The working mode (O1) follows a Kanban approach. Tasks in operations often need