The SAP TechEd season 2018 is around the corner and I am very excited to contribute the lecture
OPP400 Microservices in an Agile Environment, which is in large parts based on the internal work of the SAP Community.
There is also my related Lightning Talk
LT120, which I describe in this
blog post.
Learning Objectives
The talk is based on the assumption that systems, processes, and organizations can only evolve together in a digital company. The structure of an organization is mutually connected to the architecture of the system that is built by the organization. Microservices and
Self-contained Systems (SCS) are related patterns for structuring complex systems into smaller modules that are developed and owned by autonomous teams. It is very important that these teams work and think agile from end to end to avoid waste when working on new products or services under conditions of uncertainty.
In this talk you learn how to:
- Improve complex software architectures with Self-contained Systems
- Combine microservice architectures with agile software development
- Think agile from end to end to reduce waste
Let's look at these statements in more detail.
Self-contained Systems
An SCS is an autonomous web application that has its own business logic and its own database if a database is necessary. The important part of an SCS is its user interface. The user interface is used to provide the primary function of the SCS to users. Self-contained Systems and microservices are related but different concepts. An SCS can consist of multiple microservices. Microservices are independently deployable modules with physical boundaries owned by one team.
SCSs and microservices are a perfect match for
Domain-driven Design. In DDD, domains are decomposed into subdomains to ease their modeling and comprehension. The models of these subdomains are only valid within a context that needs a boundary. The boundary is the SCS and the microservices are the modules that help organize the elements of the domain model within the context.
An SCS is owned by one single team. This makes the team the owner of the Bounded Context and all Microservices that belong to the SCS.
Agility and Microservices
Part of the agile
manifesto is the principle: "The best architectures, requirements, and designs emerge from self-organizing teams." A microservice architecture enables the described autonomy and self-organization. Consequently, teams need many different skills to get things done. Only cross-functional teams can operate autonomously and respond quickly to customer needs.
Best practices summarized as the
Twelve-Factor App and Continuous Delivery are more than technical details for microservices. The SAP Community implemented these essential architectural concerns successfully with the SAP Cloud Platform. This allows the SAP Community to bring changes into the hands of its users during normal business hours.
End-to-end Agility
Lean approaches such as the Lean Startup and Lean Enterprise use feedback loops and experimental problem-solving approaches. Lean Enterprise, for instance, emphasizes the importance of end-to-end agility, which most organizations fail to implement. Join my talk to learn more about this problem.
Integration Patterns
A very important aspect of a microservice architecture is
integration because you cannot break a complex system into smaller modules with physical boundaries without facing any integration task. Microservices and SCSs can be integrated on different layers:
- User interface: Links and transclusion can be used to integrate systems having their own user interfaces. This approach is used by the SAP Community to keep the SCSs as independent as possible.
- Business logic:
- Messaging: Messaging has countless advantages. The SAP Community uses Apache Kafka to implement the pattern Event-Carried State Transfer in a resilient and scalable manner.
- Service APIs: Business logic can be (re-)used by RESTful APIs.
A very important aspect of microservice integration is the organizational structure. DDD provides patterns, such as Customer/Supplier and Conformist, to describe and analyze the relationship between two integrated systems. The pattern Conformist can occur where each team reports to different managers or has different goals.
Summary
In the beginning, I mentioned that systems, processes, and organizations can only evolve together in a digital company. Agile software development must be done from end-to-end with cross-functional teams. The teams' structure should match the microservices architecture and maybe also your Bounded Contexts if you work with DDD.
