The more I work with AWS the more I’m willing to base the next phase of my career on it. The breadth of technologies and the use cases where they are applicable are so varied that I don’t see how you could avoid them in a software development career.

The development model that I’ve worked in for the past 15 years has been the on premise web application server managed by IT. I honestly don’t see any future in it. Of course those systems will continue to exist as do COBOL systems, but new development and new types of software will come from a space where customers don’t deploy and manage your software but simply use it.

I continue to study the various AWS white papers and my co-worker. who passed the Solutions Architect Associate exam, was kind enough to let me borrow her copy of AWS Certified Solutions Architect Official Study Guide: Associate Exam. The Cloud Guru course that I wrote about was good, but since I haven’t taken the exam I’m not sure that a video course is enough so I’m going through the Amazon exam preparation guidelines.

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.