Not long ago Amazon announced their newest service, AWS CodeStar. This is a pretty exciting development in the world of application development.
What I was really hoping to see from CodeStar, was a tool that would replace my least favorite aspect of web development… DevOps. While it’s interesting, and I handle it well enough, I don’t actually like doing it.
Creating and configuring servers gets tedious, and managing those servers in production is nerve-racking. CodeStar has a lot of potential to simplify an app developers workflow, but I wonder if it offers enough to completely replace the need for me to configure and manage infrastructure.
What You Get
Out of the box CodeStar supports Java, JavaScript, PHP, Ruby, and Python. It has “templates” for each language that are used to provision an entire application infrastructure in minutes. Templates can be used when launching apps on EC2, AWS Lambda or AWS Elastic Beanstalk.
Each app has an accompanying dashboard where you can track commits, builds, tests, and deploys. You can also view your application’s performance stats, and track issues with a built-in JIRA integration.
When you look at everything you’re getting, CodeStar sounds amazing. It sounds so amazing that it even generated a little concern about the future of DevOps…
CodeStar seems like it could be the solution application developers looking for. The question is can it deliver on all it’s potential? I figured I would take it for a spin and find out.
I’ll walk through the process I took to deploy my first application using CodeStar and share my thoughts on the experience.
Getting Started
CodeStar makes it easy enough to get started. From the CodeStar main page I clicked Get Started Today.
This took me to my CodeStar dashboard where I could see all my applications. Since I hadn’t created any yet, I saw this instead:
After clicking Start a project I was prompted to grant CodeStar permission to manage AWS resources on my behalf. This was because I had never set up my IAM permissions. To continue I clicked Yes, create role.
Creating a Project
I was presented with 27 different “template” applications to choose from. Each template gave me details about what type of infrastructure would be created.
Ruby on Rails
I wanted to see how the process of launching a Ruby on Rails app felt in comparison to Heroku, since that’s been the easiest method for nearly a decade.
I chose to launch a Ruby on Rails app on Elastic Beanstalk. After naming my application, I clicked Create Project and CodeStar did the rest:
I was prompted to add an SSH key to AWS since I hadn’t in the past. Once I added my SSH credentials I was able to continue creating my app:
The Dashboard
I was able to see the progress of my application in the top right-hand corner of the dashboard. While my app was being created, I took the time to look around a bit.
There was so much to do, I didn’t know where to begin…
From the dashboard I could manage resource, monitor application performance, view my codebase and commits, manage CI pipelines, and much much more. True to Amazon form, they pretty much gave me everything and the kitchen sink. It was actually a little overwhelming.
Sometime after the 15 minute mark, my application was complete. 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 a lightly branded, custom Rails application, that would change backgrounds based on the time of day.
The developer in me thought this was kind of silly, but the person in me thought the attention to detail was actually pretty awesome.
So Much To Do, So Little Time
I can’t possibly go over everything I was able to do and see in the dashboard, we’d be here for days. I’ll just highlight a few of the things I liked, and then some of what I didn’t.
What I liked
I liked how simple the project creation process was. It was easy to get started, select the template, and launch my project. I liked that CodeStar walked me through additional setup, as my project was being created.
I also liked that I was able to view my application codebase, and commit history. Since it’s all hosted in an AWS CodeCommit repo, they have it right there in the dashboard.
The last notable thing I liked was the default application. I think it was really cool that AWS branded their template application.
What I didn’t like
I’m trying not to be too critical of CodeStar, because I want to be objective in my analysis. However, I’ve been using Nanobox for the past 6 months, so I had some very high expectations.
Time to provision
The first thing I noticed was the time 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.
Ultimately, as I’ve already mentioned, it took my project closer to 15 minutes to get up and running. This was much longer than I would have liked. The only saving grace here was the fact that during that time I was walked through some additional configuration, which made it not seem as long.
AWS all the things
This next one is a drawback for me, but maybe not for everyone. To get any benefit out of CodeStar you’re locked into using AWS for everything.
What is the point of having such a cool tool if you can only use it in one place. If I want any of the benefits of CodeStar I am locked into using AWS. Although I’m not constantly deploying my application all over the place, it still felt a little stifling.
I like knowing I have the freedom to deploy my app anywhere I want… just in case.
Language/Framework Support
I was a little let down by the limited language and framework templates CodeStar supported out of the gate.
I would have liked to see support for Golang and Elixir (Phoenix), and some more Node.js and PHP frameworks. I’m sure they’ll add more in the future, but again, compared to what I’m used to, this felt very limiting.
Logs
Something that was very odd to me was how you access your logs with CodeStar. You have the option to view the last 100 logs, or download your entire log…
When I’m troubleshooting a live application I want streaming logs. Plain and simple. It makes it so much easier if I can hit the page and see exactly whats happening. Also, rather than seeing 100 or everything, I like to step through my logs chunks at a time to follow the output back to the source of the bug.
Workflow
This is a big deal for me, and using CodeStar felt like a huge step backwards. I’ve been doing all of my development in isolated development environments that I can deploy anywhere.
I don’t have to manage languages, versions, dependencies. All that is taken care of for me. I describe my applications environment and it’s configured the same every time, locally or in production. With CodeStar it felt like I was going back to doing things the “old way”.
The 800 lb. Gorilla
Time to address my biggest gripe with CodeStar. It’s the same gripe I have most AWS products really… the dashboard.
“The problem with [Amazon Dashboards] is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” ~ Joe Armstrong
While this quote is actually speaking about object-oriented languages, I feel like it describes perfectly the feeling I get when trying to use CodeStar.
While the dashboard has a lot of cool features and things you can do with it, it’s massive. In fact, the dashboard is so big, it’s actually four dashboard masquerading as one.
On paper CodeStar seemed like it offered simplicity by removing all the complexities of DevOps. In the end, all the complexity has been localized into a dashboard that’s hard to find what you’re looking for, understand what it all does, and how it all works together.
“EVERY THING ON IT — Shel Silverstein”
Conclusion
The fact that Amazon recognizes there is a problem speaks volumes. They’ve taken a leap in the right direction, but fell a little short. As it stands, I don’t think CodeStar is going to be the end of DevOps. It just isn’t quite there yet.
I’ll stick with what I’ve been using. It gives me a complete development to production workflow, and checks all the boxes along the way. It’s not that I can’t do DevOps… I just don’t want to have to anymore.
I love learning, creating, and building. Thats why I enjoy development so much. But, I’m exhausted from having to be a full-stack, DevOps, sys. admin, rockstar, ninja, guru. I just want to write code, and make cool stuff.
Maybe it’s because I’m a 30-something developer, but my neck hurts from wearing so many hats.