Source – theregister.co.uk
Microservices aren’t a new concept to Java – their forerunner was Service Oriented Architectures (SOA), which could be constructed, among other means, with the assistance of Enterprise JavaBeans (EJBs).
The fundamental concept behind microservices is applications should be broken down into small services that can be arbitrarily scaled independently of one another.
Think Netflix; their entire infrastructure is designed to spawn more web servers or databases as needed, and by all accounts they go pretty far down the code-sharding rabbit hole, obtaining efficiencies the rest of us can only dream about.
The problem with SOA approaches generally, however, was they weren’t very “micro” in their attempts to split up monolithic applications into services. They still retained a relatively large footprint.
The actual line between an SOA and microservices isn’t clearly delineated. At what point is a service micro enough to be a microservice? Some argue that the politics matter more: SOA was typically pushed on developers by magazine-wielding managers. The microservices trend is viewed as a more grassroots movement.
Since an exacting definition of what a microservice is doesn’t really exist, some find it easier to define what a microservice is not.
Fashions change especially in the world of dev, but regardless of the definition boundaries between SOA and microservices, SOA did introduce a generation of developers to the idea of message queuing – a concept that has become important to many of today’s microservices architectures.
Message queues let services to talk among themselves, an important notion if you want your application to actually do something and not choke while waiting for some other aspect of the application service structure to execute.
EJBs were handy because they involved Message Driven Beans (MDBs). MDBs are stateless, service-side components that are transaction and are activated by the EJB container when it receives a message. MDBs helped make EJBs a useful tool for those seeking to use Java to make services that plug into a message-queuing-based microservices architecture.
While EJBs served the needs of the SOA development paradigm just fine – even if the individual services were a bit fat – competing languages kept producing thinner, lighter approaches to microservices than the traditional EJB could deliver.
The pressure was on to make Java more efficient.
One of the more recent responses to this was creation of the Web Profilein Java EE 6. Applications using the Web Profile did not have access to the whole of the Java language and libraries. Only those sections deemed likely to be useful to writing “web-tier” services were included.
For a while, the Web Profile was good. Over time, however, ecosystems changed and pressure grew to support all the modern standards. At the same time the pace of Java version releases slowed. This spurred development of MicroProfile.
MicroProfile defines a Java EE profile that has JAX-RS, JSON-P and CDI. It is not a replacement for Java EE, but rather should be thought of as an extension of it, one whose goal is to keep the environment for microservices evolving to meet emerging standards faster than the language itself is revised. The changes will likely be fed back upstream when the language does experience a versioning event.
Unlike previous attempts to square the microservices circle that focused primarily on service footprint, MicroProfile tries to build a common base that can unite different factions of Java developers. The folks behind MicroProfile are very careful to say they don’t want to create a standard (or set of standards).
MicroProfile is closer to the definition of all the parts of the stack that the majority of Java ecosystem stacks can agree on. An example of this is the inclusion of JSON-P but not JAX-B. This strikes me as a clear statement that JSON-based REST APIs have won, and XML is slated for the dustbin of history. You can still manually include JAX-B (and JAX-P) if you want to play with XML, but the consensus choice is JSON.
Areas where there is still a great deal of contention – such as message queuing – are not defined. The inclusion of CDI does provide the necessary bits to bolt on your message-queuing solution of choice, but you have to make that choice. Use of Wildfly Swarm as the delivery vehicle keeps MicroProfile microservices light.
Finished in September, MicroProfile has the support of some big names that include IBM and Red Hat but it remains to be seen if it will be accepted by the community as a whole. There’s already talk, in the meantime, of extending MicroProfile, with some not happy that technologies they favour aren’t included – or aren’t being included fast enough.
The rest of the ecosystem
Naturally, this being developerland MicroProfile is not alone, and there exists a range of other tools and frameworks for microservics. These include the Akka, Play, and Lagom frameworks that have a strong following, mostly from Scala developers. Lightbend does include Java APIs, and the Play framework in particular has a significant Java developer following as well.
Hashicorp is a powerful name in the microservices world. Even non-developers have heard of some or all of their projects: Consul, Nomad, Packer, Serf, Terraform, Vagrant and Vault all have powerful communities around them. Vagrant in particular is hard to avoid, even for operations staffs. Mulesoft is another popular player.
Docker, Kubernetes, and Apache Mesos, of course, are the much-beloved titans of the operations side of the microservices world. One could reasonably add desired state-configuration tools like Puppet, Chef, Ansible and Salt to the ops side of the microservices list as well.
This is where Dev starts to meet Ops, as desired-state tools are more typically associated with the Ops side of movement than with the very developer-centric microservices movement.
They come together on the new ground of composable infrastructure. Similarly, the ability for infrastructure to be managed by code becomes a factor when buying anything from switches to SANs. To the microservices crowd, waiting on humans to provision infrastructure is anathema.
Java is once again moving with the times, which is handy for everybody out there in possession of Java skills in today’s cloudy, DevOpsy and composable infrastructure-defined world. That’s because microservices comes down not to the language you use but how applications are designed, not the tools used to write them. With MicroProfile, at least, Java devs are on more equal terms.
