Scenario - creating a highly available campaign site for loungebeer.com
The course is part of these learning paths
In this group of live videos, we tackle a practical scenario to help you learn real-world cloud consulting skills.
This is a unique and engaging live video format where we join the Cloud Academy AWS, Azure, and Google Cloud Platform teams in a real-time work situation. The team listen to a customer brief, discuss and define technical requirements and then evaluate which of the public cloud platforms could best deliver on the customer requirements.
From this course, you will learn how cloud professionals go about solving real-world business problems with cloud solutions.
With this course, you will learn how cloud professionals tackle and solve a business problem with each of the three public cloud platforms. This course is highly recommended for anyone interested in learning how to become a cloud architect, specialist or consultant!
Learning how to use your cloud skills in real-world situations is an important skill for a cloud professional. Real life projects require you to be able to evaluate requirements, define priorities and use your knowledge of cloud services to come up with recommendations and designs that can best meet customers' requirements. As a cloud professional you often have to think on your feet, process information quickly and be able to demonstrate design ideas quickly and efficiently.
In this course, we work through a customer scenario that will help you learn how to approach and solve a business problems with a cloud solution. The scenario requires us to build a highly available campaign site for an online competition run by loungebeer.com - a "craft" beer launching a new product in to the market at the US Superbowl event.
In these interactive discussions we join the team as they evaluate the business requirements, define the project constraints, and agree the scope and deliverables for the solution. We then work through the technical requirements we will use to evaluate how each of the three cloud platforms - Google Cloud Platform, AWS and Microsoft Azure - could be used to meet the technical requirements.
We follow each of the platform teams as they define solution architectures for Google Cloud Platform, AWS and Microsoft Azure. We then regroup to run a feature and price comparison before the team builds a proof of concept for our solution design.
This group of lectures will prepare you for thinking and reacting quickly, prioritzing requirements, discussing design ideas and coming up with cloud design solutions.
02/2018 - DynamoDB now supports encryption at rest so that would potentially influence our choice of database in thie scenario
For planning tools see
For more information on White Listing see
- [Lecturer] Prioritization is an important skill to master as a Cloud Ninja. So, let me step through the tools I'm using with John, for this brief, so you can use them if you get into similar situations. Now, cloud services allow you to do more, and so people are going to expect you to perform miracles as a Cloud Ninja. Now, you can't perform miracles, but these tools can make it easier for you to get your stakeholders to open the gates and get you more of a particular resource, perhaps a time extension, or a budget increase. So, having these simple frameworks in your toolkit is going to make your life easier. The two simple tools I'm using are the Iron Triangle and the MoSCoW method. Now, these are two simple, agile tools that can make it easy for you to agree an outcome with your stakeholders. Stakeholders usually want the project to succeed just as much as you do, and the Iron Triangle and the MoSCoW method can help us all arrive at a common start point. Now, projects need to be performed and delivered under certain constraints. The Iron Triangle is a visual model of the core constraints of project management. It is a graphic aide where the three attributes shown on the corners of the triangle are shown in opposition, time, cost, and features. Most importantly, one side of the triangle cannot be changed without affecting the other two. Now, this is really useful when you need to intentionally choose a project bias with a customer, or a customer representative, or if you need to re-analyze the goals of a project. I use it to illustrate what the impact of one corner changing will have on the other two corners, i.e., if you want to get something done faster, then it's going to cost more or we need to drop some features. So, if John hears back from the customer that the data needs to be encrypted or that they must have a reporting dashboard, then those features are going to change either the time corner of four weeks, or the cost corner of 20K. Now, the second tool we use is the MoSCoW method, and the MoSCoW method is a feature prioritization technique used to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. Now, you can use this simple technique in a number of ways, and there's no right way of doing it. I like to use it to limit scope and to reduce feature creep with non-technical stakeholders. I use it in conjunction with a version two bucket. So, things that get pushed out of the must-have list, go into our next iteration. So customers feel better about leaving something out, right now, if they know it can be included later. Now, you can also use this to help shuffle features around when you're talking to technical teams with your product backlog. Now the must-have features are those required for our minimal, viable product. The should-haves are those features that are important but not vital to the MVP. So, it may be painful to leave them out, but the solution is still viable without them. Now, the could-haves are those wanted or desirable but least important and they have less impact, if left out, compared to a should-have. Now, the most important one is the would-haves or the won't-have-this-time. The won't-haves are the ones we agree with stakeholders to be the least critical, lowest payback items, or just simply not appropriate, at this time. So, as a result, the won't-have requirements are not planned into the schedule for a delivery time box. The won't-have requirements are either dropped or reconsidered for inclusive in later time boxes, i.e., our version two. So, for our project, here's how it's looking. The must-have requirement is zero downtime. The should-have feature is data encryption at rest. The could-have is monitoring, and the would-have, or won't have this time, hopefully, is dashboarding to show how the campaign is performing during that short, brief moment when it's running. So, if John needs to add dashboarding, well, yes, we can do it, but that's going to cost more. Why? Well, we can't move the date of the Super Bowl. So, that four week time constraint is fixed. So, the time constraint can't change, so the cost corner will need to change if we include dashboarding as must-have for John's customer. Now, it's never easy going back and saying that it will cost more, but, as a Cloud Ninja, you need to master the corners and stay firm on the straights. Yes, the customer can have a particular feature, but they will need to fund any additional resource or accept any change to the timeline first. Now, it's very important you agree this upfront with the customer. So, if there is any change to any of those corners, it's something that you do collaboratively. Make sure you don't just absorb any change in the hope that it's gonna get done, make the customer happy. If this is a charity job, forget everything I've just said. But, if you are running a commercial project, use these tools so that you can be fair and firm and prosper, okay? Agreeing expectations is the most important part of any project. You get this part right, upfront, and every other decision becomes easy. Okay, let's get back to the brief.
Head of Content
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.