I have been testing out microservices lately using springboot to create microservice projects. The more i understand about the setup the more questions i am confronted with.
How are all the microservices that are running, managed? How do developers manage, deploy or update microservices via a central location?
When deploying multiple instances of a microservice, do you leave the port to be decided during runtime, or should it be predefined?
I am sure there will be much more questions popping up later.
Links used:
http://www.springboottutorial.com/creating-microservices-with-spring-boot-part-1-getting-started
https://fernandoabcampos.wordpress.com/2016/02/04/microservice-architecture-step-by-step-tutorial/
Thanks in advance.
Microservices do tend to go out of control sooner than later. With so many services floating around, you need to think of deployment and monitoring strategies ahead of time.
Both of these are not an easy problem, but you have quite a few tools available at your disposal.
Start with CI/CD. Search around it and you will find a way around. One option is to make use of Jenkins for Blue/Green deployments
In this case jenkins will be one central place where you manage your deployments (but this is just an example, we do have quite a lot of tools build around this that may help you better based on your needs)
Other part of this problem lies in when where you tend to deploy stuff? Different cloud providers have their own specific ways of handling microservices and it depends on your host really. But one alternative is to make use containers.
If you go with raw containers like dockers directly you will have to take care of mapping ports (if they are deployed on same host machine) but then you can use abstraction on top of this like if you are on AWS then you can consider ECS or docker swarms or I personally prefer Kubernetes. You do not need to worry about the ports on which they are and can directly talk to your service over a load balancer. There is lot that is missing in here and you really need to pick one such tool and dig deep, but there are options out there for you to explore.
Next is monitoring, if you are going with kubernetes, you do get lot of monitoring tools out of the box that will help you access the service logs query them etc. But you also need to make sure that from development perspective you do provide for correlations id's, api metrics, response times, because you will need them to debug issues when its comes to microservices specially one related with latencies. If you are not on kubernetes you can still get all these features added but individually, like ELK stack for log monitoring (as you do not want to go to each service to check for logs), zipkin for tracking , API gateway and loadbalancers for service discovery and talking to containers.
Hope this helps you get started.
you can start with the following:
Monitoring :
Start with spring-boot-admin and prometheus.
https://github.com/codecentric/spring-boot-admin
Deployment:
Start with docker and docker-compose and move to kubernetes.
Few examples for docker compose:
https://github.com/jinternals/spring-cloud-stream
https://github.com/jinternals/spring-micrometer-demo
There are container services/container management systems available for example Amazon ECS, Azure container services, Kubernetes etc which take care of automated deployment by centralised repositories like Amazon ECR etc, automated scale up/down of microservice instances, take advantage of dynamic port allocations to run multiple instance of same service on a single instance/host and also give you a centralised dashboard to monitor resource usage and infrastructure events.
You can make use of any one to get answers to all of your questions as all of them provide most of the functionalities needed for managing your microservices.
I'm going to performance benchmark a large Java application. What is the best approach to do it?
It is POJO-based application that consists online part with UI and WebService layer, but the most of heavy business logic is in long running batch processes implemented with Spring Batch. The application is deployed on JBoss Application Server and persists data in Oracle database.
What I'm looking to get is not only the throughput of batch process or number of concurrent requests handled by online layer. I'm also looking to get more insight and gather some internal metrics for things like batch job steps, JDBC etc. Furthermore I'm going to correlate the metrics with system-wide metrics I can get from JVM, OS, application server, database.
Ideally I'd like to do it with no code modifications if possible.
My idea to implement this kind of performance monitoring is to rely on JMX and provide a central component that can gather metrics from various MBeans and correlate them. It seems that each main component I want to measure is JMX-enabled:
JBoss Application server has extensive JMX capabilities
Spring Batch can be JMX-enabled with Spring Batch Admin extention
JVM is OK for all it's internals exposed via JMX
Oracle with DMS MEtrics also give good insight into performance of JDBC link
I was wondering if there are any good open source frameworks/tools that could help me with collection, correlation and visualization of the metrics as described above. Thanks in advance for your recommendations.
P.S. I have done my homework and browsed the open source scene with that regards, but I don'w want to put any specific names here yet to avoid biased answers.
I need some help here after a few days of trying to learn spring I have given up trying to find a decent resource.
I am making a Web Application and this is my first full application and I want to use Jersey to make it and also use Spring . I am Using eclipse IDE and Maven as a build tool.
With these settings how is the best way to set up such a web application. Ie the application context ect also do i need to configure some sort of container to run the application on the server as with working with some examples they run fine locally but not on deployment.
If anyone has any tutorials that they have used or infact any resources they are greatly appreciated, Ideally want to have an application set up that uses simpleJDBCtemplate and i can then just code my backend implementation into it.
Help!
Thanks
Chris
I found that the source code given at http://gitorious.org/java-rest-example was very helpful in getting a Jersey app up and running quickly. It uses Jetty, which I've found to be a fast, lightweight web app container. That example doesn't use Spring, but for a basic REST application, you might not need it.
As for a Spring resource, I bought the book Spring Recipes: A Problem-Solution Approach
and found it helpful for explaining Spring from the ground up. One thing I liked about it is it shows you the simple/naive ways of achieving something followed by more sophisticated/cleaner ways of doing things.
As a seasoned Spring user I was assuming that Spring Integration would make the most sense in a recent project requiring some (JMS) messaging capabilities (more details). After some days working with Spring Integration it still feels like a lot of configuration overhead given the amount of channels you have to configure to bring some request-response (listening on different JMS queues) communications in place.
Therefore I was looking for some background information how Camel is different from Spring Integration, but it seems like information out there are pretty spare, I found:
http://java.dzone.com/articles/spring-integration-and-apache (Very neutral comparison between implementing a real-world integration scenario in Spring Integration vs. Camel, from December 2009)
http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Comparing Camel with other solutions, October 2009)
http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, October 2008)
Question is: what experiences did you make on using the one stack over the other? In which scenarios would you recommend Camel were Spring Integration lacks support? Where do you see pros and cons of each? Any advise from real-world projects are highly appreciated.
We choose Camel over Spring-Integration because the fluent API is really nice. We actually use it in Spring projects and use Spring to configure part of it. The programming API's are clear and there is a large set of sensible components.
We did a small scale shootout and basically at that time for our requirement Camel won. We use it mainly to transfer internal datafiles to/from external parties which usually requires format conversions sending it using ftp/sftp/... or attaching it to an email and sending it out.
We found the edit-compile-debug cycle reduced. Using groovy to experiment setting up routes are added bonuses.
Spring-Integration is a great product too, and I am quite sure it would satisfy our needs too.
I only recommend Spring Integration if you already have got a Spring project and you have just to add some "basic" integration using File, FTP, JMS, JDBC, and so on.
Apache Camel has two main advantages:
Many, many more technologies are supported.
Besides, a (good) XML DSL, there are fluent APIs for Java, Groovy and Scala.
Because Apache Camel has very good integration with Spring, I would even use it instead of Spring Integration in most Spring projects.
If you need more details, you can read my experiences in my blog post: Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel?
I have recently conducted a Camel vs Spring Integration shoot-out with the aim to integrate Apache Kafka. Despite being an avid Spring developer, I sadly found my suspicion with Spring's ever-growing Project stack confirmed: Spring is awesome as IOC-Container to serve as glue for other framework, but it fails at providing viable alternatives to those frameworks. There might be exceptions to this, namely everything to do with MVC, where Spring came from and where it does a great job, but other attempts to provide new functionality on top of container features fall short for three reasons and the SI Kafka use case confirms all of them:
Introduction of a long-winded difficult to use DSL for XML-configuration.
Pages of xml-configuration code to get all framework components wired-up.
Missing resources to provide functionality on par with dedicated frameworks.
Now, back to the results of my shoot-out: most importantly I am impressed by Camels overall concept of routes between endpoints. Kafka seamlessly integrates with this concept and three lines of configuration are enough to get everything up-and-running. Problems encountered during the process are neatly addressed by ample documentation from the project team as well as a lot of questions on Stackoverflow. Last but not least, there is a comprehensive integration into Spring that leaves no wishes unfulfilled.
With SI on the contrary, the documentation for the Kafka integration is quite intense and still fails to explain clearly how to integrate Kafka. The integration of Kafka is pressed into the SI-way of doing things, which adds extra complexity. Other documentation, e.g. on Stackoverflow is also less plentiful and less helpful than for Camel.
My conclusion: cobbler stick to your trade - use Spring as a container and Camel as system integration framework.
It really depends on what you want to do. If you need to extend something to build your own messaging solution Spring Integration has the better programming model. If you need something that supports many protocols without custom code, Camel is ahead of Spring Integration.
Having a small scale shootout is a very good idea, just make sure you're trying to do the type of things that you'd typically be doing in the project.
--disclaimer: I'm a Spring Integration committer
Most comparisons of Camel and SI that I've seen don't take the following into account:
1.) The effect that Spring Boot has had on developer productivity for Spring Integration
2.) The effect of Spring XD has had on making Spring Integration applications available with no code compilation - also Spring XD sources and sinks are simply Spring Integration channel adapters, when you're looking to extend Spring XD.
3.) The effect of Spring XD has had on making unifying Spring Integration, Spring Batch, Spring Data (+Hadoop!) in one stack, effectively bringing batch and stream processing, HDFS/Apache Hadoop support, and much more to Spring Integration.
4.) The effect of the soon-to-be-released Spring Integration 4.0 Java DSL https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference
For your consideration,
/Pieter (disclaimer I work at Pivotal)
We are using Spring Integration for our application and now considering to move to Apache Camel as we encountered lots of issues with Spring Integration framework. Here are couple of issues.
The CachingConnectionFactory which Spring provides opens 1000's of idle connections in IBM MQ and there is no guarantee that these connections are reused. And still these connections will stay open forever which creates troubles on the MQ side. Had to restart the application every week in lower environments just to refresh the connections. Apache Camel also provides Caching and the connections seems to go up/down based on the load.
Spring doesn't provide mappers for QoS parameters. Even if you enable QoS, the delivery mode and expiration/timetolive properties will get lost (I am going to raise a JIRA issue for this). Apache Camel handles this and QoS parameters are sent to upstream applications and not dropping it.
I am right now working on issues with handling the exceptions and transactions with Apache Camel which Spring seemed to handle better with AOP.
Apache Camel is a very good framework and very complete too. But if your application uses spring, my personal advice is to use Spring Integration.
Spring Integration is the integration EIP complaint framework of Spring-Source ecosystem. It has excellent integration with the ecosystem: Spring boot, Batch, XD; even the core uses same abstraction starting from Spring Framework 4. Some of the messaging abstraction were moved in the framework, as proof that the basic messaging abstraction of Spring Integration is very strong. Now Spring framework for instance use the messaging abstraction for Spring Web, web socket support.
Another good thing in a Spring application with Spring integration respect to use Apache Camel is that with Spring integration, you can use only one Application Context. Remember that the Camel Context is a Spring context. if you have the chance of use a new Spring version, I suggest to use Spring Integration Java DSL for configuration. I use it on my new projects, and it feels more readable and clear. I hope that this reflection can help you for the your evaluations.
Actually, I would say FTP has graduated its incubation period. You can do a simple search on SI forums/JIRA to see what new features were implemented and bugs that were fixed. From various chatter it seems like there is already some production usage out of it, so I would suggest to give it a second look and of course communicate your concerns to us via
http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT
Cheers
Oleg
Disclaimer: I am Spring Integration committer
One reason to use Camel over Spring Integration is when you need a more featureful EIP set. Spring Integration doesn't provide abstractions over things such as ThreadPool.
Camel does provide additional constructs for this simplifying some of the aspects of working with concurrent code:
http://camel.apache.org/camel-23-threadpool-configuration.html
If you have no need for this sort of thing and just want to connect file, JMS, FTP endpoints etc... then just use Spring Integration.
Camel act as middleware for application where one can perform data modeling, transformation of message values and choreography of messages.
If your current application is in Spring and require features which are supported by Spring Integration of EIP then Spring Integration is the best option else require more third party supports/protocols/file formats etc
We need to add WorkFlow to our Spring managed application. Does anyone have any useful experience in using any of the myriad of OSS Work Flow solutions? Which one is best? Which one integrates with Spring best? Which ones should we avoid?
If you only need some simple process orchestration, Spring's own Web Flow, despite its name can serve as a orchestration task manager. If you need to preserve state for several days then you will need to become an 'early adopter' of one of the open-source projects. You may want to look at Eclipse's BPEL project.
My hunch is that once a clearer picture of the BPEL/BPM/Workflow space emerges you will see Spring provide an abstraction layer the same way they have for JDBC, Transactions, ORM frameworks etc...
Like Brian said if you're doing anything of great complexity you might look at using BPEL.
There are a number of open source BPEL engines, one that comes to mind is Apache Orchestration Director Engine
I second Spring Web Flow. Depending on how complex the process is, Web Flow is great for managing various states and I've found that it's pretty easy to pick up and there's a good amount of documentation out there for it.
ActiveVOS is by far the best BPEL engine in my opinion. Download the evaluation version and give it a go. JBoss have even adopted their open source offering.
We're looking at Drools/Guvnor, possibly integrated with jBPM (as in this presentation), to add a workflow engine to our Spring/Java EE app, but we're still in the very early phases of trying it out.