In anticipation of Emily Jiang's session, "Rethink Microservices", Richard Wallintin (WPS - Workplace Solutions) had a number of questions about her view on the microservices hype and her choice of frameworks for a modern and successful application development.
Your talk promises a critical view on the microservices hype. Do you believe there are widespread misconceptions on what microservices should be or were meant to be?
In my talk, I will explain the history of microservices and what microservices are, the misconception and the best practices for developing microservices. I will then talk about the future of microservices, especially now that serverless gains more popularity.
There are widespread misconceptions on what microservices should be. One common misconception was that microservices are the default answer to all kinds of problems. Microservice are about being independently managed and released. In order to adopt microservices, it is necessary to also involve cultural changes such as team size, organizational changes, etc. Monoliths are not evil, and there are good reasons for them to exist for a long time.
Regardless of what a “microservice” is or should be – what traits of systems (and frameworks) do you consider most crucial for successful application development today?
Successful application development must adopt Cloud Native technologies to ensure that the applications are configurable, resilient, secure, monitorable, and intelligent so that they can work well with the Cloud. With these requirements, the application development should adopt the Cloud Native standards, including MicroProfile and Jakarta EE, to ensure that Cloud Native best practices stay vendor neutral.
In the world of small, focused deployment units and containerization, is the choice of framework (e.g., Spring vs. Jakarta EE vs. MicroProfile) only an implementation detail? Which factors should teams take into account when making a decision?
The choice of framework matters a lot as you will need to ensure smaller deployment units and containerization. Jakarta EE and MicroProfile are complementary to each other. They are open source standards. If you choose these frameworks, you will have many runtimes to choose from, including Open Liberty, Wildfly, Payara, TomEE, etc. MicroProfile and Jakarta EE are Cloud Native standards while Spring is a library, which is only supported by Spring framework. If you don't want to look into any particular vendor, you should choose open source standards such as MicroProfile and Jakarta EE.
Looking at the list of specs in MicroProfile, technical runtime/operations support is well represented (tracing, metrics, health, fault tolerance, config). Is this the key benefit of MicroProfile, or are there other pillars of equal importance?
MicroProfile is a community driven project. It offers a mature programming model for developing Cloud Native applications. Community involvement and feedback are very important to the success of MicroProfile. Please connect with the MicroProfile community by subscribing to MicroProfile googlegroup.
Follow-Up-Question: How do MicroProfile and the Jakarta EE Web Profile influence each other? Are Tracing, Metrics, Health etc. likely to appear in the Jakarta EE stack?
MicroProfile adopts Jakarta EE Core Profile, which is a smaller new profile introduced in Jakarta EE 10 for MicroProfile's usage. MicroProfile and Jakarta EE Web Profile or Platform are complementary to each other. MicroProfile aligns with Jakarta EE technologies. At the moment, there is no plan to move MicroProfile technologies to Jakarta EE because end users can easily use MicroProfile and Jakarta EE together. Quite a few companies, including IBM, Red Hat, Oracle, Tomitribe, Microsoft, and Fujitsu, support both communities.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
