If I look at recent projects, I’ve used various forms of Git, a few variations on Jenkins, and the leading repository services – Artifactory and Nexus.
In general, most of my recent work has been backed in some ways by AWS. Similarly, most of the services, have been self-hosted.
I can’t quite bring myself to switch from GitHub or GitLab to AWS Code Commit, but with the thing I’m about to write, it might seem like I should.
Stop Hosting Your Own Stuff!
Unless you’re a big IT player, selling hosted services, you gain very little by hosting your own build tooling. A repository, for example, requires maintenance, access rights, patching, disk management… it’s a potentially busy job.
If you’ve adopted AWS, then why not use the tools that AWS provides to do all of these things?
- Docker images – ECR – it’s simplistic, but it works a treat, and is essentially boundless
- Published artifacts – Code Artifact – again, a simple list of packages, but the basic minimum you might need
- Code… ok… maybe your favourite Git provider has a better UI than CodeCommit, and if you’re using a SaaS version of it, you might be better off… and maybe even a self-hosted one for corporate security reasons… but try not to
- Builds – CodeBuild – it’s basic in ways that don’t matter, and can pretty much do anything – WITHIN YOUR VPC where you need it
- Deployments – add a wrapper around AWS like Terraform or Ansible if you must, but Cloudformation works pretty well
The point is that the AWS ecosystem provides incredibly workable alternatives to making your own thing, and they work well and evolve under you.
When Shall I Deviate?
I don’t think security should be a reason to use your own tool rather than an AWS provided one. If you don’t trust AWS for security, then don’t use it at all!
Maybe eventually you’ll discover some must-have features ONLY available in a particular tool that you CANNOT live without. But I bet that’s not the case at the start of a project, or even that it’s as important as it first seems.
Starting with the native tooling as a default and then splitting off into vendor-specific products when you need to is, in my view, a better and faster route to success.
Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: Going Native Opinions expressed by Java Code Geeks contributors are their own. |
The price should be the reason to host your stuff.