In the microservices panel at microXchg 2018, held in Berlin, a panel discussed the state of microservices as of today, and considered whether the hype is over and microservices are becoming a mature technique. Moderating the panel was Susanne Kaiser, who began the debate by asking what the prerequisites are for a company introducing microservices. The panel — consisting of Stefan Tilkov, Chris Richardson, Elisabeth Engel and Daniel Bryant — noted that it’s important to know why you want to use the microservice architecture style. Do you have the requirements that call for a migration? The primary aspect of microservices is to solve a problem, not to be a fancy new techology.
- Bryant, independent consultant and editor for InfoQ, referred to Martin Fowler and Phil Calçado for the more technical prerequisites, but emphasized the importance of understanding your domain model. For a start-up without a real knowledge of what you are building, he would choose whatever is the fastest, and often this is not microservices
- Engel, UX and software engineer at Gutefrage, pointed out that if you don’t feel pain in your current architecture, then maybe you should stay with that
- Richardson, founder of Eventuate, noted that if your present architecture is holding you back, then it can be an excellent time to migrate to a microservice architecture
- Tilkov, co-founder of INNOQ, pointed out that you can build great systems without microservice, sometimes even better software using a monolith
Kaiser then asked what the biggest barriers for adoption of microservices are, and also asked how to overcome them.
- Tilkov believes one major barrier is when you get your service boundaries or sizes wrong. This is so difficult to change, that teams tend to accept the original implementations even they aren't so great
- For Richardson the essential problem when adopting microservices is the decomposition into a meaningful set of services. On the other hand, when working with a multi-million-line monolith, you are as a developer confronted with that complexity every day. Working with one single service is much simpler
- Engel sees the complexity as the hardest part. For her a key to success is to get something that developers can look at, understand and use
- Bryant points out that we must not forget all the technology that comes with microservices, and also that the way you design and build a system is as important as the architecture itself
When asked about the challenges for the frontend when microservices are introduced, Engel noted that a consumer still assumes the application is a single thing, so you have to make sure the frontend stays consistent when content from different backend services is displayed. One challenge is that frontend technology is not built for a microservices backend. Commonly the solution is to use old technologies like iframe and framesets, so there is a need for some new JavaScript-based techniques for this. Tilkov claimed that architects have to focus more on the frontend and acknowledge that it matters. For him, the frontend typically matters more than the backend.
A more general next question was if microservices have emerged into being the preferred way of creating enterprise applications?
- Richardson and Tilkov believe they shouldn’t be the first choice and emphasized that the architecture must depend on the context. For small single teams, the monolith is almost always fine. With many teams involved you should probably look at some form of service decomposition
- Engel likes to prepare a monolith for splitting it up by having seams where this can be done if needed
- For Bryant, evolutionary architecture is very interesting for enabling a future migration of an architecture
Going beyond microservices, Kaiser asked if serverless architecture is the next step for build systems, and how they will collaborate with microservices.
- Richardson sees serverless as orthogonal to microservices, and from his perspective serverless is a way of deploying microservices — a coming alternative to containers
- For Tilkov serverless is the perfect deployment option; five years from now he believes we will not be deploying Kubernetes clusters anymore. A problem he has though, is that he can’t figure how to build a large system that is composed of 100’s of functions. He thinks we need something clustering them in larger units, and compares with building a large system just by using database triggers calling stored procedures
- Bryant mentioned that there are new technologies like Camunda that are the next evolution of business process managers (BPMs) that use domain-specific languages (DSLs) to describe how functions interact. They allow for business functions to be composed into business flow and may be a way of assembling simple and highly event driven functions into a workflow
When asked if microservices will fade away and evolve into something else, the panel agreed that we always will have a need of reducing size and complexity. The technology and platforms will evolve but the key idea of boundaries in microservices, with an inside/outside view of things, will stay for a long time. Bryant believe that more standard functions will be pushed down into the platforms, allowing for developers to focus more on the business side — maybe in the near future there will be a mix of software engineers and business people attending the conference.
At the recent QCon London 2018 conference, a panel discussed The Future of Microservices and Distributed Systems.
The presentations at the conference were recorded; some are already published, with more to come.
