What is our primary use case?
We happily use containers as a way of scaling out microservices so we use Nexus Repository for the management of containers, as a kind of repository. That's about 50 percent of what we use it for. The other side is that it is used for application and development artifacts. We use it to track artifacts in a repository so we can deploy software code. It's not a code library because we GitLab as well. It's more for the compartmentalized aspect that fits in and we can redeploy those on-demand.
The way we deploy it is private cloud, ultimately. We have an internal cloud infrastructure that we operate and the Nexus platform sits inside it. We are looking at ideas around integrating this into AWS right now, because we are doing a huge kind of transformation project to move a lot of our on-prem services into public cloud. We're looking at that whole "bridge" between the cloud and on-prem and how we deal with that. That's something of a stepping-stone before we can take everything back into the cloud. I think Nexus Repository will eventually end up there.
How has it helped my organization?
The key benefit we get from it is speed to delivery. It has improved our overall time to get new applications out with new code. That's true whether from a platform perspective, where we are quickly deploying up-to-date Docker containers, or whether we are looking to deploy new code out to deliver a new application. That whole release cycle is vastly improved. The way we've automated a lot of our processing, particularly with us being very much a cloud-centric organization, it helps with our ability to deliver code and then scale out as we need to.
Initially, we did a deal with Sonatype to get a small number going to see what the general, intangible benefits were. The developers were certainly happy with the way our product was working. And then there was fact that we had more control of it, being on a computer on somebody's desk, that it was more centrally managed. I do have a really strong feeling that if we took it away, overall productivity would drop off. How much? I don't know but it certainly would drop off. We would probably lose people as well, since they like the tool.
We did a survey, a tool-chain analysis across the whole company, because we've got many different tools doing all sorts of similar things. At the top of the chart, in terms of people loving them, across the business — in particular the developers — were GitLab and Nexus. Nexus Repository is seen as a key, useful, strategic tool that we use here.
What needs improvement?
We've had some challenges around the database they use. We've had some big outages and it's due to the fact that we haven't found the database they use is all that stable. I think they've realized that themselves. We're probably not the only customer who has complained to them about that. They're realizing there is a problem with the proprietary database and hopefully they'll be giving customers options to move to different database types. We've had some really positive conversations with Sonatype around that and they've provided us with the support and special services to help us migrate off of that, onto another type of database platform which we have more control over.
For how long have I used the solution?
We've been using it now for about two years.
What do I think about the stability of the solution?
The stability is okay. We've had some storage issues just recently, which wasn't anything to do with Sonatype. If the data is moved from one storage array to another storage array, it takes the database offline and, as a consequence, the application goes offline as well. And then it is labor-intensive to bring the service back.
It all comes down to their database. It's very sensitive — you really have to talk to it nicely and do things in a very controlled way. We have a whole host of applications and databases running across our storage arrays, and this is the only product that really causes any real grief when we move data from one array to another. The real problem is their proprietary database. Once we got off that, the stability, I reckon, will be a whole lot better.
In the last 12 months we've had about four or five major outages. We had some in the evening, which you might think would be okay. Well, that's fine for the UK, but we operate in Manila, we operate in New Jersey, we operate in Las Vegas; we're pretty much all over the world.
We have been very clever in terms of how we take outages and get them communicated. It is one of those heavily used products and when it is down people are quick to shout.
We have about 500 people using it right now.
What do I think about the scalability of the solution?
How are customer service and technical support?
Technical support is not perfect, but quite good. On a scale of one to ten, it's a seven or eight. They're generally responsive and knowledgeable.
They aren't a ten because it's not always easy to get ahold of them by telephone. In a lot of the cases things have to be logged by email. As much as they are very responsive, on occasions when we've had some real outages, we haven't had the response times that we would expect the vendor to provide for a mission-critical tool. When we do get on and start working with them, the knowledge and attention to helping resolve the problem is really good. In fact, that part is excellent.
Which solution did I use previously and why did I switch?
We were using the open-source and free version of Nexus. Prior to that we weren't using a competing solution.
We liked most of the things that we got with the free version. The extra capabilities we got were things like being able to support multiple data centers, a better support structure around high-availability. In addition, the whole aspect of having support at all was also among the main reasons we went for the product.
How was the initial setup?
The complexity behind the initial setup was due to the infrastructure that we had in place. The overall tool wasn't so bad. It was just adapting the Nexus product to be deployable across our internal cloud platform.
In terms of starting the project, getting it ready for deployment took about six to eight weeks overall. Getting people onboard and using it took a lot longer; to get people migrated across. But getting the platform up and running, from my point of view, didn't take that much time at all in terms of doing all the testing, disaster-recovery testing — everything that we have to do before we can commission a product to enter live service.
We've got it deployed across multiple data centers. Even though we use our internal cloud, we've got three data centers in the UK and one in Gibraltar. We have high-availability across all areas. It only operates out of one data center at any one time, but we've got the facility set up so that if we need to bring it up in another data center, we can.
In terms of the support we got from Nexus, they helped set things off and they did so mammothly. I use the word "training," but it wasn't like, "Come train us." It was more of an educational process. They took us through some scenarios of how we could migrate solutions across, how we would work in it. That was good.
What about the implementation team?
We used the technical resources from Sonatype plus our own internal guys. There was one guy from Sonatype, and an architect and two systems engineers from our side.
What was our ROI?
We don't really measure the return of investment on this particular tool. It was put in as an essential-tool product.
I do have a real gut feeling that if we didn't use Nexus Repository, it would affect the productivity of our developers across two cities in the UK, Leeds and London, as well as Gibraltar, Krakow in Poland, and the guys out in Manila, New Jersey and Las Vegas. Being able to have one product that we can scale globally, for developers across our organization, has been great.
What's my experience with pricing, setup cost, and licensing?
One of the challenges we had around licensing was how to deal with anonymous requests. According to the letter of the contract, an anonymous request consumes a license. We had to do some work to get over the fact that any anonymous interactions with the Repository product had to be put back to an end-user account. We discovered this by chance when we were going through the whole licensing situation last year. We have plugged those anonymous gaps now, so we're okay.
Going back to the scalability, when we had anonymous connections in there, we probably were running at about 5,000 and there were no issues.
I don't know whether we get a great deal or a bad deal compared to other companies. I've not done my research on that. But in terms of the price point that we're charged, I know the people who actually sign the checks for this and they're happy to pay — if anybody's ever happy to pay for anything at that particular level. So the pricing is fine.
If you run it through your own infrastructure that's the only additional cost. If they could do a software-as-a-service product, we'd probably take it, if it was something that could scale and integrate into our pipeline. We're certainly having a really good conversation with people at GitLab right now around that very thing, around software as a service, rather than having to build our own platforms and the whole management around that. We're cloud-first as a business organization, so if there was something that they could do better, it would be to provide that SaaS-based solution. I don't know if it's available in other countries, but it's certainly not available in the UK.
Which other solutions did I evaluate?
We didn't look at any of the competing products at the time because we were happy with what we're getting from the open-source product. And we were happy with the conversation that we had with Sonatype around their Repository enterprise product. So we went with that.
What other advice do I have?
Talk to Sonatype about how flexible they can be around their licensing. We did purchase 500 licenses, but initially we were around 20. Rather than paying for the whole thing, I would say, "If we commit to the 500 over a particular period of time..." and have that conversation about what a realistic ramp-up would be. See if you can be charged for the number of users you have, rather than paying for 500 users but only using 20, which is what we did. It wasn't an effective use of money at that point. If I was doing it again, I'd have a better commercial conversation with them around how we could ramp up the costs over a defined period of time.
One of the biggest lessons we have learned is don't underestimate how much developers will potentially like the product. As soon as we started testing it, we had developers all over our organization really wanting to be part of it. And that's why we ramped up so quickly. We wondered whether we would cause all-out war at one point. We had a few minor speed bumps along the way but nothing really critical. A lot of it was about account permissions and those kinds of things. But other than that, it went really smoothly. The lesson learned is to make sure that you keep a touchpoint with your account management team.
And as part of any type of initial project, I would certainly get one of Sonatype's technical guys on point. We got somebody to work with us to give us that initial induction training and supporting us by checking out the solution definitions that we put together to deploy Nexus Repository across our own structure. We worked really closely with them and that is one thing I would recommend, unless you've got some great Nexus skills in your organization. We didn't look at other systems integrators to work with us. We went straight to Sonatype.
Initially, we had the open-source, freeware version and we had lots of different things like Docker repos around it. We've consolidated that down. We've got the enterprise version of Nexus now. We use it as a consolidated product for all teams across the business. We use Nexus IQ as well to provide that layer of security around it. We're not averse to using open-source repositories and pulling them down. But due to the level of requirements in the organization, we have to have adequate security controls in place, so we use that. I'm not a security tech expert by any stretch but it helps us when we use open-source.
In terms of the solution integrating well with our existing DevOps tools, I would say it does, but with a bit of caution as well. It's getting better. In terms of our pipeline that we use to deploy applications out there, we have integrated with Jenkins to help deploy through some kind of built pipeline. It takes a little bit of developing on our side to get that working properly and effectively.
As for maintenance, we keep things up to date. It sits inside what we call an infrastructure cloud tooling team. That team consists of about six engineers but it doesn't take six engineers full-time to maintain it. It takes about one day a month's worth of time to maintain at most. It's not high maintenance at all. It's when things fail then that it becomes a bit more intense. But overall, when things are running really nicely, then it's hardly any effort at all.
I would rate Nexus Repository at eight out of ten. Once we move it to one of our own internal databases, as opposed to using the proprietary database structure, that will probably move to a nine or a ten. It's an excellent product overall.