A day in the life of a Quickstarter!

[mwhittington]

*Alfresco Content Services (ACS) is no longer using AWS Quick Start for deployments on AWS. We recommend Amazon EKS as the new reference deployment for ACS on AWS - read the following blog post from our Product Manager Harry Peek to learn more: https://www.alfresco.com/blogs/digital-transformation/alfresco-embraces-amazon-eks*

During my time at Alfresco I have worked on several projects. The most exciting ones have been any that have involved the usage of AWS and the wealth of services they have to offer.

AWS have a set of products called Quickstarts. These are a collection of reference architectures that allow any business with an AWS account to "quickly" start with a particular product. These products are offerings from the Quickstart community that contribute. For example there are Quickstarts for Chef, Docker, Git and others.

Alfresco currently has a Quickstart for Alfresco Content Services. This allows the end user to deploy a CloudFormation template, the AWS technology used to deploy an ACS environment in your own AWS account, in under 45 minutes. Once complete, and license permitting, there will be an ACS cluster ready to use. A deployment that may typically have taken days and weeks to manually complete now only takes minutes, all because of the power of AWS.

Having recently worked on both the Alfresco Content Services Quickstart and another Quickstart we are developing internally (watch this space) I'd like to share my thoughts about the process in general and describe a day in the life of a Quickstarter.

Firstly, understanding what you want to build is key. Obviously. But what I mean by this is making sure that you ask yourselves the right questions; What are the underlying resources needed to complete your deployment? Do you need to offer a secure network? Secure access to any resources deployed? If these are a resounding yes, then AWS offer some free templates that you can use to help "layer" your infrastructure so you can concentrate on coding the product and higher-level infrastructure you may want to deploy.

We at Alfresco always try to ensure that any Quickstart we offer now and in the future is secure and "production" ready. There's no reason why the Alfresco Content Services Quickstart shouldn't be used in production. The template can be downloaded, extended and deployed by anyone.

Once you have identified what you want to build, next is the proposal. The AWS Quickstart team are ready to hear about what you want to build. Following their guidelines, we:

1. Proposed a Quickstart. They review and agree or push back for more information.
2. Start development. This happens in parallel to the proposal. Removing bottlenecks is key.
3. Internal testing. We need to ensure that the Quickstart we are building is reliable and repeatable. It builds in the same way each and ever time we deploy it in our own AWS accounts.
4. Submit a code review. The AWS Quickstart team will create a git repo ready for the code to be reviewed. 

Some simplified steps there, but some of these steps can take weeks. What I have learnt and discovered with my most recent project is:

• Networking. I don't mean CIDR's, I mean people. It's been a great opportunity to network internally and externally with individuals who I may never have done unless I was working on a Quickstart. Talking with the AWS team and learning from them has been invaluable and has helped me grow as a developer.
• Product development. This is the most important point I want to impress on you, the reader. When developing your own Quickstart, try and make sure you utilise as many AWS resources as possible. For example; rather than install MySQL or another equivalent on an EC2 instance use RDS or Dynamo, instead of storing files locally store them on S3, rather than storing your session state locally use RDS or ElastiCache. If your product can't talk to these services or has hard-coded limitations then its time to take a look at your product to make it more "cloud-aware".
• Communication. Make sure at every step you talk to the wider audiences within your organisations to keep them in the loop. Do not assume people know what you are doing and why. The quicker you can receive feedback from technical and non-technical people the better your first iteration of your Quickstart will be.
• Documentation. We cant forget this can we? A Deployment Guide is required for each and every Quickstart. This needs to be thorough, tested and well written. Its just as important if not more so than the Quickstart itself. Its the enabler for your users. Potentially, each and every Quickstart of yours that is deployed is a new customer. The guide needs to hit the ground running.

Thanks for reading!