Tools for Building your MVP on AWS
•
4 likes•1,225 views
Speaker: Alejandra Novack, Developer Relations, Amazon Web Services Early stage startups are time and resource constrained and they need to quickly get to product market fit. In this session you’ll get an overview of how startups build MVPs using services like Amazon API Gateway, AWS Amplify, AWS Lambda, Amazon EKS, Amazon Lightsail, and database options. After this session, you’ll be able to pick the right technologies and use pre-configured architectures to speed up your development.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Tools for Building your MVP on AWS
Similar to Tools for Building your MVP on AWS (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Tools for Building your MVP on AWS
- 1. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Tools for Building your MVP onAWS Alejandra Olvera-Novack AWS Developer Relations Amazon Web Services
- 2. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Mobile Q&A | Submit Your Questions Online Open a browser on any laptop, tablet, or smartphone Go to slido.com Enter the event code: STARTUP Don’t have a question? View the submitted questions and upvote your favorites.
- 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. Whatis aSprint?
- 10. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Sprints Complete Uninterrupted Short
- 11. © 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
- 12. © 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
- 13. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Whatis aStandup?
- 14. © 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
- 15. © 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
- 16. © 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
- 17. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Time Until Impact Roadmap Prioritization End of runway
- 18. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Roadmap Prioritization Time Until Impact End of runway
- 19. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. TechnicalDebtCost Time Absolute
- 20. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. TechnicalDebt Time Cost Relative Absolute
- 21. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. CheckoutCodeLingo forTechnicalDebt codelingo.io
- 22. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Rigid Flexible Abstractions Easy Hard 1 System N Systems2 Systems
- 23. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. If you build it… You must maintain it
- 24. © 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
- 25. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. TheHappyPath
- 26. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Optimize for Learning Learn PrototypeExperiment
- 27. © 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
- 28. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Monolith Does everything Monoliths are OK
- 29. © 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
- 30. © 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)
- 31. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Microservices Does one thing Microservices
- 32. © 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
- 33. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon CloudFront Mobile Web Amazon AuroraAWS AppSync Amazon Simple Storage Service (S3) Frontend Amazon Cognito Amazon DynamoDB Amazon Elasticsearch Service AWS Lambda AWS Amplify
- 34. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. FullStackServerlessApps/StaticApps/SPA
- 35. © 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
- 36. © 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
- 37. © 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
- 38. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Over invest where its difficult to change.
- 39. © 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
- 40. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Integration Points Documentation Specification Tutorials Videos Quick Starts
- 41. © 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
- 42. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Mobile Q&A | Submit Your Questions Online Open a browser on any laptop, tablet, or smartphone Go to slido.com Enter the event code: STARTUP Don’t have a question? View the submitted questions and upvote your favorites.
- 43. Thank you! © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Alejandra Olvera-Novack @quetzalliale for Twitter
- 44. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
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, a prototype is something you might create to see if your idea is feasible or to help you find the happy path for UX for your users or to just get a visual on what you have in your head. This is typically the minimum number of features/build out you need to test your overall hypothesis Lyft was trying to see if peer-to-peer transportation would work! So the minimum amount of features they would need to test their hypothesis is: (1) a driver to be able to sign up and login, (2) a rider to be able to sign up and login, (3) a rider to be able to request a driver, (4) a driver to be able to find that rider, (5) and then some form of payment to be exchanged between the 2 parties If LYFT had included in their MVP other features such as “sharing your ride on social media” or “add a stop” …that would have been “overbuilding”
- 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 If you are a perfectionist, it’s good to have someone on your team that is not to push you to release before your ready.
- - 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 by features outside of this scope
- Building your MVP is a process and having an accompanying development process will facilitate 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.
- - A plan or agenda for the next 1-2 weeks… and you decide what you plan to build within that timespan. - You have to separate your product out into sprints, so that things get done.
- Each sprint should have a theme, be about one thing, and aim for delivering a usable 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 quiet, 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 anything 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. Sometimes things change really fast so shorter sprints are better.
- Everything you do will seem important but you need to prioritize what gets done in each sprint. What is the best way to do that? - 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, break up the feature into parts. 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. - 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.
- A meeting that happens usually once a day between the dev team and sometimes a PM or member of the business team. You discuss what’s .. Blocking you, What task you’re working on, What you think you’re going to accomplish in the next week
- 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 time zones be asynchronous and use a messaging app like Slack or even by creating Trello cards with your updates. Stand up should be any blockers I have, what I’m working on currently, any questions I have for discussion
- 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. --What I’m showing you here are a bunch of AWS services that help you develop what’s called a continuous delivery pipeline. Allowing your developers to continuously deliver their new code to your production product.. Or the beta version of it… or whatever one your testers are testing with. EXPLAIN – CodeCommit: this is where your code lives, you may already be familiar with GitHub or BitBucket CodeBuild: this builds your code, so if you have a language or framework that you’re building in that needs to compile before it gets released… CodeBuild will do that for you You may choose to use Third Party Tooling to run all the tests for your code… And then CodeDeploy just deploys your code .. CodePipeline will help you set up the entire pipeline and all the steps your product needs to take before it gets released. CodeStar: this one will create the code pipeline for you from your existing code base… so if you’re just starting out and don’t have anything set up yet.. We recommend CodeStar because it will setup everything for you. 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. Sometimes you build features that your customers don’t even end up using or wanting, I would call this an overbuild. If you’re trying to make your product perfect and have too many features right up at the front, it’s not an MVP.
- - Startups rarely fail because of software that could not scale due to meeting the demand of too many users. Focus on features that your users are asking for. Build for 10x users you currently have. Don’t worry so much about scale, because that’s rarely why startups fail.. Plus remember that AWS takes care of that for you.
- 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. The reality is technical debt is going to happen because you’re moving so fast. - 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. I rebuilt mine completely 3 times in the course of 2 years. A cool startup that we met from Australia is actually trying to prevent technical debt in an automated way using machine learning just integrates with your Github repo and checks to make sure the code checked in follow the tenents of your code base. It’s called CodeLingo and I believe it’s free right now so a great way to try and prevent technical debt early on.
- When you know you’re going to need to eventually handle more than one type of a thing, consider generalizing when possible. 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 code to upload an image, maybe you don’t know if later on you will need to upload videos, maybe build the ability to upload either. Doing this while you’re in it is far less extra effort than going back and refactoring the code to handle more than one media type.
- Often it seems easy, fun, important to just 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. Saying no can be difficult but you have to stand strong.
- - The less you build the less you maintain, and you will be able to deliver more to your users. - Undifferentiated heavy 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. 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. It’s 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 their happy path and most likely the happy path of others.
- - 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 with your UX or feasibility. 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 virtually no limits how services can be combined and there a lot of services. 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 could be the right choice, it allows for fast development at the early stage as you don’t need to design the process boundaries ahead of time. So a monolith means it’s all just 1 system, right? Adding features to monolith’s is usually quick as there is one place it needs to be done. A well designed monolith can be scaled horizontally and broken apart later if needed. Some startups will never outgrow the scaling capacity of a well designed monolith.
- Monoliths can be easily be deployed with LightSail. Lightsail also makes it easy to deploy web sites using frameworks 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 boundaries between services. EXAMPLE – Think of a shopping site .. If the cart functionality suddenly stops working, it won’t affect other features such as login. Each of them live separately in the code base. 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 early on. Also 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 microservices from the outset. In this example architecture for building your 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 responses in S3 which API gateway can proxy too. CLICK Later you add a mobile client, deploying containers on Fargate or any other container orchestration option. You can extend it further by having API gateway route to any other AWS service. App mesh can also help you manage all your microservices even if they are using different compute options Extra: Each lambda or service can be thought of a microservice, you wont need to deal with scaling, only pay for usage and no servers to manage.
- Amplify framework 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 delivery. AppSync presents a managed 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. Integration with Lambda allow for connecting to any external data source - 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 alternative 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
- Containers are a form of operating system virtualization. A single container might be used to run anything from a small microservice or software process to a larger application. Inside a container are all the necessary executables, binary code, libraries, and configuration files. Docker is a great tool you can use to aid in the development of containers…Docker will package everything up for you into something called an IMAGE, and then that IMAGE is what runs inside of a container. That IMAGE contains all software tools needed to run the code. Docker has become particularly popular in the development of microservices. AWS has multi container services for working with docker: 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 underlying servers we sometimes call it serverless containers serverless meaning no infra to manage. ECR is a container registry 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 ingesting 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 real-time 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 realize 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 lengthy 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 areas 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 organizations is the world by taking advantages of the many security controls and services. Web applications: Using cognito, certificate manager, and cloudfront 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 security. Parameter store you can securely store secrets you applications needs ensure that only your application has access to sensitive information. Shield 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 fully use it, understand how it works under specific conditions or explain it clearly to others without detailed documentation. When your product exposes an API to software developers, this is now extremely important, there are specialized tools for defining your API, resources, 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. Swagger is the name associated with the widely used tools for implementing the the OpenAPI specification and our services integrate with swagger to help you maintain your documentation and keep your API up to date. 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. Quickstart 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 decisions you’ll make so the extra time you put into 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 in front 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 data model and key value or document stores are often good fits. For more specialized use cases, look at Neptune for graph databases, Timestream for time series data or QLDB for a ledger.
- Thank you can call to action to start building your MVP.