Back in 2016, many would have argued this was just another unbearable buzzword, but today many organizations are reaping the very real benefits of breaking down old monolithic applications, as well as seeing the very real challenges microservices can introduce.
For teams dealing with loads of technical debt, microservices offer a path to the promised land. They promise to bring greater flexibility and easier scalability. Smaller code bases are easier to understand, and with clearly separated services the overall architecture is much “cleaner”.
Microservices bring with them new and exciting possibilities (the cake is NOT a lie), but they’re still not without challenges. Anyone that tells you otherwise is sorely mistaken (or, more likely, trying to sell you something). Higher frequency releases and increased collaboration between dev and ops is exciting, but it’s important to stay diligent.
Microservices may be considered a revolutionary way to build applications, but this new approach does not require us to completely start from scratch. Rather than asking what specialized framework you need to build a new microservices architecture, let’s ask how we can use current frameworks to support the same goal.
But first… A short recap of what microservices are and where they came from:
Martin Fowler, along with James Lewis, tried to define this new architecture in his first article covering microservices way back in 2014:
“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery”.
Back then, microservices and the concept of containerized applications were so new there weren’t really specialized tooling or frameworks available to support building, deploying and running those kinds of applications. Rather, the focus was on adapting current tools for use with this new architectural style.
In the past half a decade, the industry has exploded with technology built especially to support new microservices. That doesn’t mean that they’re the best suited for each individual’s needs though. In fact, unlike monoliths, which are generally developed with the tech stack in mind, each service in a microservices architecture can be built using a different framework based on its own functionality.
This post is not about the pros and cons of microservices, but instead looks at the underlying technology most-suited to support it. If you’re looking to dig into some of the common pitfalls of microservices (and how to overcome them, of course), check out this post that covers the main challenges associated with microservices. Instead, we’ll go over some of the most popular frameworks for building microservices – both traditional and container-specialized.
The classic Java EE, now Jakarta EE (JEE), approach for building applications is geared towards monoliths. Traditionally, an enterprise application built with Java EE would be packaged into a single EAR (Enterprise Archive) deployment unit which includes WAR (Web Archive) modules and JARs (Java Archive) files.
Although there aren’t any technological restrictions ruling out the use of JEE for microservices architectures, there is a significant overhead cost. Each service would need to be packaged as a standalone unit, meaning it should be deployed within its own individual JEE server. That could mean deploying dozens or even hundreds of application servers to support a typical enterprise application.
Luckily, the community noticed early-on that the standard JEE didn’t address the new build challenges that microservices introduced. Since 2016, many additional open source projects have been started to support microservices built in JEE.
Eclipse MicroProfile is a continually growing set of APIs based on JEE technologies. It’s an OS community specification for building Enterprise Java microservices, backed by some of the biggest names in the industry, including Oracle, Red Hat and IBM.
Bottom line: There’s no reason you can’t use Java EE for microservices, but it doesn’t address the operational aspects of running multiple individualized services. For those of you that want to move an existing monolith JEE app to microservices, there are plenty of “add-on” tools out there based on JEE technology to support your needs.
Spring is one of the most popular frameworks for building Java applications and, like with Java/Jakarta EE, it can be used to build microservices as well. As they put it, “[microservices do] at the process level what Spring has always done at the component level.”
Still, it’s not the most straightforward process to get an application with microservices architecture up and running on the Spring framework… You’ll need to use Spring Cloud (heavily leverages Spring Boot), several Netflix OSS projects and, in the end, some Spring “configuration magic”.
For a deep dive on how to build microservices with Spring, check out this post straight from the source.
Bottom line: Spring is well positioned for the development of microservices, together with an offering around external open source projects that address the operations angle. That doesn’t mean it will be easy though.
Lightbend provides us with another option. Continuing with the same theme, Lagom wraps around the Lightbend stack with Play and Akka under the hood to provide an easier way to build microservices. Their focus is not only to provide an easy solution for those moving towards microservices, but to ensure that those microservices are easily scalable and reactive.
In an interview with InfoQ back in 2015, Jonas Bonér, Lightbend’s CTO and co-founder, said:
“Most microservices frameworks out there focus on making it easy to build individual microservices – which is the easy part. Lagom extends that to systems of microservices, large systems – which is the hard part, since here we are faced with the complexity of distributed systems.”
Bottom line: Lagom takes Lightbend’s capabilities and leverages them in one framework, specially designed for building reactive microservices that scale effectively across large deployments. Their focus is not only on the individual microservices, but on the system as a whole.
Not unlike the other frameworks we’ve looked at in this post, Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web services. An opinionated collection of Java libraries that make building production ready Java applications much easier.
Dropwizard Modules allow hooking up additional projects that don’t come with Dropwizard’s core, and there are also modules developed by the community to hook up projects like Netflix Eureka, similar to Spring Cloud.
Bottom line: Since Dropwizard is a community project that isn’t backed by a major company like Spring and Pivotal, Java EE and Oracle, Lagom and Lightbend, its development might be slower, but there’s a strong community behind it and it’s a go-to framework for large companies as well as smaller projects.
Apart from the 4 big players we’ve mentioned here, there’s a plethora of other projects that are worth mentioning and can also be used for writing microservices:
Vertx, also under the Eclipse Foundation, is a toolkit for building reactive applications on the JVM. Some might argue it should have a spot at the big 4.
Spotify Apollo is a set of Java libraries that is used at Spotify when writing Java microservices. Apollo includes features such as an HTTP server and a URI routing system, making it trivial to implement RESTful services.
Kubeless is a Kubernetes-native serverless framework. It’s designed specifically to be deployed on a Kubernetes cluster so users are able to use native Kubernetes API servers and gateways.
Additional frameworks include Spark, Ninja and Jodd, Restlet and Bootique.io.
Bottom line: The Java microservices playing field is quite large, and it’s worth checking out the smaller players just as much as the industry giants.
It doesn’t matter which framework or platform you’re using, building microservices isn’t tightly coupled with any of them. It’s a mindset and an architectural approach, and the best practice (as always) is to find the best options for your application’s unique requirements.
With that said, successfully implementing a microservice architecture doesn’t stop at the application itself. Much of the cost around it comes from so-called DevOps processes, monitoring, CI/CD, logging changes, server provisioning and more that are needed to provide continued support to the application in production. So, go ahead and enjoy your cake, but don’t forget to stay diligent as you reap your rewards.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.