DevOps as a Service on AWS

DevOps has become the go-to methodology for many organisations looking to improve their application development and deployment process. 

But implementing the entire pipeline yourself can be a bit of a time and resource blackhole. 

Luckily, DevOps as a service (DaaS) providers can help you go from zero to hero relatively fast – but as with anything, there are pros and cons.

Below, we look at some of the technical capabilities and limitations of DaaS for AWS users.

What is DevOps as a service?

DaaS providers offer all the benefits of DevOps without the need for organisations to build their processes from scratch. 

In essence, DaaS means moving the DevOps lifecycle to the cloud and having it set up, managed and owned by third-party specialists. 

DaaS providers are flexible, sometimes managing everything from code repositories to server deployments and sometimes just supplying DevOps engineers to monitor and test on an ad hoc basis.

Any good DevOps as a service provider (a club we like to think of ourselves as a long-time member of) will have experience finding the right balance between outsourcing and ownership – but in some situations, you may still want to keep everything in-house.

How does DaaS differ on AWS?

Every major cloud provider, including AWS, offers its own suite of DevOps tools. DaaS providers will work with a mix of these and/or 3rd-party alternatives (such as Jenkins) depending on their skills and your needs.

So, understanding DaaS on AWS means understanding AWS’s DevOps suite and exactly what the pros and cons of DevOps as a service are.

DevOps tools and processes on AWS

The core tenet of DevOps is setting up a continuous integration and delivery (CI/CD) pipeline, sometimes called the DevOps lifecycle. This enables you to quickly and automatically build, test and deploy your code, which is the end goal of DevOps. 

A CI/CD pipeline will include several steps, in general:

• Code commit – developers check code into a central repository where it is automatically built and tested
• Code build – a build server compiles the code and runs automated tests
• Unit testing – unit tests verify that individual pieces of code are working as expected
• Integration testing – integration tests verify that different modules work together as expected
• Deployment – the code is deployed to a staging or production environment
• Monitoring and logging – the application is monitored for performance and errors. Logs are generated and analysed to identify issues which are fed back to the developers – and the whole process starts again

Now lets look at the tools that would be used to make this happen.

AWS CodePipeline

CodePipeline is a continuous delivery service that automates your release pipeline. It allows you to easily model, visualize and automate the steps in your release process.

CodePipeline integrates with popular source control providers such as AWS CodeCommit, GitHub, Bitbucket, and more. It also integrates with build tools such as AWS CodeBuild, and AWS Elastic Beanstalk.

Often compared directly with Jenkins, the open source CI/CD tool, CodePipeline comes with one key difference.

 With Jenkins, you need to set up and maintain your own server. CodePipeline is a managed service, so there is no infrastructure to set up or manage. 

CodePipeline integrates natively with other AWS services, so you can easily build a complete CI/CD pipeline without installing additional plugins.

AWS CodeBuild

Used for creating deployable packages from your source code, this continuous integration tool compiles your code, runs tests, and produces artefacts ready for deployment.

You can start a CodeBuild project with just a few clicks from the AWS Management Console. You simply specify your source code location and choose your build settings. Then CodeBuild takes it from there, automatically pulling in the necessary tools and dependencies to run your build.

AWS CodeDeploy

The next part of the suite is AWS CodeDeploy. With CodeDeploy, you can deploy your application revisions to Amazon compute instances, on-premises instances, or both.

CodeDeploy is designed for developers who want to take a hands-off approach to deployment. It automates the entire process, from getting the code ready to verifying that the new version is running as expected.

AWS CodeStar

For a simpler way to get started with DevOps on AWS, you can use AWS CodeStar. 

CodeStar provides a unified user interface where you can manage all the resources needed for your software development projects.

With CodeStar, you can quickly set up a complete CI/CD pipeline for popular programming languages such as Java, PHP, Python, and Ruby. You can also use it to build pipelines for serverless applications using Lambda functions.

Critically, this is an overlay on top of the existing AWS resources. This makes it easy to get started with CI/CD without having to learn the details of individual AWS services – that can be detrimental in the long run, however, and it may be more useful to familiarise your development team with AWS CodePipeline instead. 

DaaS vs. DevOps on AWS

When deciding whether to go it alone or partner up with a DaaS provider,  there are four key considerations:

• In-house knowledge/resource: If you’re already familiar with the DevOps tools on AWS and you have the spare hours, then implementing your own AWS DevOps pipeline could be the way to go. However, without these things, the DIY option will entail a serious investment. You’ll likely need to hire a full-time DevOps person, or run the risk (as so many do) of overstretching your engineers and getting something half-baked. 
• What (exactly) is your DevOps hole? DevOps as a service providers vary in terms of flexibility. Some might only provide DevOps engineers on an ad-hoc, gap-filling basis; some might only take on projects when they’re doing the full build. Some do both. Before choosing whether to outsource or keep it in the family, identify exactly what it is you can’t do right now.
• Cost: DevOps as a service pricing will vary depending on the provider and the services you choose. For a set-up you can go on to manage yourself, a DaaS provider makes more sense. However, if you already have a salaried team with DevOps knowledge, you may just want a DaaS provider to cover things like out-of-hours deployments.
• Limitations: When you use DaaS, you’re limited to the providers’ features and services. If you want to add or remove any tools or processes, you’ll need to work with the provider to make changes.

How we can help 

There is no one-size-fits-all answer for whether or not you should use DaaS. The decision depends on your specific needs and situation. 

However, as DaaS extraordinaries, we’d be remiss to not suggest you give us a look. 

We’ve carried out DevOps projects for major brands around the world, so to discuss your DevOps and DaaS needs, or anything else, just get in touch.