Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Tools for building your Startup on AWS
Similar to Tools for building your Startup on AWS (20)
Recently uploaded
Recently uploaded (20)
Tools for building your Startup on AWS
- 2. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Tools for Building your MVP onAWS Rob De Feo Startup Advocate youtube.com/RobDeFeo
- 3. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is an MVP?
- 4. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Reid Hoffman Co-Founder LinkedIn
- 5. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Minimum{x}Product Viable Usable Loveable Testable
- 6. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Product
- 7. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. W H A T W E ’ L L C O V E R Anti-patterns
- 8. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Development Iterations 1. 2. 3.
- 9. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Sprints Complete Uninterrupted Short
- 10. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Planning Low Impact Fast to Build Slow to build High Impact Focus Area DistractionUndifferentiated Break Down
- 11. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. MinimizeTaskSize One engineer can handle Adds incremental value Done in a single sprint Reducing scope removes ambiguity Easier to prioritize
- 12. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Standups 1 MinutePer Person Max 15 MinutesMax Every DayFirst Thing in the Morning EveryoneTech, Product, Marketing, Business
- 13. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. ContinuouslyShipReleases AWS CodeCommit AWS CodeBuild Third Party Tooling AWS CodeDeploy AWS CodePipeline AWS CodeStar Source Build Test Deploy
- 14. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. W H A T W E ’ L L C O V E R Anti-patterns
- 15. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Time Until Impact Roadmap Prioritization End of runway
- 16. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Roadmap Prioritization Time Until Impact End of runway
- 17. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. TechnicalDebtCost Time Absolute
- 18. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. TechnicalDebt Time Cost Relative Absolute
- 19. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Rigid Flexible Abstractions Easy Hard 1 System N Systems2 Systems
- 20. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. If you build it… You must maintain it
- 21. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. No infrastructure provisioning, no management Scale automatically Pay for value Highly available and secure Build Less,DeliverMore
- 22. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 80% Tracer Code Feature Primary Feature 85%90%
- 23. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Optimize for Learning Learn PrototypeExperiment
- 24. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. W H A T W E ’ L L C O V E R Anti-patterns
- 25. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Monolith Does everything Monoliths are OK
- 26. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Easiestwaytoget started Create larger instances Add attached block storage Load balance your application Connect to AWS services Networking & data transfer DNS management One static IP/instance Computing power
- 27. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Elastic Beanstalk Deploy andScaleMonolith Availability Zone 1 Availability Zone 2 Auto Scaling Group Amazon RDS (Master) Instances Amazon RDS (Slave) Elastic Load Balancing (ELB)
- 28. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Microservices Does one thing Microservices
- 29. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. BuildingYourAPIonAWS Amazon Cognito Web Amazon Simple Storage Service (S3)Amazon API Gateway Services AWS Lambda Any AWS Service Mobile AWS Fargate
- 30. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon CloudFront Mobile Web Amazon AuroraAWS AppSync Amazon Simple Storage Service (S3) Mobile Amazon Cognito Amazon DynamoDB Amazon Elasticsearch Service AWS Lambda AWS Amplify
- 31. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Static /SinglePageWeb
- 32. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Containers Amazon Elastic Container Service Amazon EC2 Container Registry AWS Elastic Beanstalk Amazon Elastic Container Service for Kubernetes AWS Fargate AWS App Mesh
- 33. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Analytics Mobile Web Amazon Kinesis Amazon Kinesis Data Firehose Amazon Simple Storage Service (S3) AWS LambdaAmazon Pinpoint Amazon Kinesis Data Analytics Amazon Elasticsearch Service Amazon CloudWatch Alarm Amazon API Gateway Amazon CloudFront Amazon Athena Amazon QuickSight
- 34. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. W H A T W E ’ L L C O V E R Anti-patterns
- 35. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Over invest where its difficult to change.
- 36. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Organizations AWS Key Management Service AWS CloudTrail Security AWS Systems Manager (Session Manager) AWS Secrets Manager (Parameter Store) AWS ShieldMFA tokenAWS Identity and Access Management Amazon Cognito AWS Certificate Manager Amazon CloudFront
- 37. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Integration Points Documentation Specification Tutorials Videos Quick Starts
- 38. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Relational Referential integrity, ACID transactions, schema- on-write Lift and shift, ERP, CRM, finance Aurora, RDS Key-value High throughput, low- latency reads and writes, endless scale Real-time bidding, shopping cart, social, product catalog, customer preferences DynamoDB Document Store documents and quickly access querying on any attribute Content management, personalization, mobile DocumentDB In-memory Query by key with microsecond latency Leaderboards, real-time analytics, caching ElastiCache Graph Quickly and easily create and navigate relationships between data Fraud detection, social networking, recommendation engine Neptune Time-series Collect, store, and process data sequenced by time IoT applications, event tracking Timestream Ledger Complete, immutable, and verifiable history of all changes to application data Systems of record, supply chain, health care, registrations, financial QLDB AWS Service(s) Common Use Cases DataModel andStore
- 39. Thank you! © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Rob De Feo youtube.com/RobDeFeo
Editor's Notes
- - Minimum viable product or MVP, this is the first product you build. - This is the product that gets your startup through the product market fit phase. - MVP is not a proto-type where typically you are testing a narrow part of the problem.
- You initial version should be minimal, if its not you have shipped it too late and taken too long to get user feedback. This quote provides a good guideline to when you should get your product in front of users. It should feel uncomfortable
- - Minimum viable product, sometimes referred to as Minimum viable/usable/loveable/testable product. - Each of these dimensions test something specific, often MVP is the generic term. - Viable: Completely new product and need to test multiple dimensions. - Usable: Optimizes for getting the product in customers hands early and getting feedback. - Lovable: Assumption is that existing products are disliked by customers. - Testable: Good for risky business assumptions e.g. AirBnb
- - MVP is not a customer facing term. - While your first customers are likely to early adopters, your product needs to work. - They are using it to solve an important problem for them. - The bounding of a product should be clear, it should have one core function and the minimum features that support that core function. - Don’t get distracted features outside of this scope
- Building your MVP is a process and having an accompanying development process will facilite that. Your development process should not be there to slow you down, its intentionally light and designed for high velocity iterations.
- - Product development is a process – the goal of this process is to help you build quickly. The aim of each iteration is to improve your product by a few percent. Incrementally giving value to your customers.
- - Each sprint should have a theme, be about one thing, and aim for delivering a useable release at the end of each sprint. - Complete: Sprints are bursts of work preceded by planning and followed by retrospective, the sprint contains every action and piece of work needed to deliver a feature. - Uninterrupted: Developers work without interruption. If you’re the CEO with an amazing new feature, your job is keep quite, you can change it all start of next sprint. Plus you will have more time to speak to users and get data to see if it is such a great idea. You can change it all at the beginning on the next sprint but not before. If you’re a developer your job is to deliver the work committed to and push back on an ything else. - Short: There is no fixed time on sprints. For all the reasons above and related to planning if you choosing between 2 durations pick the shorter option. 1 week sprints are ok. Fast delivery is motivating and rewarding.
- - Everything you do will seem important but you need to prioritize what gets done in each sprint. - Instinctively the easiest you look at the expected benefit and divide by expected development time. Order them and work through the list. This is good but has two problems. You wont have enough data to measure benefit in a reliable way, benefit is too often defined by revenue which is too early a metric for pre-product market fit. - Instead look at speed to implement and impact on your customers. Plotting this is fast and easy. It gets you most of the way there. the cut off line for speed, should be does it fit in a sprint for a single developer. The cut off line for impact is do you believe it will meaningfully change the metric you care about. Sections: Click Bottom right is tempting – but even if its quick to implement it has little value to your customers, you don’t need to do it. These will appear often in your planning sessions, don’t be tempted. Click Top right is obvious – you should ONLY do work that lives here Click Top left – This are big and important and you need to work on them. But you should only work on them after you break down the requirement. Make it minimal. Removing the hard and less impactful parts of the feature to move the task to the top right. Click Bottom Left – Avoid at all costs, this is the undifferentiated corner. Your users won’t see it. Too often I see startups building databases or other services that are not core to their business. Its probably already been built by someone. You have capacity to build probably 1 great product. Make sure it’s the right one. If you’re a startup building a database product then build the database and apply this thinking to everything else. Extra - When your in the middle of the process is easy more difficult that it looks, calibrate by retrospectively looking back on when you thought tasks were plotted vs the reality after you have some data.
- - If the feature does not fit in a sprint, change the feature not the process. Reducing big tasks, helps to get features that are valuable but too big to work on in one sprint. - Big features should be broken done in to smaller micro tasks, to incrementally give value. - Break the feature down and remove the hard and less important parts. - Micro tasks should be small enough that one engineer can get the work done in less that one sprint duration. The smaller the task size the easier it is to justify and fit in. Advantages: Smaller tasks are easier to prioritize. Ambiguous tasks are hard to deliver. Reducing the scope of a task removes ambiguity. Even if the feature is less complete you have something users can test earlier.
- Do them daily, standing up, ideally first thing in the morning before people get into their day. Everyone should be there, technical, product, marketing, business. Often tech is blocked by something that product/marketing/business can help solve by clarifying or removing a constraint. Max 1 min per person: what they did yesterday, what they are working on today, what they will do after, and importantly what they are stuck on. Use a stopwatch if needed. Max 15min total: if you can quickly resolve any issues that come up then do. Otherwise take blockers or other topics “offline”. If you are going over this time your team is too big or updates are not concise enough. Extra if you have remote teams there should be still some form of standups on video call, or if in different timezones be asyncrounous and use a messaging app
- Each sprint should end with a feature. You need to deploy it so you can get feedback from users. You should do this at the end of every sprint This momentum is important and you can see how users respond to your work. Use pull requests and a light continuous delivery. EXPLAIN – Codestar Extra: Your architecture can be built using CloudFormation or CDK which should sit along side your application code and your pipeline can also configure and provision AWS resources.
- Just as the early stages of building a business are unique compared to as a business grows. The same is true of technology you build early on. Here are a few anti patterns compared to when you are building in late stage startups or enterprise applications.
- - If you image that each dot represents a feature and the size of the dot is time it took to build it. - Too often startups are building features needed too far in the future....This doesn't work You are moving so fast in different directions that future you plan for now is not proven to materialize. Future planned work is usually bigger, meaning a disproportionate amount of your effort will take time if ever to return value. - The biggest problem is though that many features are built to return value after you have ran out of money.
- - Startups rarely fail because of software that could not scale due to meet the demand of too many users. Focus on features that your users are asking for. Build for 10x users you currently have. AWS will help you scale.
- - Technical debt is the build up of deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. - Technical debt is hard to avoid when moving fast especially in an early stage startup. - While its true that getting everything right at the beginning will reduce the work you need to do to improve and maintain in the future.
- - Treat technical debt in your MVP as an acceptable cost to moving quickly. - Its hard to avoid this exponential growth is tough on the technology that you are building especially if you are focusing on quickly delivering features. - While the absolute cost to remove technical debt is lower now in relative terms it could be your entire engineering working on this and not features. - The other reason not to worry is you will probably rebuild your core product many times over during the life of your startup.
- - When you know you’re going to need to eventually handle more than one type of a thing, consider generalizing. Imagine the opposite ends of the scale, building for exactly one system or building for any system, - Generalizing against any type of system is really hard problem to solve especially as you do not know of the different system yet. - Click Generalize..But just barely--make your system capable of handling two kinds of things. This will help you avoid too tightly coupling without having to be completely abstract. - Click As long as the systems are not too similar you will building a good amount of flexibility for the effort. Example: Take for example integrating payments systems, integrating against one only make your solution too rigid, against any system all over the world is really hard. 2 Payment providers is a good balance between flexibility and speed.
- Often it seems easy, fun, important to build it yourself. Especially at small scale, this approach does not scale well. Everything you build you will have to maintain. The growth of your business is likely to be due to the development of your product, not due to time spent building on undifferentiated heavy lifting. If you get your process correct, you have the capacity to build one great product. You need to focus on building YOUR product not building a backend service that already exists. Customers will care about YOUR product, not your underlying technology. Once you have a successful product your users love, as you grow you will have big interesting technical challenges. Extra: Saying no to building some is good. Too often startups are building something not because their customers need it but because their talented technical teams have the ability to build it. But lack the awareness to NOT build it.
- - The less you build the less you maintain, and you will be able to deliver more to your users. - Undifferentiated lifting is hard especially at scale, using services means you don't need to provision infrastructure or scale instances. - You can use AWS services to accelerate the speed of development and pay for the value you use. While having secure and highly available characteristics.
- There may be five or ten ways to use a feature, but there is usually one way that 80% of people will use it--the happy path, the shortest way to accomplish the main purpose. Build those first, and try to launch with just those. You will learn about the feature and how users use it, what you have built will then be production ready. Tracer code is not disposable, its production ready code. It contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. Its end to end. It simply is not fully functional. Extra: Sit customer down with your product and observe how they use it, this will give you the happy path.
- - You will build great technology, at this stage its best to focus on learning before optimizing technology. - Experiment often and liberally, use templates or online examples to experiment with services, products, and new technologies. The more you explore the space the better idea you will have of what works. - Know when to prototype. A distinction between prototype and MVP is that a prototype is an experiment to prove one thing. Its better to prototype out of your MVP. Its usually quicker and you don't need to write production code in your MVP. 2 example prototypes are: Looks like - Use mockups - To get feedback on design or user experience? Works like - Use templates, or sample code - To quickly see if something is possible - Extra: You may chose to use learning as the measure of impact when doing sprint planning.
- There are many different ways to build using AWS. While there are vitually no limits how services can be combined. These sample architecture cover many of the use cases we see when people are building their MVP. They can be used as a guideline to start and then expand as your product develops.
- Starting with a monolith is often the right choice, it allows for fast development at the early stage as you don’t need to design the process boundries ahead of time. A well designed monolith can be scaled horizontally and broken appart later if needed. Some startups will never outgrow the scaling capacity of a well designed monolith. Adding features to monolith’s is usually quick as there is one place it needs to be done.
- 2 twos of monolith can be easily be deployed with LightSail. Lightsail makes it easy to deploy these web sites like WordPress, Magento, Plesk, or Joomla. Web applications. Are deployed with pre-configured development stacks like LAMP, Nginx, MEAN and Node.js. to make it easy for you to get your web application online.
- Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS. You can upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time.
- Microservices are a great way to build and scale your applications when you understand the boundries between services. Each service is tasked with doing one thing and doing it well. That means you will design the service, infrastructure and data model for this specific use case. This is especially helpful if you expect a lot of load from users. Of as your development team grows, microservices are considered a way to keep your development velocity high. In a well designed microservices architecture if any individual microservice is not working then other parts of the application will still function. Although each service does one thing as a whole they combine to provide a full suite of functionality to users.
- Serverless is an easy way to build microservics from the outset. In this example architecture for building you API on AWS you can see how services are used in a microservices architecture. Request come from customers that have integrated with your product API Gateway routes traffic in this case to lambda CLICK You can extend this easily by building a web client, adding authentication with Cognito, and storing pre-processed responsed in S3 which API gateway can proxy too. CLICK Later you add a mobile client, deploying containers on Fargate or anyother container orchestration option. You can extend it futher by having API gateway route to any other AWS service. Extra: Each lambda or service can be thought of a microservice, you wont need to deal with scaling, only pay for useage and no servers to manage.
- Amplify framwork is an open source client framework, includes libraries, a CLI toolchain, and UI components. It integrates with the most relevant cloud services for mobile development A set of developer tools for building, testing, deploying, and hosting the entire app – frontend and backend You can easily start out building your mobile application and web front end. The website hosted on S3 with CloudFront to provide content devilery. AppSync presents a manged GraphQL endpoint to interact with your frontends and pulls data from Amazon Aurora. CLICK The can be extended by adding authentication with Cognito and additional data sources depending on your requirements such as dynamodb or elastic cache. Integation with Lambda allow for connecting to any external datasource - Broad support for the most popular OS platforms and frameworks - The Amplify Framework, an open source client framework, includes libraries, a CLI toolchain, and UI components - The CLI toolchain enables easy integration with Cloud Services such as Amazon Cognito, AWS AppSync, and Amazon Pinpoint - Developer Tools for building, testing, deploying, and hosting the entire app – frontend and backend
- An alternatice method of deploying a static web or single page application is with Amplify Console AWS Amplify Console supports common Single Page App (SPA) frameworks (e.g. React, Angular, Vue.js, Ionic, Ember), Static-site generators like Gatsby, Eleventy, Hugo, VuePress, and Jekyll. Works with Git and create development environments There are 3 easy steps: 1. Connect your repository 2. Configure build settings 3. Deploy your app
- Docker has is ubiquitous in development, particually in microservices. AWS has multi container services for working with docker: If you are developing a monolith in docker, elastic beanstalk provides a simple way to deploy and scale. ECS and EKS allow for running container orchestration services on AWS that deploy and scale your containers. Fargate make it possible to run containers without having to manage any under lying servers. ECR is a contrainer registery for storing your containers so they can be easily deployed. App Mesh is a service mesh that provides application-level networking to make it easy for your services to communicate with each other across multiple types of compute infrastructure.
- When injesting large amounts of data or building analytics products it’s advisable to build architecture that is specific to that task. In this example you start out by collecting events from your web and mobile applications that are sent to kinesis which in turn uses kinesis firehose to store the events in S3. CLICK next you add more logs such as API gateway and CloudFront access logs and and use Athena to query the data. Quicksight can be used to present dashboards or send weekly updates via email of key metrics. CLICK Later you can use specialized stores for specific data types such as Elastic Search, or Kinesis Analytics which gives realtime analytics over the streaming data. Cloudwatch can be used to trigger notifications and take automated actions. Pinpoint helps you engage with your customers by sending them email, SMS, and push notification campaigns Extra: The first step in this architecture is the most important, if you store data and logs you can easily delete them if you realise they are not needed but you can’t query what you didn’t store
- Software can be rebuilt and often is but it’s a lengthly process. There a specific class of decisions that are important to get right at the beginning.
- Some of the decisions you will make now will stick around for a long time. Know when a decision is a one way or two way door. The follow are some important ares that warrant investing time upfront as they are for different reasons hard to change.
- With AWS cloud you can be as secure as the most security sensitive organisations is the world by taking advantages of the many security controls and services. Web applications: Using cognito, certificate manager, and cloufront gives, secure user authentication, SSL, and DDOS protection via Shield. With IAM enables you to manage access to AWS services and resources securely, using MFA for a additional level of secuirtiy. Paramater store you can securely store secrets you applications needs ensure that only your application has access to sensitive information. Sheild is managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. Session Manager you can have secure access to EC2 instances with all activity logged. When working with enterprises or regulated industries services such as: Cloud trail enables governance, compliance, operational auditing, and risk auditing of your AWS account Key Management Service (KMS) makes it easy for you to create and manage keys and control the use of encryption across a wide range of AWS services and in your applications. Organizations helps you to centrally manage billing; control access, compliance, and security; and share resources across your AWS accounts Extra: having a data classification helps to demonstrate how you will store and manage data at different levels of sensitivity.
- Early adopters will try your product, but they will not be able to full use it, understand how it works under specific conditions or explain it clearly to others without details documentation. When your product exposes and API this is more important still, there are specialsed tools for defining your API, resources, verbs, inputs and outputs. OpenAPI is a specification that allows you to describe your API with documentation first. Even you don’t expect external customers to integrate with your API. These same reasons are valid for your internal purposes. Tutorials are useful ways to show people how to use your product especially if it has new features. Videos are an engaging way to demo your product. Quickstarst help get your first users up and running quickly so they can try out your product. These all help to scale the adoption of your MVP Extra: Its very difficult for developers to integrate with your API without documentation. You can share you API spec even before your have built anything with your early users. They can give you feedback and start integrating against mock endpoints. Extra: Include versioning in the API specification to allow you the possibility to upgrade in the future if needed.
- Data choices last longer than many other so the extra time you put in to this pays off. First think of your data model, how the entities relate to each other and how this data will be read and used in the future. Select the correct datastore for the access patterns (read/write ratio), durability, security, cost and availability requirements. Selecting the correct datastore for your application is important, take the time to consider the above and the use cases. This table will help you to make this choice. If you are building a monolith or familiar with relation databases then RDS or Aurora with Elastic cache infront is suitable for a large number of applications. Microservices SHOULD have one data store for each service, its easier to define the characteristics for the datamodel and key value or document stores are often good fits. For more specialized use cases, look at Nepute for graph databases, Timestream for time series data or QLDB for a ledger.
- Thank you can call to action to start building your MVP.