Does anyone have experience with running Spring Cloud Micro Services in production?
I have about 10 micro services within one big Maven multi-project. This means that all the source code is under a single repo. The advantages are that it is easy to check out and manage the project in my IDE.
My concern is with CI as it means that the build server will need to figure out which services changed and deploy them respectively. Alternatively all the micro services will be deployed every time a change is committed.
I'm eyeing exploding the project into a source repo per micro service (my gut feel is that this is the correct approach). This way only the affected service is deployed.
My goal is to run every micro service as a container on Kubernetes.
Do you have any advise / tips / concerns that you can raise that might be an unwelcome surprise down the line?
More important than separating codebase is to create a separate CI/CD pipeline per microservice (running its own unit and integration tests), and another pipeline to integrate all microservices and run end-to-end tests.
Since you plan to release your microservices as Docker containers, consider a Docker Registry for versioning and distribution of your images.
Here are some references that follow this idea: DZone, Microsoft
Related
I have a spring boot project with 4 microservices (Eureka service registry, Config server, a Zuul gateway and a userservice) in one repository with a parent project where I have a docker-compose.yml which reads the Dockerfiles in the microservices project and uses the "application-docker.yml" and "bootstrap-docker.yml"
What I'd like to do is to trigger a jenkins pipeline after a commit in git so that it will compile and deploy the microservices in Docker. Eventually I'd like to have a production configuration that deploys the images in Kubernetes maybe AWS.
Now, in order to work, the microservices need to start in order:
configserver
eureka service registry
gateway , etc..
What is the best practise?
If I have separate repositories per microservice, I think I can figure it out. It should be easy to deploy a single microservice assuming that configserver and eureka service registry are already up and running, in reality they should never change.
If I have a single repository, and I keep developing new microservices, do I need to have separate jenkins file per microservices or can I have a jenkinsfile in the parent project and use docker-compose?
How does it work? Any articles online that can help (couldn't find any). Does it make sense?
Or do I need to look at Jenkins X ?
Thanks!
I would recommend using separate repositories for each microservice. You use microservices to prevent monoliths and have small well-defined services; it only seems appropriate to also separate them by space i.e. store them in separate repositories (making it for example easier to reuse one).
You would then have to provide a Jenkinsfile in each repo. These would be mostly identical.
If you want fast release cycles you could automatically deploy a single service upon release.
Alternatively you could use an additional release train module that handles the full deployment.
In both cases I would use a docker-compose file that handles the interconnection between the services.
You can enforce the right order by using 'depends_on, links, volumes_from, and network_mode: "service:..."'. For a full reference see the docker documentation.
If you want to keep your single repository your Jenkinsfile(s) would have to be quite hacky, I suppose... After each commit you would either
build all modules --> monolithic behaviour
somehow determine which modules have changed (e.g. looking at the git log) --> same behaviour as with multiple modules but very hackily
The Docker-Compose File
If you want to release all modules at a specific point of time you could use a Release Train module where the docker-compose.yml resides next to a Jenkinsfile. Then when you want to ship your application you can start this Jenkins-job.
If you want to ship each service as soon as it is released, independently from the others, you would need to access the docker-compose.yml from each module. You could do this manually (since the files won't change too often) or create a docker module that you use as a git-submodule in all your services.
We use a generic docker-compose.yml for this, where every version is replaced by a variable:
example-service:
image: example.service:${EXAMPLE_SERVICE_VERSION}
Then to start that specific service in jenkins we use the command
export EXAMPLE_SERVICE_VERSION=1.1.1
docker-compose -p example-project -f docker-compose.yml up -d example-service
I have a multi-modules vertx application deployed on OpenShift. For integration testing purposes, I would like to deploy a database container with pre-defined data, and destroy it when the test is finished.
How can I achieve this ?
My application uses junit and maven fabric8 plugin to deploy containers in Openshift.
This is something that could be done relatively easy using arquillian-cube, which does support Kubernetes and Openshift.
What arquillian-cube can do for you, is to (optionally) create an ephemeral project, deploy everything you need for your test and once everything is up and running, then start your tests. In the end it can also do the cleaning up for you.
It is quite flexible so according to your needs and requirements it can work with either ephemeral or fixed projects. And also there are pletny of configuration options when it comes to cleaning up.
Last but not least, it does play quite nicely with the fabric8 maven plugin.
https://github.com/arquillian/arquillian-cube/blob/master/docs/kubernetes.adoc
I am trying to convert a normal monolithic web application into microservices structure using Spring Boot and Spring Cloud. I am actually trying to create Angular 2 front-end application and calls these my developed microservices in the cloud. And I am already started to break the modules into independent process's structure for microservice architecture.
Here my doubt is that, when designing the flow of control and microservice structure architecture, can I use only one single Spring Boot project using different controller for this entire web application back end process?
Somewhere I found that when I am reading develop all microservices using 2 different Spring Boot project. I am new to Spring and Spring Cloud. Is it possible to create all services in single project by using different modules?
Actually, it doesn't matter to package all those services into ONE project. But in micro-service's opinion, you should separate them into many independent projects. There are several questions you can ask yourself before transforming original architecture.
Is your application critical? Can user be tolerant of downtime while you must re-deploying whole package for updating only one service?
If there is no any dependency between services, why you want to put them together? Isn't it hard to develop or maintain?
Is the usage rate of each service the same? Maybe you can isolate those services and deploy them which are often to be invoked to a strong server.
Try to read this article Adopting Microservices at Netflix: Lessons for Architectural Design to understand the best practices for designing a microservices architecture. And for developing with Spring Cloud, you can also read this post Spring Cloud Netflix to know which components you should use in your architecture.
Currently I am working on microservices too, according my experience we have designed microservices as step below,
Maven
You should create the project with different project. But actually you can separate your project to submodule. So you will be easy to manage your project, the submodule you can use with other project too.
Build the Jar Library put your local repository. it can save your time, you have just find the same component or your functionality then build the jar file put in your local repository , so every project that use this function call point to download this repository, you don't have to write many project same same.
So finally I would like you to create different springboot project, but just create submodule and build local repository.
By creating your modules in different projects you create a more flexible solution.
You could even use different languages and technologies in a service in particular. E.g. one of your services could be NodeJS and the rest Java/Spring.
I am new to microservices and am learning Spring Boot
I have IntelliJ Ultimate and am wondering how best to structure my microservice code
For the system that i am building that will have a few microservices should I..
Open 1 IntelliJ containing a module for each Spring Boot microservice
Open multiple instances of IntelliJ and have one Spring Boot microservice per instance of IntelliJ
I think it will be tricky to do 2 if I have a lot of microservices but I do not know if IntelliJ is able to have multiple Spring Boot microservices running at the same time in one instance of IntelliJ
Any advice on how you work with microservice code / projects would be appreciated.
InteliJ is able to have a lot of Spring Boot microserices/application running at the same time. It have no impact on performance, even if you run all microvervices in debug mode. I would choose first option. This is an approach, we are using in our poject:
Start new project in IntelliJ.
For each microservice create new module in InteliJ.
Benefits:
If someone new want to work on that project, he can import one
project and have all microservices imported at once. Even if he would
work only in few of them, he can look how others are build.
in InteliJ you can create Run Configuration as "Compaund". So, when you want to run all your services at once, you can do it with just one click.
But, if you have 1500 employees, want go full netflix way and create 500 microservices, then better way will be to keep them separate :)
One of the benefits of microservices is organisational scalability. You have several teams working on different microservices at the same time. Also, it should be possible to develop, build and run each microservice on its own. If you don't have those goals, you get all the complexities of microservices and very little of the advantages.
In such a scenario, each microservice should live in its own version control. As long as this is given, if the IDE supports multiple version control sources per module, go for 2). Otherwise I guess you must stick with 1).
Which is good in production environment? Individual embedded tomcat for each app or one tomcat for many apps?
The idea of making micro services is mainly to build services that are developed/ deployed/scaled independently. When you try to deploy multiple microservices inside a same container/jvm then you may not be able to leverage all these benefits. Also you CI/CD/integration testing may be hard. Try using embedded containers or container technologies like Docker which ensures complete isolation of the microservices.
The decision also depends on what is the deployment environment of yours. If its cloud going for Docker would be a good idea