Can we do Hot deployments (updating running code) in Spring Boot applications running outside the IDE.
I see that "spring-boot-devtools" is mainly used when developers work through code changes in their IDE but, am looking for hot deployments in Stage or Production environments.
This 'Hot Deployment' feature was shown as one of the highlight in OSGi when compared with Spring Boot based Microservices. Hence am trying to clarify if such a facility is offered by Spring Boot.
Related
I’m looking for some distributed tracing technologies for our spring boot services, in the internet, I see we have 2 popular choices I.e opentelemetry agent and spring cloud sleuth.
I see both of the them have good integration support, I’m confused to which one to go for, please give me some suggestions
As of today, you can find the following announcement on the Sleuth's Spring page:
Spring Cloud Sleuth’s last minor version is 3.1. You can check the 3.1.x branch for the latest commits. The core of this project got moved to Micrometer Tracing project and the instrumentations will be moved to Micrometer and all respective projects (no longer all instrumentations will be done in a single repository).
Additionally, sleuth is not playing nicely when trying to integrate tracing with other java-but-not-spring-exclusive libraries. To afford any such implementation you would need to configure Sleuth to use the open-telemetry tracer.
Thus, my advice would be to go for open-telemetry, unless you have an exclusive reason not to do that.
As for my current approach, I was introducing otel into an established project that is due for a Spring Boot 3 migration next year. I thus opted to use non-sleuth Spring otel libraries to avoid coupling with Sleuth in this short period.
I am not sure if that's a good approach, but with a lack of proper Spring 2 -> 3 migration, this way will not be a blocker until you can migrate other deps over
I've been learning spring boot for a while and as per my understanding, we use spring boot only to create the project along with dependencies and embedded servers. It doesn't have much of a role while working on the project or after the project is created.
I mean, if i were to work on an enterprise application for a company, chances are that, there is already a project created using springboot and I don't have to really use spring boot anywhere while working on that project.
Is my understanding correct?
I've tired googling, but did not find a clear answer.
No. You may still need to use the following spring-boot features after creating a project :
Externalise the application properties
Test the application using testing utilities and annotations provided by spring-boot
Use its auto-configuration feature to quickly configure if you need to enhance your application with other library/framework afterwards.
Use its developer tool to make you have a better Dev experience (e.g automatic restart the app when code changes , hot-reload static content etc.)
Use Actuator to monitor your application health and gather metrics.
I mean, if i were to work on an enterprise application for a company, chances are that, there is already a project created using springboot and I don't have to really use spring boot anywhere while working on that project.
I think you can say pretty much the same about any framework out there. I can't agree with this statement in general.
Every framework (including spring boot) provides a set of features that you may opt to use or not to use in your project.
So yes, for each existing microservice you'll have a #SpringBootApplication class.
Also probably set of configurations / practices how to work with configurations.
You'll already have also spring beans on existing project.
However software constantly evolves (otherwise it doesn't make sense to hire programmers, you know).
So when you (as a new employee) need to create a new micro service then, congratulations, you're using Spring boot features.
Other day-to-day tasks include (just a couple of example out of the head):
Create Integration Tests (#SpringBootTest)
Define new configuration Properties
Use Actuator
Use Metrics + define new metrics
Reconfigure Logging
Writing Liquidbase/Flyway migrations
Integrate new set of beans (Configurations)
Use Autoconfigurations
and so on and so forth.
If you want to really understand what you're doing while implementing these tasks you should know how do relevant features provided by spring boot work.
Question regarding correct set up of microservice infrastructure with Spring Cloud projects. Let's assume there are service discovery, Gateway, config service and some custom service. All of them have dependecy to Spring Cloud projects of version Camden.
And it is necessary to upgrade one of them (let say Gateway) to version Edware.
Should the rest of microservice also be upgraded to version Edware or can safety stay with Camden?
By looking at release notes of Edgware.SR3, seems like there are couple of fixes in config but thing to notice is Eureka is moved to 1.7.2
Not sure which Camden release you are on but supposedly, if you are on Camden.SR7 and planning to migrate to Edgware.M1, there are many releases in between which you have to keep track of and changes that occured in between.
You can find the release dates & sequence here
Other than that, there are no more changes so far(atleast not in the release document) that could affect your discussed architecture.
Best bet would be to try and test.
I have an interesting decision to take for my project.
We use spring boot for our micro services.
The development environment is spring boot wíth tomcat in the embedded mode.
However, I am not sure if there are any advantages/ drawbacks if I choose this way in production too.
The counter argument is to deploy a war in a separate tomcat.
I am not able to think on any buying points for both views
What will be the best choice for a large enterprise production system on cloud(jar/war)?
I saw some recommendations here (but I need more stronger reasons to chosse/ not choose any one): Spring boot embedded container or war file in an external container for production
here are my points to use fat jar for production deployment.
fat jars are simple to build and deploy.
Spring Boot aims to be production ready, by default. This means that
it ships with useful defaults out of the box that may be
overriden, if necessary.
Fat JARs are good for running as the microservices as managing
microservices is already a burden then why one more step to
configure and deployment should be considered.
fat jar can also run as a java service easy to manage by a single command, restart server/jvm can be managed automatically.
Spring boot is Embedded with- Tomcat, Jetty and Undertow so changing
app server for any micro services is not a big deal.
We have started new project on spring stack and using latest versions. But we have workflow requirement and I used activiti in past. But as I see there is no spring boot 2 support for activiti and camunda. Can anybody suggest which BPM is best that can be integrated with spring boot 2.
You will find a bunch of Spring Boot 2 starters in the Flowable github repo.
The documentation explains step-by-step how to create a BPM enabled Spring Boot application. There is also the blog post The road to Spring Boot 2.0 that the improved support for Flowable within Spring Boot as part of the Flowable 6.3.0 release.
You ask for suggestions on which BPM is best. Well, I cannot be objective since I am part of the Flowable Team, but I can say that our Spring Boot implementation is pretty neat:
All engines are supported (BPMN, CMMN, DMN), both embedded and exposing their respective REST APIs.
There is an automatic configuration of Spring Security to use the Flowable IDM engine (in case no other custom security is configured).
There is no "EE" version of the starter. Flowable provides Spring Boot 2 support 100% Open Source.
The Spring Actuator integration is quite powerful.
Did I mention Open Source? ;-)
In order to get the all engines you would need to use the flowable-spring-boot-starter(-rest) dependency. The (-rest) needs to be used if you want the Flowable REST APIs to be automatically configured.
There is also the option to run the BPMN, CMMN or DMN engines in standalone mode. For that you would need one of the following dependencies:
flowable-spring-boot-starter-process(-rest)
flowable-spring-boot-starter-cmmn(-rest)
flowable-spring-boot-starter-dmn(-rest)
So, compare for yourself, but for me, it's pretty clear and of course I am open to discussion.
The Activiti is working on Activiti Cloud fully based on Spring Boot 2 and Spring Cloud Finchley (targeting kubernetes deployments, but it can be used outside kubernetes if that is not your thing) if you are looking for a BPMN runtime for Cloud Native applications. We are working hard on releasing the first Beta1 release at the moment, and we will very welcome feedback about it. Hope this helps.
If you use the camunda-bpm-spring-boot-starter you can write self contained services running camunda process engine with spring boot 2.