There has been a lot of hype around microservices, so one might think that enterprise development teams are rushing to build them. That's not what is happening, according to veteran Java middleware consultant Mike Croft. Once burnt by rapidly adopting other models, such as SOA, businesses are twice-shy about embracing microservices. Also, implementing microservices isn't easy, because "there's no one-size-fits-all model," he said.
Mike Crofthead of support, Payara
"In terms of actual implementations, I'm seeing businesses take a cautious, measured approach to microservices," Croft said in a video interview conducted at the 2016 JavaOne conference in San Francisco. He's in favor of DevOps teams doing strenuous due diligence before implementing microservices. "It's not a silver bullet, and there other challenges to overcome beyond the technical challenges."
Croft described the differences between implementing microservices and SOA and when and why to develop microservices instead of applications. He also discussed building microservices in Java EE and GlassFish development. Croft is head of support for Payara, which created and offers support for Payara Server, a drop-in replacement for GlassFish Server Open Source Edition.
Watch the video for more of Croft's views and advice on implementing microservices, building microservices and Java EE and GlassFish and more.
Transcript - Plan well and don't rush into building microservices, Java pro says
Hi, I'm Jan Stafford. I'm executive editor for TechTarget. I'm talking with Mike Croft, who is head of support from Payara. Mike, tell me, what do you think of the basic requirements or criteria for microservices and what are some of the challenges of determining them?
Croft: Well, there's been a lot that's already written about what the technical challenges of microservices are, what should define a microservice, how micro should a microservice be. And there's a huge amount of disagreement and … some people saying things like it needs to be just a couple of lines of code long; others saying, actually, just as long as it's a single unit and it's only got a single concern. But, for me, I think the really big challenge that is often underestimated is something that's encapsulated in Conway's Law, which states that any organization is bound to develop software that, kind of, reflects its own communication structure internally.
So, I think the biggest challenge that organizations face is not necessarily its technical challenges, but the management challenges that come … with going from a monolithic approach to developing software, where perhaps everyone [goes from] working together on a team, or the developers [are] together in a room, to working in multiple teams where you might have some developers and some QA and some build and, kind of, restructuring the organization to better reflect how you want your microservices architecture to develop.
Is there such a rush to microservices that people are using microservices incorrectly or might be building microservices when they should be building applications?
Croft: It's certainly a possibility. It's not something that I've seen so far. Certainly, the people I've spoken to … have been fairly cautious about this.
Obviously, a lot of people have made the comparison between microservices and what we had with SOA quite a few years ago now. And I think, you know, it's the old saying, 'Once burned, twice shy.' So, people have already seen how things worked out last time when SOA was kind of sold as the one-size-fits-all solution to everyone's problems; a silver bullet. So, although there has been a lot of hype around microservices, in terms of actual implementations, I'm seeing businesses take a slightly more cautious, measured approach to it. And I'm hoping that does continue because there are a lot of advantages to microservices, but as you say, it may not well be a one-size-fits-all approach.
The old techniques of SOA and large-scale enterprise service buses were fine and were appropriate for some of the customers who bought them, but not all of them. And I think … the main problem is that they were oversold into places where they didn't really belong. So, I'm hoping that the trend continues -- that people do proceed with a bit of caution, with a bit of a pinch of salt, realizing that it's not a silver bullet and that really there are other challenges to overcome beyond the technical challenges.
And when is it obvious that you should be building a microservice instead of an application?
Croft: I guess it's hard to say, really, because a monolith can do the job just as well as a microservice. So, what I see as a really big benefit of moving to a microservices approach is the fact that you have decomposed your application down into smaller units, which can then scale independently of the rest. So, as we look forward [to the] modern world of computing and we look forward to cloud computing, as Oracle [has] announced this week with Java EE and [its] new plans are much more cloud focused.
To really take advantage of public cloud opportunities where dynamic scaling is really a factor, what you really want to do is only scale the bit of your application that isn't heavy load. You don't want to have to scale up parts of your application that aren't really being heavily used. That's one area where you can really see some quick benefits from microservice architectures.
So, what I think really needs to be borne in mind is the fact that, sure, microservices can be good and can be very useful, but you need to have an idea of what you want to get out of them first. Don't just go for microservices thinking, 'Well, this may work for us.' … 'We think we'll probably get some benefit out of it.' But this benefit we're thinking of is ethereal. We don't really know what it is. Unless you have a concrete idea of how … your end customers are going to see some benefit from it, they're not gonna care about all the pain you go through in trying to get from a monolith to microservices because, at the end of the day, they just want their products to work.
What best practices do you suggest for writing microservices in Java EE?
Croft: Well, Java EE, I think from Java E7, has really, really come into its own as a mature technology. So, there are a lot of, kind of, false ideas out there about the kind of bloat that is around in Java EE, which, you know, if you go back … 10 years or so is, kind of, fairly well-deserved. But that has been taken on board by the developers of Java EE and has been addressed. So, I think … you need to bear in mind where the industry is going. So, things like the enhancements that Oracle has made recently … they're focusing on configuration, they're focusing on health check, JSRs and also multi-tenancy -- gives you a good idea of where Oracle sees things going.
There's also the micro-profile initiative, which is a collaboration between Payara, Red Hat, IBM and Tomitribe, and since the announcement back in June, we've had other members join. Hammock is one other implementation. This is another kind of viewpoint of where we're seeing that the future of Java EE might lie. And I think, really, the key there is fast iterations. So, we've got things like CDI at its core. We've got JAX-RS providing REST endpoints.
But there are still a lot of heated debates and a lot of to-and-fro from the community about what really does make a microservices platform. Because, of course, even within a single organization, you might have several different microservices, and each one of those might have a completely different set of APIs that it makes use of. There might be one or two core ones, but if you reduce things right down to that core, then you're left with something that isn't really all that useful to develop with. So, it's hard to find that balancing act between what is core for microservices in Java EE and what is getting too far down so that we lose what's useful.
What are some best practices for building microservices in GlassFish?
Croft: If you're building microservices in GlassFish, the first thing I would say is use Payara because -- well, I sort of have to -- but, yes, one thing that Payara has done is we have benefited from the way that GlassFish has been designed. So, when Oracle took over ownership of GlassFish from Sun, they re-architected it and based it around a modular [Open Service Gateway Initiative] framework, and, in doing so, what they've enabled is the ability for us to create what we've branded as Payara Micro.
Effectively what we've done is taken the APIs that were available in the web profile of Java EE, we've added a couple of APIs -- we've added JBatch and JCache -- and we've created a Java file implementation of Enterprise Java, which is now available to use to build microservices on. … I guess I kind of have to credit Spring Boot for popularizing the FAT JAR method of deployment, although I think other people have done that as well. We also allow the ability to deploy WI files directly to Payara Micro. So, we don't really limit people to methods of deployment.
Good. Well, thanks for talking with me.
Croft: No problem.
OK. And thanks for watching.