Microservices for Java Developers -- including free O'Reilly PDF for download

883 views
Skip to first unread message

Katherine

unread,
Sep 18, 2016, 7:03:08 AM9/18/16
to ccsfc...@googlegroups.com
Microservices for Java Developers: A Hands-On Introduction to Frameworks & Containers
http://developers.redhat.com/promotions/microservices-for-java-developers

...requires you to sign up for Red Hat Developers program.


---------------------------------------------------------------------------------------------------------
Preparing Your Environment
We will be using Java 1.8 for these examples and building them with Maven. Please make sure for your environment you have the following prerequisites installed:
  • JDK 1.8
  • Maven 3.2+
  • Access to a command-line shell (bash, PowerShell, cmd, Cygwin, etc.)
The Spring ecosystem has some great tools you may wish to use either at the command line or in an IDE. Most of the examples will stick to the command line to stay IDE neutral and because each IDE has its own way of working with projects. For Spring Boot, we’ll use the Spring Boot CLI 1.3.3.

Alternative IDEs and tooling for Spring:
For both Dropwizard and WildFly Swarm, we’ll use JBoss Forge CLI and some addons to create and interact with our projects:
Alternative IDEs and tooling for Spring, Dropwizard, or WildFly Swarm projects (and works great with JBoss Forge):
Finally, when we build and deploy our microservices as Docker containers running inside of Kubernetes, we’ll want the following tools to bootstrap a container environment on our machines:
---------------------------------------------------------------------------------------------------------


Book goes through 3 popular Java frameworks for developing microservices:
  • Spring Boot for Microservices (starting on pg 19)
      • Spring Boot is an opinionated Java framework for building microservices based on the Spring dependency injection framework. Spring Boot allows developers to create microservices through reduced boilerplate, configuration, and developer friction. This is a similar approach to the two other frameworks we’ll look at. Spring Boot does this by:
        • Favoring automatic, conventional configuration by default
        • Curating sets of popular starter dependencies for easier consumption
        • Simplifying application packaging
        • Baking in application insight (e.g., metrics and environment info)
    Spring historically was a nightmare to configure. Although the framework improved upon other high-ceremony component models (EJB 1.x, 2.x, etc.), it did come along with its own set of heavyweight usage patterns. Namely, Spring required a lot of XML configuration and a deep understanding of the individual beans needed to construct JdbcTemplates, JmsTemplates, BeanFactory lifecycle hooks, servlet listeners, and many other components. In fact, writing a simple “hello world” with Spring MVC required understanding of DispatcherServlet and a whole host of Model-View-Controller classes. Spring Boot aims to eliminate all of this boilerplate configuration with some implied conventions and simplified annotations—although, you can still finely tune the underlying beans if you need to.
      • Spring was used in large enterprise applications that typically leveraged lots of different technology to do the heavy lifting: JDBC databases, message queues, file systems, application-level caching, etc. A developer would have to stop what she’s doing, switch cognitive contexts, figure out what dependencies belonged to which piece of functionality (“Oh, I need the JPA dependencies!”) and spend lots of time sorting out versioning mismatches or issues that would arise when trying to use these various pieces together. Spring Boot offers a large collection of curated sets of libraries for adding these pieces of functionality. These starter modules allow you to add things like:
        • JPA persistence
        • NoSQL databases like MongoDB, Cassandra, and Couchbase
        • Redis caching
        • Tomcat/Jetty/Undertow servlet engine
        • JTA transactions
      Adding a submodule to your application brings in the curated set of transitive dependencies and versions that are known to work together saving developers from having to sort out dependencies themselves.
        • Spring Boot really is a set of bootstrap libraries with some convention for configurations, but there’s no reason why you couldn’t run a Spring Boot application inside your existing application servers (as a WAR). The idiom that most developers who use Spring Boot prefer is the self-contained JAR packaging for their application. This means Spring Boot packages all dependencies and application code into a self-contained JAR with a flat class loader. This makes it easier to understand application startup, dependency ordering, and log statements; but more importantly, it helps reduce the number of moving pieces required to take an app safely to production. This means you don’t take an app and chuck it into an app server; the app, once it’s built, is ready to run as is—standalone—including embedding its own servlet container if it uses servlets. That’s right, a simple java -jar <name.jar> is enough to start your application now! Spring Boot, Dropwizard, and WildFly Swarm all follow this pattern of packaging everything into an executable uber JAR.
      But what about management things we typically expect out of an application server?
        • Spring Boot ships with a module called actuator which enables things like metrics and statistics about your application. For example, we can collect logs, view metrics, perform thread dumps, show environment variables, understand garbage collection, and show what beans are configured in the BeanFactory. You can expose this information via HTTP, JMX, or you can even log in directly to the process via SSH.
      With Spring Boot, we can leverage the power of the Spring Framework and reduce boilerplate configuration and code to more quickly build powerful, production-ready microservices. 
      • Dropwizard for Microservices (starting on pg 37)
        • Dropwizard was created well before either Spring Boot or WildFly Swarm. Its first release, v0.1.0, came out December 2011. At the time of this writing, v0.9.2 is the latest, and 1.0 is just around the corner. Dropwizard was created by Coda Hale at Yammer to power the company’s distributed-systems architectures (now called microservices!), heavily leveraging the JVM. It started out as a set of glue code to combine some powerful libraries for writing REST web services and has evolved since then, although it still maintains its identity as a minimalist, production-ready, easy-to-use web framework.
      Dropwizard is an opinionated framework like Spring Boot; however, it’s a little more prescriptive than Spring Boot. There are some components that are just part of the framework and cannot be easily changed. The sweet-spot use case is writing REST-based web applications/microservices without too many fancy frills. For example, Dropwizard has chosen the Servlet container (Jetty), REST library (Jersey), and serialization and deserialization (Jackson) formats for you. Changing them out if you want to switch (i.e., changing the servlet container to Undertow) isn’t very straightforward.
       
      Dropwizard also doesn’t come with a dependency-injection container (like Spring or CDI). You can add one, but Dropwizard favors keeping development of microservices simple, with no magic. Spring Boot hides a lot of the underlying complexity from you, since Spring under the covers is pretty complex (i.e., spinning up all the beans actually needed to make Spring run is not trivial) and hides a lot of bean wiring with Java Annotations. Although annotations can be handy and save a lot of boilerplate in some areas, when debugging production applications, the more magic there is, the more difficult it is. Dropwizard prefers to keep everything out in the open and very explicit about what’s wired up and how things fit together. If you need to drop into a debugger, line numbers and stack traces should match up very nicely with the source code.
       
      Just like Spring Boot, Dropwizard prefers to bundle your entire project into one, executable uber JAR. This way, developers don’t worry about which application server it needs to run in and how to deploy and configure the app server. Applications are not built as WARs and subject to complicated class loaders. The class loader in a Dropwizard application is flat, which is a stark difference from trying to run your application in an application server where there may be many hierarchies or graphs of class loaders. Figuring out class load ordering, which can vary between servers, often leads to a complex deployment environment with dependency collisions and run-time issues (e.g., NoSuchMethodError). Running your microservices in their own process gives isolation between applications so you can tune each JVM individually as needed and monitor them using operating system tools very familiar to operations folks. Gone are the GC or OutOfMemoryExceptions which allow one application to take down an entire set of applications just because they share the same process space.
      • WildFly Swarm for Microservices (starting on pg 61)
        • The last Java microservice framework we’ll look at is a relative newcomer to the scene yet leverages tried-and-trusted Java EE functionality found in the JBoss WildFly application server. WildFly Swarm is a complete teardown of the WildFly application server into bitesized, reusable components called fractions that can be assembled and formed into a microservice application that leverages Java EE APIs. Assembling these fractions is as simple as including a dependency in your Java Maven (or Gradle) build file, and WildFly Swarm takes care of the rest.
      Application servers and Java EE have been the workhorse of enterprise Java applications for more than 15 years. WildFly (formerly JBoss Application Server) emerged as an enterprise-capable, open source application server. Many enterprises heavily invested in the Java EE technology (whether open source or proprietary vendors) from how they hire software talent as well as overall training, tooling, and management. Java EE has always been very capable at helping developers build tiered applications by offering functionality like servlets/JSPs, transactions, component models, messaging, and persistence. Deployments of Java EE applications were packaged as EARs, which typically contained many WARs, JARs, and associated configuration. Once you had your Java archive file (EAR/WAR), you would need to find a server, verify it was configured the way you expect, and then install your archive. You could even take advantage of dynamic deployment and redeployment (although doing this in production is not recommended, it can be useful in development). This meant your archives could be fairly lean and only include the business code you needed. Unfortunately, this lead to bloated implementations of Java EE servers that had to account for any functionality that an application might need. It also led to over-optimization in terms of which dependencies to share (just put everything in the app server!) and which dependencies needed isolation because they would change at a different rate from other applications.
       
      The application server provided a single point of surface area for managing, deploying, and configuring multiple applications within a single instance of the app server. Typically you’d cluster these for high availability by creating exact instances of the app server on different nodes. The problems start to arise when too many applications share a single deployment model, a single process, and a single JVM. The impedance arises when multiple teams who develop the applications running inside the app server have different types of applications, velocities of change, performance or SLA needs, and so on. Insofar as microservices architecture enables rapid change, innovation, and autonomy, Java EE application servers and managing a collection of applications as a single, all-in-one server don’t enable rapid change. Additionally, from the operations side of the house, it becomes very complex to accurately manage and monitor the services and applications running within a single application server. In theory a single JVM is easier to manage, since it’s just one thing, but the applications within the JVM are all independent deployments and should be treated as such. We can feel this pain when we try to treat the individual applications and services within a single process as “one thing,” which is why we have very expensive and complicated tooling to try and accomplish that introspection. One way teams get around some of these issues is by deploying a single application to an application server.
       
      Even though the deployment and management of applications within a Java EE environment may not suit a microservices environment, the component models, APIs, and libraries that Java EE provides to application developers still provide a lot of value. We still want to be able to use persistence, transactions, security, dependency injection, etc., but we want an à la carte usage of those libraries where needed. So how do we leverage our knowledge of Java EE, the power it brings within the context of microservices? That’s where WildFly Swarm fits in.
       
      WildFly Swarm evaluates your pom.xml (or Gradle file) and determines what Java EE dependencies your microservice actually uses (e.g., CDI, messaging, and servlet) and then builds an uber JAR (just like Spring Boot and Dropwizard) that includes the minimal Java EE APIs and implementations necessary to run your service. This process is known as “just enough application server,” which allows you to continue to use the Java EE APIs you know and love and to deploy them both in a microservices and traditional-application style. You can even just start using your existing WAR projects and WildFly Swarm can introspect them automatically and properly include the requisite Java EE APIs/fractions without having to explicitly specify them. This is a very powerful way to move your existing applications to a microservice-style deployment.

          After building microservices with either of the Java frameworks we discussed, we need to build, deploy, and manage them. Doing this at scale using our current techniques and primitives is overly complex, costly, and does not scale. We can turn to new technology like Docker and Kubernetes that can help us build, deploy, and operate following best practices like immutable delivery:
          • Cluster Management
          • Failover
          • Load Balancing
          The book doesn't delve into, but points out the importance of:
          • Configuration
          • Logging, Metrics and Tracing
          • Continuous Delivery

          Further references:

          Katherine

          unread,
          Sep 18, 2016, 7:05:14 AM9/18/16
          to CCSF Coders
          The short version of this is that the enterprise Java ecosystem seems very complex.

          Would be nice to find a very simple lightning talk length to map out the current ecosystem.
          Reply all
          Reply to author
          Forward
          0 new messages