A microservices architecture is a game changer for team communication, not a purely technical solution. If different teams don’t have stable, direct communication channels, the software they produce will suffer. The five key properties crucial for a successful microservices implementation are zero-configuration, auto-discovery, high redundancy, self-healing, and fault tolerance.
Armağan Amcalar, head of software engineering at unu GmbH, spoke about the human side of microservices at Codemotion Berlin 2018. InfoQ is covering this conference with Q&A, summaries, and articles.
In today’s world of distributed computing and microservices, a clean software architecture is crucial for keeping a multitude of moving parts under control. This is best achieved through a coherent understanding of the whole ecosystem, and software architecture is the key to it, argued Amcalar.
Amcalar stated that a microservices architecture is a solution to the team communication problem, rather than a purely technical solution. Conway’s law emphasizes the communication structures of an organization and relates these structures to the structures of the systems they design. Microservices is also all about communication patterns of different pieces of software, said Amcalar. Companies comprised of isolated teams have to use architectures that utilize isolated services.
Teams would do best if they acknowledged the reason why they want to adopt microservices, argued Amcalar. While there are benefits like granular scaling abilities, it’s mostly about coordinating independent moving pieces. In the end, this is a choice that stems more from the way the teams want to work, and much less from the technical perspective, said Amcalar. No one picks microservices because it’s the easiest or the most effective way to build software; they choose it for psychological reasons, he said. The teams that are early to embrace this fact are more likely to succeed with microservices. They will know how and where to pivot when the time comes.
InfoQ interviewed Amcalar about the human side of microservices.
InfoQ: Why do we need a software architecture?
Armağan Amcalar: Writing code is usually considered solely an activity to tell computers what to do. But in fact if that were the case, we would all be typing 1’s and 0’s all the time — because that’s what computers are good at understanding. However, we choose to write software in more high-level languages. The reason is fairly simple — we write code for other humans to consume and understand. In turn, software architecture is just an extension of this practice; it is basically a blueprint of the structure you intend to set up and use. We are the most effective when we have a sound plan of what we want to build and how we want to build it. A clean software architecture therefore eliminates ambiguities and creates a shared understanding of our efforts.
InfoQ: What are the properties of microservices and why do they matter?
Amcalar: Microservices are best described as cloud-scale services that cooperate together on a user request. I define five key properties of microservices and while there are many others, these are crucial for a successful microservices implementation.
- Zero-configuration: A moderately sized microservices application will contain about a hundred different microservices running in a cloud environment which, coupled with an orchestration platform, leads to the fact that no one actually knows which service is running on which machine. In order to obtain this abstraction of hardware and to operate at scale, your services and their communication should be zero-config. You can’t keep track of IP addresses, hostnames or ports for your services, and exchange that information between your services so that they can join the system. If your services depend on individual configuration, you can never achieve an automated and scalable microservices architecture.
- Auto-discovery: A successful microservices app allows individual deployment and scaling of services at any given time without a re-configuration or a reboot of the system. This means you have to have a mechanism for services to discover each other and to start communication. Service auto-discovery makes sure a new service automatically discovers and communicates with the existing ones, and existing services automatically discover a new service in the network.
- High redundancy: A microservices application allows for dynamic scaling up or down, due to user demand. If you make use of zero-configuration and auto-discovery, then it’s relatively straightforward to run multiple copies of each service and increase redundancy. This allows the system to withstand errors and crashes in individual services, as well as having load balancing between multiple copies of the same service. A successful microservices implementation has redundant copies of each service.
- Self-healing: A microservices application is a network of resilient services. If one service goes down, the orchestration platform should be able to recreate the failed service automatically, without manual intervention. This approach makes sure that you have at least a few copies of any given service, so the although the operation might falter for some users, it doesn’t completely fail.
- Fault tolerance: Another aspect of a successful microservices architecture is fault tolerance. If at any given time all the instances of the same microservice goes down, at least other parts of the system that don’t depend on the said services should continue their operation. Also, if all copies of the same microservice are non-operational, services that need to communicate with them should hold onto the requests and not automatically fail until the self-healing mechanism kicks in. Because with self-healing in place, unless there’s another bigger problem, the failed service is expected to come back online in a few seconds. Therefore, the user can receive a delayed, but still proper, response.
InfoQ: You mentioned that a microservices architecture can be as solid and efficient as the team communication. Can you elaborate?
Amcalar: One of the most critical aspects of a microservices architecture is about designing for failure. When certain functions of your application fail, you make sure other parts are still operating. When you want to scale a critical service, you make sure you only scale what you need. When you need the cooperation of multiple microservices for a single functionality, in order to provide a meaningful performance, you try to minimize back and forth communication between services, especially the ones that are located far away from each other.
Now all of these aspects are also true for communications between different teams. If different teams are responsible for different microservices and if there isn’t a stable, direct channel between said teams, the software they produce will directly suffer.
InfoQ: You stated that developers don’t want to communicate. Can you elaborate?
Amcalar: Especially the developers of our time tend to lead individualistic efforts. Teamwork is of course still valued, but developers want clear assignments with clear acceptance criteria. Teams want autonomy and ownership. They don’t want to be bound by the decisions of others, and they don’t want to feel obliged to justify themselves and their decisions towards others. Our culture of individualism has this unfortunate side-effect. Developers want to be in control, and more often than not prefer jobs where they don’t have to communicate with other fellow developers or with other colleagues from other departments.
InfoQ: How does generation Y view the world, and how does that affect the way that they participate in teams?
Amcalar: Generation Y is aptly named after one of their most renowned characteristics: they question everything. They have individual logic, reason and emotional filters, and every piece of information they gather, they filter. Although they trust other people, they hardly trust the decisions of other people. They want total control over what they are doing and a clear sense of ownership on a certain subject. This also brings in an elevated sense of self-fulfilment. Generation Y is looking for meaning in their lives, and since work constitutes a huge part of one’s life, they try to make the best out of it by challenging everything, and making sure that everything around them is in the actual way they expect. This leads to more individualistic teams and more isolated pieces that come together to form a complete picture.
InfoQ: How are microservices and DevOps related?
Amcalar: Microservices requires a lot of automation to yield its true benefits. All the key properties of microservices that I have laid out before depend on automation, as it’s not humanly possible to configure, deploy, monitor, scale and maintain hundreds of services. DevOps is a culture of automation, therefore without a proper DevOps culture, a microservices implementation wouldn’t take off. The best practices of DevOps, automation, infrastructure-as-code and its approach to orchestration enable a microservices architecture. With proper DevOps practices, you don’t have to implement a microservices architecture and can also be very successful with a monolith or other service-oriented architectures. However, without DevOps practices, you can never succeed at microservices.