I saw a lot of hand-wringing about depending on cloud services after the S3 outage yesterday. I experienced this myself because I was trying to do a tutorial that required the creation of some S3 buckets and couldn’t do it for the better part of the day. I thought about how much development would be hampered without access to AWS if my development platform was entirely based on AWS.

The real issue is points of failure and the tradeoffs relative to other features of a system. In this case, if you want global scale for your service you are either dependent on a cloud provider or you must build out that capability yourself. And if you build it yourself can you honestly say to yourself that you can build a more reliable service than a dedicated cloud provider?

There are so many ways you can architect an application for deployment on AWS and it seems to me that the options only increase when you have an existing application. One of our original thoughts was that we would create a multi-tenant version of our application. We then considered an application deployment per tenant. Neither of those had strong appeal so we’re investigating a native AWS solution.

Once we decided to use the services that AWS provides, we’ve come across more decisions to make. We need to manage data flow, so do we use Simple Queue Service (SQS) or Simple Workflow Service (SWF). No wait, new applications should you Step Functions not SWF. Elastic Beanstalk or Lambda or both? Java, Python, or Node.js? Angular, React, or Vue.js? The decisions come up and down the stack.

Some team members want to know which to choose so we don’t go down deads. I’ve come to the opinion that you make a decision and run with it but make sure you are open to and leave the option for change. It’s all so fast moving and changing that best practices and technologies will shift throughout the life of your application and you have to account for that. I think this was always the case, but in days previous to the cloud we could bury our heads and move on from a project before it came to bite us.

One of my teammates suggested that we should all consider getting the AWS Certified Solutions Architect - Associate certification. Our AWS consultants agreed and recommended the courses from A Cloud Guru to prepare for the certification test.

I’m about 2/3 of the way through Certified Solutions Architect - Associate 2017 course and have found it very educational. The material and labs are well paced and easy to follow and the mini quizzes at the end of each section are a good review of the major concepts that were being conveyed.

I don’t actually know what to expect from the cerftification exam, so I don’t know if the course is enough to prepare for it or if I need to add supplemental material. The course does recommend reading most of the AWS FAQs so I will do that in addition to finding and taking as many sample test as possible. In some ways, this feels a lot like the SATs I took almost 30 years ago.

To kickstart our cloud effort we had an AWS solutions architect and evangelist come to our offices for an immersion training session which lasted a day and a half. Going into these sessions I was hoping that we would come out with a good understanding of how we would architect our application. What I came away with was a better understanding of the breadth and depth of the services AWS has to offer but not a plan for how to piece them into an application. I felt like I had been given a tour of a gourmet kitchen, shown how to use a knife, turn on the stove, and sample a couple spices and then told to go make a meal.

I think our whole team came away with the understanding that there is a lot to learn and that we will certainly need some guidance in putting together a sound application architecture.

I’m a long time Java developer with years of J2EE-like application experience. The software I’ve worked on for the last 10+ years is deployed on JBoss into enterprises. We largely treat the application and applcation server as a single monolith that is installed via a typical installer. We have never treated the .ear file as a self-deployable entity and we have no development practices that support that type of deployment.

After a false start in 2014 we are again making the attempt to “take our application into the cloud.” In our first attempt, our team had a lot of misconceptions about what moving to the cloud meant. The most positive aspect of our current attempt is that we brought out some consultants from AWS for training and we can admit to ourselves that we really don’t know how to make the move.

I plan to document as much of our transition as I can and hope others can benefit from our good and bad experiences.