AWS CodeStar enables you to quickly develop, build, and deploy applications on AWS.
Amazon recently announced their newest service AWS CodeStar. It's designed to simplify your AWS development workflow, and help you easily create, test, and deploy your applications on AWS, and it's completely free!
Out of the box
CodeStar provides a unified project dashboard which allows you to monitor application activity by tracking commits, builds, tests, and deploys across all stages of development, and view your application's performance statistics.
CodeStar also integrates with Atlassian's JIRA for easy issue tracking and project management, all from the same dashboard, and comes with built-in role-based access policies, making it easy to manage access for project owners, contributors, and viewers, across all services simultaneously.
Amazon has a pretty good tutorial for getting started with CodeStar but I wanted to go through the process first hand and share my experience.
In this tutorial I'll go through how to create and deploy an application using CodeStar and then I'll talk about some of the pros and cons of using CodeStar, some of CodeStars limitations, and what else is out there.
Accessing the Dashboard
Getting started with CodeStar is actually quite simple. Click on Get Started Today from the CodeStar main page.
This will take you to the CodeStar dashboard where you'll be able to view all the projects you've created. If this is your first time (which I'm assuming it is), then you'll see this:
Click on Start a project to, well... start a new project.
If you haven't set up IAM permissions (like I hadn't) then you'll be prompted to grant CodeStar permission to administer AWS resources on your behalf. Click Yes, create role to continue.
If you don't have admin permissions to create a role for CodeStar you'll have to apply the AWSCodeStarFullAccess manage policy to your IAM user, or have an admin do so for you.
Creating a Project
From your CodeStar Dashboard you're given the option to launch over twenty different project templates (27 to be exact). Each template gives details about what type of infrastructure they'll create.
You can use the left panel to easily sort the different template options, and if you need help choosing a template you can click on help me choose.
Ruby on Rails
I was curious to see how setting up a Ruby on Rails application felt compared to Heroku, since that's been the easiest method for nearly a decade.
I chose to launch a Ruby on Rails applications running on Elastic Beanstalk. After naming my application, I simply clicked Create Project and CodeStar did the rest:
If you haven't already added an SSH key to AWS, you'll be prompted to before you can continue:
You can watch your application progress in the top right-hand corner of your dashboard.
In the mean time, you can spend some time looking around the management dashboard. From here you'll be able to manage resources, monitor application performance, view your codebase and commits, manage teams, create deployment pipelines, and track issues. Pretty neat.
True to Amazon from, they pretty much provide you with everything and the kitchen sink. It's actually a little overwhelming at first. Take this with a grain of salt, but let's just say it's your typical Amazon dashboard experience.
After about 15 minutes my application was complete, and I was able to view it using the Application Endpoints section on the main dashboard.
The template Rails application was actually really cool. It wasn't just a default Rails app, but it was a well designed, custom Rails application.
The application was branded to the region where I launched my app, and would even change backgrounds based on the time of day. The developer in me thought this was pretty silly, but the person in me thought it was actually pretty awesome.
Viewing the Codebase
From the left-hand dashboard menu, click on Code and you'll be able to view your applications remote AWS CodeCommit repo. From here you can see the code base, and view and compare commits.
I didn't go over everything you could do with CodeStar here, since that a little outside of the scope of "getting started". I may do another article in the near future that goes into more details about all of the available features.
For now, you can use the left navigation to do everything you'll need to do to manage your application. You'll set up pipelines, manage teams, create and manage environments, and more.
I want to finish off this article talking about what I liked about CodeStar and what I didn't like, or wished I'd seen.
What I liked
I liked how simple the project creation process was. It was easy to get started, select the template I wanted to use, and launch my project.
I liked that, as my project was being created, CodeStar walked me through additional setup I'd need in place to develop, deploy, and manage my application once it was done being created.
The last notable thing I liked was the default application. I think it was really cool that AWS branded their default application rather than just have a particular frameworks default look.
Something I want to mention, but I'll go over in more detail the next section, is the dashboard. The dashboard has a lot of cool features and things you can do with it but, to be honest, it's all quite overwhelming.
What I didn't like
I want to be objective in my analysis, and so I'm trying not to be too critical of CodeStar. I will say upfront, however, that I've been using Nanobox for the past 6 months, and it has built up some high expectations.
Time to provision
The first thing that caught me off guard was how long it took to provision the infrastructure. Their introductory guide mentioned that the infrastructure would be up in a matter of minutes. In my mind, I was thinking like five minutes or less, which is what I've become accustomed to with Nanobox.
Ultimately it took my project about 15 minutes to get up and running. This was much longer than I would have liked, but thanks to the configuration steps they walked me through it didn't feel as long.
AWS all the things
This next one won't necessarily be a drawback for everyone, but it is for me. To get any benefit out of CodeStar you're locked into using AWS for everything.
The main drawback with this in my mind is that I don't get any benefits of CodeStar anywhere else. I can't use CodeStar with DigitalOcean, Linode, etc., which I get since Amazon wants to make it easier to use their services. I'm just used to the flexibility that Nanobox gives me to deploy to any host I choose.
I was a little surprised at the somewhat limited languages and frameworks that CodeStar supported out of the gate. It makes sense that they would pick the most popular frameworks for the most popular languages:
- Java - Spring
- Ruby - Rails, Sinatra
- Python - Django, Flask
- PHP - Laravel, Slim (I thought this was interesting)
But, I would have liked to see support for Golang, Elixir (Phoenix), and some more Node.js and PHP frameworks. I'm certain they'll add more in the future, so this is really just more unfortunate than anything else, at the moment.
I would have liked to see some streaming logs rather than just the ability to download the last 100 logs or all the logs...
When I'm troubleshooting a production application it's nice to have the logs available to help facilitate the process. It doesn't seem that ideal to download the last 100 logs, then if I don't see what I need in there, download all of them.
I've gotten used to seeing streaming live and historical logs so I can hit the web page and watch exactly what's happening. It ends up being so helpful when troubleshooting issues, it would be hard to do without.
Something else I found a little confusing was the release workflow. Using the Pipeline dashboard you create your project build and release pipelines.
In these pipelines you'll add different steps for build, test/CI service integrations, and release deployment. Ultimately it wasn't very clear exactly how it all worked and would take some playing with to get down.
The 800 lb. Gorilla
Time to address my biggest gripe with CodeStar, and it's the same gripe I have about any AWS product really... the dashboard. The dashboard is so big. Massive really. In fact, there are four dashboards you interact with, each with their own left navs.
In my mind CodeStar promised simplicity by removing all the complexities of DevOps. I get that with something as complex as DevOps it's hard to hide it all behind a dashboard UI. It's very hard to find what you're looking for, and understand what it all does. Eventually, you'd probably figure everything out, but even then... it would still be too much dashboard.
For me, workflow is a big deal. While CodeStar does remove the need for DevOps in my workflow, replacing it with a huge, convoluted dashboard, isn't really what I was hoping for.
What else is there
As I mentioned before, I've been using Nanobox for the past 6 months, which should make sense since I'm an engineer at Nanobox. A fact I'm not trying to hide.
It was really great to get a chance to use CodeStar and see that a company like Amazon has found the same problems in the industry that we have, and are addressing them in a very similar way.
We believe that while DevOps is a very important part of an application's life cycle, it's something that should be automated, controlled by the application developer, and not handed off to a middleman.
I'm not going to sit here and tell you all the great things about Nanobox and how it compares to CodeStar, because, although they are trying to solve the same problem, they do it very differently.
I will, however, encourage you to give them both a try. Nanobox does address some of the concerns I brought up about CodeStar, but there are also things that Nanobox doesn't do quite as well.
Pretty much everything I outlined in the What I Liked section are the areas that CodeStar does better than Nanobox. And then, some of the things I outlined as drawbacks (for me) won't be considered drawback for everyone.
Either way, this is a really exciting time for application developers. Just like with the advent of Heroku and PaaS, we're seeing a huge change in the development landscape, and it's becoming easier, by the day, for application developers to be in full control of their applications, from development to production, and beyond.