Virtual Panel: the MicroProfile Influence on Microservices Frameworks

In mid-2016, two new initiatives, MicroProfile and the Java EE Guardians (now the Jakarta EE Ambassadors), had formed as a direct response to Oracle having stagnated their efforts with the release of Java EE 8. The Java community felt that enterprise Java had fallen behind with the emergence of web services technologies for building microservices-based applications.

Introduced at Red Hat's DevNation conference on June 27, 2016, the MicroProfile initiative was created as a collaboration of vendors - IBM, Red Hat, Tomitribe, Payara - to deliver microservices for enterprise Java. The release of MicroProfile 1.0, announced at JavaOne 2016, consisted of three JSR-based APIs considered minimal for creating microservices: JSR-346 - Contexts and Dependency Injection (CDI); JSR-353 - Java API for JSON Processing (JSON-P); and JSR-339 - Java API for RESTful Web Services (JAX-RS).

By the time MicroProfile 1.3 was released in February 2018, eight community-based APIs, complementing the original three JSR-based APIs, were created for building more robust microservices-based applications. A fourth JSR-based API, JSR-367 - Java API for JSON Binding (JSON-B), was added with the release of MicroProfile 2.0.

Originally scheduled for a June 2020 release, MicroProfile 4.0 was delayed so that the MicroProfile Working Group could be established as mandated by the Eclipse Foundation. The working group defines the MicroProfile Specification Process and a formal Steering Committee composed of organizations and Java User Groups (JUGs), namely Atlanta JUG, IBM, Jelastic, Red Hat and Tomitribe. Other organizations and JUGs are expected to join in 2021. The MicroProfile Working Group was able to release MicroProfile 4.0 on December 23, 2020 featuring updates to all 12 core APIs and alignment with Jakarta EE 8.

The founding vendors of MicroProfile offered their own microservices frameworks, namely Open Liberty (IBM), WildFly Swarm/Thorntail (Red Hat), TomEE (Tomitribe) and Payara Micro (Payara), that ultimately supported the MicroProfile initiative.

In mid-2018, Red Hat renamed WildFly Swarm, an extension of Red Hat’s core application server, WildFly, to Thorntail to provide their microservices framework with its own identity. However, less than a year later, Red Hat released Quarkus, a "Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best-of-breed Java libraries and standards." Dubbed "Supersonic Subatomic Java," Quarkus quickly gained popularity in the Java community to the point that Red Hat announced Thorntail’s end-of-life in July 2020. Quarkus joined the relatively new frameworks, Micronaut and Helidon, that were introduced to the Java community less than a year earlier. With the exception of Micronaut, all of these microservices-based frameworks support the MicroProfile initiative.

The core topics for this virtual panel are threefold: first, to discuss how microservices frameworks and building cloud-native applications have been influenced by the MicroProfile initiative. Second, to explore the approaches to developing cloud-native applications with microservices and monoliths, and also the recent trend in reverting back to monolith-based application development. And third, to debate several best practices for building microservices-based and cloud-native applications.

Panelists

• Cesar Hernandez, senior software engineer at Tomitribe
• Emily Jiang, Liberty microservice architect and advocate at IBM
• Otavio Santana, developer relations engineer at Platform.sh
• Erin Schnabel, senior principal software engineer at Red Hat

InfoQ: How has the MicroProfile initiative, first introduced in 2016, influenced the way developers are building today’s microservices-based and cloud-native applications?

Hernandez: MicroProfile has been allowing Java developers to increase their productivity during the creation of new distributed applications and, at the same time, has allowed them to boost their existing Jakarta EE (formerly known as Java EE) architectures.

Jiang: Thanks to the APIs published by MicroProfile, the cloud-native applications using MicroProfile have become slim and portable. With these standard APIs, cloud-native application developers can focus on their business logics and their productivities are significantly increased. The cloud-native applications not only work on the runtime that developed against originally, they would also work on different runtimes that support MicroProfile, such as Open Liberty, Quarkus, Helidon, Payara, TomEE, etc. The developers learned the APIs once and never need to worry about re-learn a complete set of APIs in order to achieve the same goal.

Santana: The term cloud-native is still a large gray area and it's concept is still under discussion. If you, for example, read ten articles and books on the subject, all these materials will describe a different concept. However, what these concepts have in common is the same objective - get the most out of technologies within the cloud computing model. MicroProfile popularized this discussion and created a place for companies and communities to bring successful and unsuccessful cases. In addition, it promotes good practices with APIs, such as MicroProfile Config and the third factor of The Twelve-Factor App.

Schnabel: The MicroProfile initiative has done a good job of providing Java developers, especially those used to Java EE concepts, a path forward. Specific specs, like Config, Rest Client, and Fault Tolerance, define APIs that are essential for microservices applications. That’s a good thing.

InfoQ: Since 2018, the Java community has been introduced to Micronaut, Helidon and Quarkus. Do you see a continuation of this trend? Will there be more microservices frameworks introduced as we move forward?

Hernandez: Yes, I think new frameworks and platforms help in the synergy that produces innovation within the ecosystem. Over time, these innovations can lead to new standards.

Jiang: It is great to see different frameworks introduced to aid Java developers to develop microservices. It clearly means Java remains attractive and still the top choice for developing microservices. The other trend I saw is that the newly emerging frameworks adopt MicroProfile as the out-of-box solution for developing cloud-native microservices, as demonstrated by Quarkus, Helidon, etc. Personally, I think there will be more microservices framework introduced. I also predict they might wisely adopt MicroProfile as their cloud-native solutions.

Santana: Yes, I strongly believe that there is a big trend with this type of framework especially to explore AOT compilation and the benefits from the application's cold start.

The use of reflection by the frameworks has its trade-offs. For example, at the application start and in-memory consumption, the framework usually invokes the inner class ReflectionData within Class.java. It is instantiated as type SoftReference, which demands a certain time to leave the memory. So, I feel that in the future, some frameworks will generate metadata with reflection and other frameworks will generate this type of information at compile time like the Annotation Processing API or similar. We can see this kind of evolution already happening in CDI Lite, for example.

Another trend in this type of framework is to support a native image with GraalVM. This approach is very interesting when working with serverless, after all, if you have code that will run only once, code improvements like JIT and Garbage Collector don't make sense.

Schnabel: I don’t see the trend stopping. As microservices become more specialized, there is a lot more room to question what is being included in the application. There will continue to be a push to remove unnecessary dependencies and reduce application size and memory footprint for microservices, which will lead either to new Java frameworks, or to more microservices in other languages that aren’t carrying 20+ years of conventions in their libraries.

InfoQ: With a well-rounded set of 12 core MicroProfile APIs, do you see the need for additional APIs (apart from the standalone APIs) to further improve on building more robust microservices-based and cloud-native applications?

Hernandez: Eventually, we will need more than the 12 core APIs. The ecosystem goes beyond MicroProfile and Java; the tooling, infrastructure, and other stakeholders greatly influence creating new APIs.

Jiang: The MicroProfile community adapts itself and stays agile. It transforms together with the underlying framework or cloud infrastructure. For example, due to the newly established CNCF project OpenTelemetry (OpenTracing + OpenCensus), MicroProfile will need to realign MicroProfile Open Tracing with OpenTelemetry. Similarly, the previous adopted technologies might not be mainstream any more. MicroProfile will need to align with the new trend. For example, with the widely adopted metrics framework, Micrometer, which provides a simple facade over the instrumentation clients for the most popular monitoring systems, the MicroProfile community is willing to work with Micrometer.

The other areas I think MicroProfile can improve is to provide some guidance such as how to do logging, require all MicroProfile supporters to support CORS, etc. If any readers have any other suggestions, please start up a conversation on the MicroProfile Google Group. Personally, I would like to open up the conversation in early 2021 on the new initiatives and gaps MicroProfile should focus on.

Santana: Yes, and also improvements that need and can be made on the existing ones. Many things need to be worked together with the Jakarta EE team. The first point would be to embrace The Twelve-Factor App even more in the APIs. For example, making it easier for those who need credentials, such as username and password, in an application through the MicroProfile Config API. I could use JPA and the JMS as examples.

Another point would be how to think about the integration of CDI events with Event-Driven Design and increasingly explore the functional world within databases and microservices.

Schnabel: There is still a lot of evolution to come in the reactive programming space. We all understand REST, but even that space is seeing some change as pressure grows to streamline capabilities. There is work to do to align with changing industry practices around tracing and metrics, and I think there will continue to be some changes as the capabilities that used to be provided by an application server move out into the infrastructure be that raw Kubernetes, a serverless PaaS-esque environment, or whatever comes next as we try to make Kubernetes more friendly.

InfoQ: How would building cloud-native applications be different if it weren’t for microservices? For example, would it be more difficult to build a monolith-based cloud-native application?

Hernandez: When we remove microservices from the cloud-native equation, I immediately think of monolith uber-jars deployments. I feel that the early adopters of container-based infrastructures started taking advantage of cloud-native features using SOAP architectures instead of JAX-RS based microservices.

Jiang: I don’t see a huge difference between building cloud-native applications vs. microservices. Cloud-Native Application includes modular monolith and microservices. Microservices are normally small, while monolith is large by tradition. MicroProfile APIs can be used by either monolith or microservices. The important bit is that cloud-native applications might contain a few modules, which share the same release cadence and are interconnected. Coud-native applications should have their dedicated database.

Santana: So, as Java didn't die, the monoliths won't die anytime soon either! Many of the best practices we use today in the cloud-native environment with microservices can be applied with monoliths. It is worth remembering that The Twelve Factor App, for example, is based on the book Patterns of Enterprise Application Architecture, which is from 2003 and the popularization of the cloud environment occurred, mainly, in 2006 with Amazon AWS.

In general, the best practices you need to build a microservice architecture are also needed in the monolith environment. For example, CI/CD, test coverage, The Twelve Factor App, etc.

Since monoliths need fewer physical layers, usually two or three as a database and application, they tend to be easier to configure, monitor and deploy in the cloud environment. The only caveat is that its scalability in general is vertical, which often causes the limit that your cloud provider can provide to be exceeded.

Schnabel: In my opinion, the key characteristics for cloud-native applications are deployment flexibility and frequency: as long as your application does not depend on the specifics of its environment (e.g., it has credentials for backing services injected and avoids special code paths), you’re in good shape. If your monolith can be built, tested, and deployed frequently and consistently (hello, automation!), you’re ok.

InfoQ: Despite the success of microservices, recent publications have been discussing the pitfalls of microservices with recommendations to return to monolith-based applications development. What are your thoughts on this subject? Should developers seriously consider a move back to monolith-based applications development?

Hernandez: Developers should analyze the business requirements and technical context before choosing the tools and architectures to use.

As a developer, we get excited to test new frameworks and tools. Still, we need to understand and analyze the architecture for a particular scenario. The challenge then turns into finding the balance between the pros and cons of adopting or moving back to existing architectures.

Jiang: Monolith is not evil. Sometimes modular monolith performs as well as microservices. Microservices are not the only choice for cloud-native solutions. Choosing monolith or microservices depends on the company team structure and culture. If you have a small team and all of the applications releasing at the same cadence, monolith is the right choice. On the other hand, if you have a distributed team and they operate independently, microservices fit in well with the team structure and culture.

If moving towards microservices causes the team moving slower, moving back to monolith-based application is wise.

In summary, there is no default answer. You have to make your own choice based on your company setting and culture. Choose whatever suits the company best. You should not measure the success based on whether you have microservices or the number of the microservices.

Santana: As developers, we need to understand that there are no silver bullets in any architectural solution. All solutions have their respective trade-offs. The problem was the herd effect, which led to the community thinking that you, as a developer, are wrong if you are not on microservices. In technology, this was neither the first nor the last buzzword that will flood the technological community.

Overall, I see this with great eyes; I feel that the community is mature enough to understand that microservices cannot be applied to all possible things, that is, common sense and pragmatism is still the best tool for the developer/architect.

Schnabel: I agree with the sentiment: there is no need to start with microservices, especially if you’re starting something new. I’ve found that new applications are pretty fluid in the beginning. What you thought you were going to build isn’t quite what you needed in the end. Using a monolithic approach for that initial phase saves a lot of effort: coordinating the development and deployment of many services in the early days of an application is more complicated, and there isn’t a compelling reason to start there. Sound software practices inside the monolith can set you up for later refactoring into microservices once your application starts to stabilize. I’ve found that obvious candidates emerge pretty naturally.

InfoQ: What are some of your recommended best practices for building microservices-based and cloud-native applications?

Hernandez: Analyze first if the problem to solve fits within the microservice approach and the constraints or opportunities the particular project has. All the benefits of the cloud-native approach depend on how well you apply the base architecture.

Jiang: The base practices for building microservices-based and cloud-native applications are to adopt The Twelve Factor App, which ensures your microservices perform well in the cloud. Check out my 12 Factor App talk at QCon London 2020 on how to use MicroProfile and Kubernetes to develop cloud-native applications. The golden tip is to use an open and well-adopted standard for your cloud-native applications and then you are rest assured they will work well in the cloud.

Santana: In addition to the practices, both popularize such as DDD, The Twelve Factor App, etc. I consider myself as having good sense and being a pragmatic, professional, excellent practitioner. You don't need to be afraid to apply something simple if it meets the requirement and your business, so escape the herd effect of technology. In the recent book I'm reading, 97 Things Every Cloud Engineer Should Know: Collective Wisdom from the Experts, among several tips I will quote two:

The first is no problem if you don't use Kubernetes; as I mentioned, don't feel bad about not using a technology when it's not needed.

The second is the possibility of using services that increase abstraction and decrease the risk of implementing cloud-like PaaS, DBaaS. It is important to understand that this type of service brings the cloud-provider's whole know-how and makes operations such as backup/restore, updating services such as databases something much simpler. For example, I can mention Platform.sh, which allows deploying cloud-native applications straightforwardly in a GitOps centric way.

Schnabel: Avoid special code paths. They are hard to test and can be harder to debug. Make sure environment-specific dependencies (hosts, ports, credentials for backing services) are injected in a consistent way regardless of the environment your application runs in.

If you’re going to use microservices, use microservices. Understand that they are completely decoupled, independent entities with their own evolutionary lifecycle. APIs and contract testing should be on your radar. Do your best to wrap your head around the ramifications of microservices: if you try to ensure that everything works together in a staging environment and then deploy a set of versioned services that work together, you’ve gone back to a monolithic deployment model. If you have to consistently release two or more services at the same time because they depend on each other, you are dealing with a monolith that has unnecessary moving parts.

Think about application security up front. Every exposed API is a risk. Every container you build will need to be maintained to mitigate discovered vulnerabilities. Plan for that. When you’re moving to a cloud-native environment, you should take it as a given that "making an application work and then forgetting about it and letting it run forever" is no longer an option, and ensure you have the tools in place for on-going maintenance.

Conclusions

In this virtual panel, we asked the expert practitioners to discuss MicroProfile and microservices frameworks. We even asked for their thoughts on the recent trend to return to monolith-based application development.

Our experts agreed that MicroProfile has influenced the way developers are building microservices-based and cloud-native applications. The Java community should expect new microservices frameworks to emerge as MicroProfile itself will evolve with either new APIs or changes to existing ones.

Our panelists also recommended that all developers should also familiarize themselves with Heroku’s "Twelve-Factor App," a set of guiding principles that can be applied with any language or framework in order to create cloud-ready applications.

With the advent of microservices, monolith-based application development had seemingly been characterized as "evil." However, our experts warned against subscribing to such a characterization. Along with describing the pros and cons, they explained situations in which monolith-based application development would be beneficial over microservices-based application development. The challenging part now is for you to take this wisdom and apply it to your specific context and set of challenges.

About the Panelists

Cesar Hernandez is a Senior Software Engineer at Tomitribe with over 14 years of experience in Enterprise Java Applications. He is a Java Champion, Duke’s Choice Award winner, Oracle Groundbreaker Ambassador, Open Source advocate, Apache and Eclipse Committer, teacher, and public speaker. When Cesar is away from a computer, he enjoys spending time with his family, traveling, and playing music with the Java Community Band, The Null Pointers. Follow Cesar on Twitter.

Emily Jiang is a Java Champion. She is Liberty Microservices Architect and Advocate, Senior Technical Staff Member (STSM) in IBM, based at Hursley Lab in the UK. Emily is a MicroProfile guru and has been working on MicroProfile since 2016 and leads the specifications of MicroProfile Config, Fault Tolerance and Service Mesh. She was a CDI Expert Group member. She is passionate about MicroProfile and Jakarta EE. She regularly speaks at conferences, such as Code One, DevNexus, JAX London, Voxxed, Devoxx, EclipseCon, QCon, GeeCon, JFokus, etc. Connect with Emily on Twitter and LinkedIn.

Empowering developers worldwide to deliver better software faster, scalable in the Cloud. Otavio Santana is a passionate software engineer focused on Cloud and Java technology. He has experience mainly in persistence polyglot and high-performance applications in finances, social media, and e-commerce. Otavio is a member of both Expert Groups and Expert Leader in several JSRs and JCP executive committee. He is working on several Apache and Eclipse Foundation projects such as Apache Tamaya, MicroProfile, Jakarta EE, where he is leading the first specification at Jakarta EE with Jakarta NoSQL. A JUG leader and global speaker at JavaOne and Devoxx conferences. Otavio has received recognition for his OSS contributions such as the JCP Outstanding Award, Member of the year and innovative JSR, Duke’s Choice Award, and Java Champion Award, to name a few.

Erin Schnabel (@ebullientworks) is a Senior Principal Software Engineer and maker of things at Red Hat. She is a Java Champion, with 20 years under her belt, as a developer, technical leader, architect and evangelist, and she strongly prefers being up to her elbows in code. Erin learns (and teaches) by coding ridiculous things, like "Monster Combat," an application that makes monsters fight each other to explore application metrics; "Game On!," a text adventure game for microservices; and a reactive workshop that munges "The Jabberwocky" to gain an understanding of how reactive operators work.

Resources

●    Microservices: What They Are and Why Use Them by Laura Mauersberger (August 14, 2017)
●    To Microservices and Back Again - Why Segment Went Back to a Monolith by InfoQ (April 27, 2020)
●    This Week in Programming: Forget Microservices, Monoliths Are the Way Forward by Mike Melanson (February 1, 2020)
●    Goodbye Microservices: From 100s of Problem Children to 1 Superstar by Alexandra Noonan (July 10, 2018)
●    You Don't Need Microservices by Elder Moraes (August 2020)
●    Istio as an Example of When Not to Do Microservices by Christian Posta (January 8, 2020)
●    Monolith vs. Microservices tweet thread by Oliver Drotbohm (July 2, 2020)