DevOps and AWS

DevOps is the practice about Development and Operations. It consists of a typical 'toolchain' of many tools that together describe how you should work on a software project. The main parts are as follows:

• Code – Writing the source code with a programming language. E.g. Java, Python, etc. This performed using an IDE, e.g. Idea IntelliJ for Java.
• Manage – Work has to be managed somehow, i.e. short, medium, long-term aims, sprints, issues, tasks, stories, bugs, milestones, etc. This can be managed with tools, e.g. JIRA.
• Store – The source code needs to be stored somewhere, e.g. using a Git repo hosted on GitHub, BitBucket. Similarly, built libraries will need to be stored and available somewhere, e.g. Nexus.
• Build/Package & Test/Release – The software will need to be built. Changes made to a library/repository that is used by another might have consequences. Or simply work done is ready for QA testing before production deployment. There are tools available to help automate and manage all of this for building software automatically according to your needs, e.g. TravisCI, Jenkins, TeamCity.
• Deploy – Software that has been built will then need to be deployed somewhere, i.e. for a test , development, or production environment. These environments and builds should be monitored too. Tools can be setup to help manage this as well.

AWS has solutions for all of these aspects, much like it does so for the infrastructure side of things. Examples of these are:

• CodeCommit - a private Git repo for your projects.
• Elastic Beanstalk for deploying, provisioning and testing servers.
• OpsWorks- manage stack implementations
• CodeDeploy - for deploying built software to AWS.

There is no obligation to use any of AWS' services, and you can use as many or as few of them as needed. They are paid-for services, but they all tend to have free limited usage still either during the first 12 months or over time, so you'll only pay for how much you go over the free provision, or plan to use in terms of numbers of commits, builds, etc. If you're considering to use AWS for these features, each service should be considered so that a good, timely decision is made so progress is not impeded and productivity is maintained.

DevOps is similar to being 'agile', i.e. employing methods and tools to increasing quality and quantity of work. Agile is more of a way of thinking, DevOps actually requires organizational changes - actual methods in the working culture and for delivering software.

DevOps can be implemented from the ground up to avoid future upheaval. It's really about applying agile principles, and there is no reason not to do this.

I'm sure we would all agree that it would be best to follow industry 'best practices' for tools and solutions. If other people have already performed analysis, and have detailed what options we have, and what the best options are for each use-case, then there is no reason to reinvent the wheel or procrastinate on matters. What matters most is finding a good solution quickly, and going with it. Even though this might not be the most perfect solution, perfect is the enemy of good.

An example of this would be for choosing a cloud platform: Google Cloud vs AWS. Both have almost identical offerings. Does it really matter which provider to go with? In general terms, no, as long as you go with something that fits what you want to do now, with a capacity for the future in mind. Such a decision does need to be agonised over in order to make rapid progress.