More AWS Services, More Choices, and Still a Challenge
Amazon Web Services is known for rapid fire announcements of new functionalities. Last week, in particular, there was a flurry of new functionalities announced, targeted at DevOps and the integrated development environment on AWS.
I have mixed feelings about AWS, specifically their UX. To really be effective with the platform you have to specialize — but after you get it down, it’s not that difficult. The other challenge I have had is how the services are presented; it’s hard to find the exact one I’m looking for.
With that said, last week they added even more services, and they threw a lot of interesting tools out to the DevOps audience. Lets see what they are:
I understand the logic for private Git servers, but it still bothers me. But as long as enterprises scream for it, and solutions like Perforce make money, clearly there is a need. And the fact that you can have them in AWS with everything else is nice. This is what CodeCommit is: cloud-based private Git instances. It is said the biggest advantage is security and integration with existing environments, which is a big sell for enterprises. But it does not go beyond this. I want to see automatic webhooks when you build an application, so that you don’t even need to wire your source repository in.
A built-in continuous delivery solution for your AWS applications. I have mixed feelings about this one, mostly because I’m so used to talking about AWS release automation in the context of how to integrate it with release automation tools like Go and Jenkins. My second apprehension is that AWS has now piggybacked on the CD unicorn. Continuous delivery and deployment imply certain types of applications, and ones that do not fit in all development shops. However, from what I can tell, it’s just a workflow tool, meaning it can be used for continuous integration or deployment, as well. And from the looks of it, it also seems pretty complex to setup. It really is a combination of S3 Buckets and CodeDeploy more nicely tied together.
Writing an API is the “easy” part. Monitoring, securing, documenting, and scaling it is the hard stuff. Not too fun, either. The gateway handles all requests to applications running on EC2, Lambda or any other web application. It is also reported to help automate the creation of the API. Not something I have tested, but I know is extremely valuable if it works — and as a backend developer, if APIs are not your thing. It is also PaaS-based, which is fantastic. You get to avoid additional nodes on your frontend and just forget about those servers all together. Which simplifies the DNS architecture substantially. And finally, it has a “pre-built” dashboard for users of CloudWatch for some analytics.
Wow, this one is not going to make Perfecto or Xamarin feel very good. But, obviously, no big surprise. Device Farm is a cloud of physical devices, and a mechanism to easily deploy and test your applications on them. Today they support a test grid of 250 devices, and easy integration into your release automation tools, like Jenkins and Go. This also fuels the heated debate between developers and QA of testing on emulators versus real devices. This does make the real-device option easier, but they are still slower, and less flexible than emulators. I am currently of the belief it is not one or the other. I would think testing in a CI environment with emulators in a rinse and repeat manner — and then during delivery using a limited suite of tests on real devices — is an ideal scenario.
A small enhancement. The ability to have User Data Protocol (UDP) traffic to your Docker containers. This will give more flexibility for rich media (video and voice) applications, in particular. On the flip side, if the developers using UDP in containers do not consider security, this is an easy door for many hackers. What is more important about this announcement is the steady drumbeat the Container Services group is committing to.
All of this — in addition to the announcements two weeks ago at AWS Summit NYC, like the addition of Chef in the marketplace — makes it clear that AWS is thinking one layer above individual services, and more about the entire environment.
But there are so many services it is hard to connect the dots. What I am really hungry for is Amazon to group everything together into a comprehensive DevOps package, where it is all tightly integrated as soon as you create a new application. Without this, it is hard to imagine a development shop that is not completely disjointed.
With every new announcement from AWS it is clear to me that if you come, and you build it, you will never leave. You are stuck. The lock-in is dramatic; however, completely worth it. You can have not only AWS for your application, but your development environment as well.
Docker is a sponsor of The New Stack.
Feature image: “Packaged food aisles of supermarket in Portland, Oregon, United States of America” by lyzadanger is licensed under CC BY-SA 2.0.