Home » Software Development » Going Native

About Ashley Frieze

Ashley Frieze
Software developer, stand-up comedian, musician, writer, jolly big cheer-monkey, skeptical thinker, Doctor Who fan, lover of fine sounds

Going Native

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.

(0 rating, 0 votes)
You need to be a registered member to rate this.
1 Comment Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Tulcas
Tulcas
2 months ago

The price should be the reason to host your stuff.