Think about the following scenario: you have a giant Drupal 7 project with heaps of services and custom code, and things. It is a single point of failure and you want to replace it. Is Drupal 8 the logical option? Do you really want to switch from one to another monolith? There were others who had the same dilemma. Come to the session to find out what they did.
Introduction of microservices promised faster project maintenance and debugging, easier scaling, high availability and lots of good, old, developer fun. However, a huge ecosystem of sometimes mutually incompatible tools and the lack of guidelines made the concept too scary for most of the teams.
Early adopters and teams with appropriate budgets started experimenting and building their own tools. The rest of us were attending conferences and trying to get the big picture from multiple, often dissonant sources.
This session is going to try to present several stories from multiple development teams. Various flavors of transition from monoliths, to the service-oriented architecture, will be covered, including some epic wins and ridiculous failures.
Special attention will be paid to:
-
High availability and domain-driven design
-
User authentication and communication between services
-
Monitoring, orchestration, and failover mechanisms
-
Keeping the project alive during the transition
-
Cost/benefit ratio throughout the teams
The target audience is developers and software architects who are considering the transition to a service-oriented architecture. Product owners and managers would also be more than welcome, as the costs of the process will be covered, too. Finally, people who already broke the monolith and survived, no matter at which position in the team, would be more than welcome to share their stories and discuss.
