JAX London Blog

JAX London Blog

JAX London, 09-12 October 2017
The Conference for JAVA & Software Innovation

Sep 11, 2017

Source: Shutterstock

In this interview, Kai Tödter emphasise that teams have to think carefully how microservices should interact with each other, like using orchestration or choreography. The services themselves should be self-contained or use resilience patterns when they need data of other microservices.

JAX London: A lot of people jump on the microservices bandwagon without having a clear purpose in mind. How important is it to ask yourself the question: “Should I use microservices?”

Kai Tödter: Often people use software architecture styles just because they are trendy or hyped. So it is very important to ask this question. There are many reasons for using microservice-based architectures but there are always costs that should never be ignored.

 

JAX London: How can microservices — if used correctly — offer flexibility in deciding how to best utilize a project’s resources?

Kai Tödter: One of the benefits of a microservice-based architecture is that a single microservice can be totally owned by a small team. So the team members can decide what would be the best technology stack for implementing the microservice. The teams are more flexible and can benefit from existing knowledge and available skills.

While one single microservice might reduce complexity for a specific domain or functionality, the composition of many microservices increases complexity. 

 

JAX London: What is the correct way to use microservices?

Kai Tödter: There is no general “correct way”, it always depends on the functional and non-functional requirements of the business context. But the teams have to think carefully how microservices should interact with each other, like using orchestration or choreography.

The services themselves should be self-contained or use resilience patterns when they need data of other microservices.

 

JAX London: Can microservices increase complexity?

Kai Tödter: Yes. While one single microservice might reduce complexity for a specific domain or functionality, the composition of many microservices increases complexity. A few examples are scalable deployment, communication between microservices, centralized logging, monitoring and tracing. And this is just the tip of an iceberg that is often underestimated.

 

JAX London: What is the biggest misconception about microservices?

Kai Tödter: I guess one of the biggest misconceptions is that microservices might solve all the existing (architectural) problems. That is definitely not the case, and teams should think carefully not only about the benefits but also about the costs when they want to go with a microservice-based approach.

There is no general “correct way”, it always depends on the functional and non-functional requirements of the business context.

 

JAX London: In your view, what are the 3 golden rules of microservices deployment?

Kai Tödter: I wouldn’t nail it down to “3 golden rules”, but there a few characteristics that should apply to all microservices. For example, each microservice should be independently deployable, upgradable, replaceable and scalable.

 

JAX London: What are the best open-source tools for orchestrating microservices?

Kai Tödter: I guess this question is related to container orchestration rather than microservice interaction patterns like orchestration or choreography. Popular container orchestration tools are Kubernetes, Marathon (for Mesos and DC/OS) or Docker Swarm.

 

JAX London: What are the key elements in implementing a microservice-based architecture?

Kai Tödter: There are many elements that characterize a microservice-based architecture. I think one key element is that microservices are treated like products rather than projects, meaning that the team owns the whole lifecycle of a microservice, including deployment and operation.

A team that owns a microservice should be cross-functional and organized around business capabilities rather than specific technologies (like UI or databases), all skills needed to implement the whole microservice should be in the team. Data management should be decentralized (e.g. each microservice decides his own persistence layer) and technology stacks should be chosen by the team, rather than having a centralized governance.

Teams should think carefully not only about the benefits but also about the costs when they want to go with a microservice-based approach.

 

JAX London: SAP President Steve Singh said on an episode of CNBC’s “Mad Money” that cloud computing is yesterday’s news — ‘microservices’ are the future. Do you agree?

Kai Tödter: I think Steve used the term “microservice” in a different context. If you think about “cloud computing” as using remote servers hosted on the Internet rather than a local server or a personal computer, then I would agree because microservices are much finer grained on that level.

If you think about cloud computing as using cloud infrastructures, platforms and services, then I would consider the cloud as a great deployment infrastructure for microservices. So, in my point of view, deploying microservices on cloud infrastructures fits very well.

 

JAX London: Who should attend your workshop and why?

Kai Tödter: My workshop  Cool Web Apps with Spring Boot, Angular and TypeScript is for software developers and architects who not only want to get an overview of the used technology stack but also get real hands-on experience building a small microservice from scratch.

Talks by Kai Tödter at JAX London 2017
10 Oct 2017
15:15 – 16:05

Behind the Tracks

Software Architecture & Design
Software innovation & more
Microservices
Architecture structure & more
Agile & Communication
Methodologies & more
DevOps & Continuous Delivery
Delivery Pipelines, Testing & more
Big Data & Machine Learning
Saving, processing & more