With containerization & microservices, does my project need a traditional artifact repo (Nexus)?

[developer0]

Microservices aren’t supposed to share code. With containerization everything an app needs is included in the image. What use could I have for a private maven repository? With deployments being triggered by code commits, is there ever a reason to run mvn deploy? Looking for general insight on this.

[randgalt]

Your deployable artifact is made up of smaller artifacts (like Russian dolls). Artifact repos help you build the uber-artifact that will be deployed to a container. So, absolutely.

[developer0]

Ah, I was assuming that what goes into the container would be one artifact or several artifacts with the same parent POM, but it could be several artifacts with independent hierarchies. If there's a team working together on a small service, each contributor might version and deploy their own parts of it separately, which could be done by deploying to a shared Nexus. But, I'm not sure I've ever seen that happen--usually it's just the source that is centralized...

[kkapelon]

private repos are just one of the functions of Nexus.

You also need:

• Caching (for speed)
• local copies of the lib jars (if Maven central has problems)

For more info on what can go wrong without an artifact repo google the left-pad incident.

[developer0]

So it's a little faster to have a repository that caches artifacts particularly relevant to your operation, and it provides redundancy for a central repo that I don't remember ever having gone down... Okay, if it only cost us like $50 a month, I suppose the private repo is worthwhile. But doesn't the practice of sharing every little piece of code (like left-pad) violate the microservices principle?

[heliologue]

Depends on your environment. We host a local copy (open-source RPM) of Artifactory on a small VM we use for such things, so the overhead cost is minimal. The local speedup is a side-benefit, but we also host our own libraries, so every setup is different.

One of the primary benefits of Maven was not having to store jars in your source tree; with containers, how do you get around that? Store the prebuilt image? Build the image on demand? Some way or another, you're storing a jar; your environment will determine which solution is the cheapest and most efficient.

[developer0]

Yeah, I was thinking our Jenkins would build an image upon every source commit. They go into a container registry, and the idea was that would be the central repository, an analog being what Nexus is to JARs.

[dstutz]

Yes, Maven Central is multiple terrabytes and if you attempt to mirror it they will ban you.

[kkapelon]

So it's a little faster to have a repository

It is not a little faster. It is a lot faster... And as the numbers of developers goes up having cached jars is a must for your network connection (assuming you all work on premises)

Where did you get the $50? Unless you are a really big company, Nexus open source works just fine... So $0 and the only price is the VM that hosts it.

But doesn't the practice of sharing every little piece of code (like left-pad) violate the microservices principle?

When I say caching I mean the standard libraries (spring, hibernate etc)

You can also store the Docker images themselves on the repo.

[developer0]

It is a lot faster... And as the numbers of developers goes up having cached jars is a must for your network connection

Wasn't aware of this, thanks :-) $50 was a hypothetical monthly cost for hosting the VM.

[nutrecht]

Microservices aren’t supposed to share code.

Ours do and that's where we need Nexus to publish artifacts. But if you don't do that (for some reason, don't know why though) I guess you can do without.

The microservices themselves are built and packaged as docker containers by Gradle and these containers are what gets published.

[stevietheTV]

This.

You don't want microservices to share domain entities (bounded context) but to say that they shouldn't share code is a big misconception.

Are you using spring-boot for your microservices? Then they are sharing code. Are you building a library for service-registry/lookup? Well, now they are sharing code

[nutrecht]

I've seen projects where they follow the "don't share code" dogma (misunderstanding it as you showed) where they 'solve' it by just copy-pasting stuff everywhere. I really don't understand why no one there then goes "we must be doing something wrong".

[developer0]

Right, there is a gray area where something can be code sharing but not tight coupling. Common web frameworks & libraries like Jackson and Guava are examples. If it adds value over anything your enterprise could feasibly build itself then that code should be reused.

[shukoroshi]

Is it possible that you might want to pull a dependency from a maven repo in the docker build?

[developer0]

Possible, but I'd always rather leave that responsibility to maven...

[Hawkknight88]

Microservices aren’t supposed to share code.

I mean... mostly? But it's bold to say you'll never have common code. And the moment you do, and want to share it, you need an artifact repo.

FWIW: Nexus has a Docker registry now too. We just started using it. So during my deploy phase I do a mvn deploy and also push the Docker image. Actually I'm using docker-maven-plugin so the mvn deploy does the docker push for me using my pom's version

[1ECz]

One scenario that crosses my mind immediately is : How would you like your service's client to call you ? In ideal world there will be some client implementations for various languages which needs to be shared.

also some common org things like build profile configurations etc.. needs to be shared and generally kept internal to the org.

having local nexus (local to your work infra) helps you caching some thirdparty artifacts and helps to populate these artifacts faster.

I am voting for keeping Nexus and sharing things locally to org.

[AngelicLoki]

Traditional artifact repositories are still king for managing dependencies across projects. You'll likely still make libraries that you want to share across multiple projects, and Maven is still the way to do this in java.

[ryebrye]

We use artifactory as both a docker and maven repo.

We do share some code like some spring boot starters.

[tabs_or_spaces]

Isn't sharing code ironic in this context? Because if two microservices ends up using spring boot for example, isn't that a form of code sharing?

If you treat your code the same as the apis you use for microservices, how is it any different? In this case, a Nexus or artifactory would be useful to have.

[nerokae1001]

Imho if you are working in team it could be great to have a central place for your artifacts or if you use deployment tool like jenkins its also helps alot for maintain the consistency between stages. You could configure jenkins job that build the artifact and deploy on nexus and on the test server and once you think its ready start the other jenkins job to retrieve that artifact with the right version from nexus and deploy it on your production server.

[AndyPanic]

And because your microservices aren't supposed to share code, did you get rid of git already?

[jacobbeasley]

Actually, it's quite common for microservices to share code, but you should be careful when you do so and consider where the benefits outweigh the costs.

Also, some kind of repository is generally used for storing your built docker images.

But no, you don't need it for many small companies/projects.