Technologies for startup
•Download as PPTX, PDF•
0 likes•137 views
Technologies for startup
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Technologies for startup
Similar to Technologies for startup (20)
More from Dzung Nguyen
Recently uploaded
Recently uploaded (20)
Technologies for startup
- 1. Technologies for startup nguyphadzu Hanoi - June 2021
- 2. Agenda 1. Startup overview 2. Product life cycle 3. Technologies for startup
- 3. What is startup A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty. — ERIC RIES, THE LEAN STARTUP [RIES 2011A, 27] A startup is a company designed to grow fast. Being newly founded does not in itself make a company a startup. Nor is it necessary for a startup to work on technology, or take venture funding, or have some sort of “exit.” The only essential thing is growth. Everything else we associate with start- ups follows from growth. — PAUL GRAHAM, CO-FOUNDER OF Y COMBINATOR A tech startup is an organization with the following characteristics: 1. Product: technology. 2. Environment: extremely uncertain. 3. Goal: massive growth. 4. Mode of operation: search.
- 5. Work at a startup Why you should? - More opportunities - More ownership - More fun Why you should not? - Not glamorous: a startup is 99.9% hard, unglamorous work - Sacrifice - Probably won’t get rich: 75% fail - Joining vs Founding: 10x Life can be much broader once you discover one simple fact: Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use. Once you learn that, you’ll never be the same again. — STEVE JOBS
- 7. Product life cycle with user centered design (*) (Book)User Centered System Design: New Perspectives on Human-computer Interaction
- 8. Product led growth model
- 10. Tech stack Golden rule A good tech stack is one that scales faster than the people required to maintain it.
- 11. Evolving the tech stack - Go with what you and your team are familiar with - Implement incrementalism for evolvement
- 12. In-house vs. buy vs. open-source Build in-house Buy commercial Open-source - Pros: - Full control - Cons: - Heavy cost: developer time for maintenance and evolve the apps - No community - Hard to find company to use knowledge in developers' career. - Pros: - Save developer time (one company dedicated for a product) - Community of customers - Cons: - Lose control of your biz - Depend on your provider → take more cost - Vendor lock-in (migrate to a different tech can be very difficult). - Pros: - Benefits of commercial products - Community of developers - Developers can reuse knowledge later - Cons: - Mostly done on a volunteer basis → hard to get a specific bug fixed … - Don’t entirely control, but be able to mitigate some of that risk.
- 13. Technologies should never be built 1. Security: cryptography, password storage, credit card storage. 2. Web technologies: HTTP servers, server-side and client-side frameworks. 3. Data systems: databases, NoSQL stores, caches, message queues. 4. Software delivery: version control, build systems, deployment automation. 5. CS 101: basic data structures (map, list, set), sorting algorithms. 6. Libraries for common data formats: XML, HTML, CSV, JSON, URLs. 7. Utility libraries: date/time manipulation, string manipulation, logging. 8. Operating systems. 9. Programming languages.
- 14. Recap of tech solutions For a startup, using open source is usually the best choice, closely followed by using a commercial product. Building infrastructure in-house should be treated as a last resort that you use only when you have no other options.
- 15. Picking a programming language (1) Programming paradigms 1. Object oriented programming - Model the world as objects—that is, data structures that package together both data and behavior - Map nicely onto the real world of nouns and verbs - Two main problems: no consensus on what “object oriented” really means or how to do it correctly; most OOP languages encourage the use of mutable state and side effects → harder to reason about, maintain, and test code, especially in concurrent environments - Java, C#, C++ ... 1. Functional programming - Model the world as the evaluation of functions and significantly limit the use of mutable data and side effects. - Why not popular? steep learning curve, functional programming is removed from the real world/ moves away from the underlying hardware architecture (it uses recursion instead of loops, immutable data instead of mutable data, garbage collection instead of manual memory management, lazy evaluation instead of eager evaluation → there are ways to fix it but it makes more burdens for programmer) - Haskell, Clojure, F# ...
- 16. Picking a programming language (2) Problem fit In theory, all modern programming languages are Turing complete, so they are all equivalent. In practice, certain types of problems are much easier to solve in some programming languages than others The community around the language has a significant impact on problem fit. Performance The programming language is usually not the bottleneck for most companies. The two most common performance bottlenecks in programming languages are garbage collection and concurrency. Garbage collection, as we discussed in the programming paradigms section, consumes CPU and memory and can pause program execution. Some garbage collection algorithms are more mature and tunable than others. With concurrency, the most important factors are what concurrency constructs are supported by the language and how it handles I/O. Productivity Programmer performance is a bigger bottleneck for most startups Productivity consists of two main aspects: how much existing code you can reuse and how fast you can create new code. The amount of existing code is determined by the popularity of the language and the size of its community. How fast you can create new code depends on three factors: experience, feedback loop ( how long it takes to see the effect of a code change, expressiveness of the language (how many lines of code it takes to implement any given idea) When you choose a language, you’re choosing more than a set of technical trade-offs—you’re choosing a community. Over time the community builds up around the language—not only the people,
- 17. Picking a programming language (3) Here are the key trade-offs to consider when evaluating a programming language: 1. Programming paradigms: Is it an object-oriented or functional programming language? Does it support static typing or automatic memory management? 2. Problem fit: For example, C is particularly good for embedded systems, Erlang for fault-tolerant distributed systems, and R for statistics. 3. Performance: How does the language handle concurrency? Does the language use garbage collection and how tunable is the collector? 4. Productivity: How popular is the language? How many frameworks and libraries are available for it? How concise is it?
- 18. Picking a server side framework (1) The biggest driving factor for picking a framework is the size of the community around it, as it affects your ability to hire, find learning resources, and leverage open source libraries and plugins. Here are some of the most popular and mature frameworks, broken down by programming language and ordered alphabetically, based on HotFrameworks: 1. C#: .NET 2. Clojure: Ring, Compojure, Hoplon 3. Go: Revel, Gorilla 4. Groovy: Grails 5. Haskell: Snap, Happstack, Scotty 6. Java: Spring, Play Framework, DropWizard, JSF, Struts 7. JavaScript: express.js, sails.js, derby.js, geddy.js, koa, kraken.js, meteor 8. Perl: Mojolicious, Catalyst, Dancer 9. PHP: Laravel, Phalcon, Symfony, CakePHP, Yii, Zend 10. Python: Django, Flask 11. Ruby: Ruby on Rails, Sinatra 12. Scala: Play Framework, Spray You can quickly cut this list down by applying three filters: programming language, problem fit, and scalability.
- 19. Picking a server side framework (2) Here are the key trade-offs to consider when evaluating a server-side framework: 1. Problem fit: For example, Rails is particularly good for CRUD applications, DropWizard for RESTful API servers, and Node.js for real-time webapps. 2. Data layer: Does the framework help you manipulate URLs, JSON, and XML? 3. View layer: Are there many built-in templating helpers? Does it use server- side or client-side rendering? Does it allow logic or is it logic-less? 4. Testing: Is it easy to write unit tests for apps built on top of the framework? Is the framework itself well-tested? 5. Scalability: Does the framework use blocking or non-blocking I/O? Have you benchmarked the framework with your use cases? 6. Deployment: Do you know how to integrate the framework into your build? Do you know how to configure, deploy, and monitor it in production? 7. Security: Is there an built-in, well-tested way with the framework to handle authentication, CSRF, code injection, and security advisories?
- 20. Picking a database (1) - When picking a data store, the most important consideration is maturity. - Relational databases should be the default option for any data storage decision. Start by modeling your problem with a relational database and see how far you can get before you run into walls. - If you do hit a wall with a relational database, it will most likely be because your data volume and availability requirements have exceeded the capacity of a single server. At this point, your priority is to identify the simplest solution that will scale. In order of increasing complexity, here are the most common options: 1. Optimize the data storage format and queries on your existing database. 2. Set up a cache in front of the database (e.g. memcached). 3. Setup master-slave replication. 4. Vertically partition unrelated tables. 5. Horizontally partition a single table. 6. Setup multi-master replication. - There are two trends to watch out for in the future. The first trend is the NoSQL ecosystem becoming more mature. The second trend is the emergence of NewSQL databases, which are data stores designed to run on a cluster while still supporting the relational model
- 21. Picking a database (2) Here are the key trade-offs to consider when evaluating a database: 1. Database type: Is it a relational database or a NoSQL store (key-value store, document store, column-oriented database, or graph database)? 2. Reading data: Do you need to look up data by primary key or secondary key? Do you need JOINs? How do you map the data into an in-memory representation? 3. Writing data: Do your writes update just a single aggregate or many? Do you need atomic updates or transactions? 4. Schemas: Is the schema stored explicitly in the database or implicitly in your application code? Is your data uniform or unstructured? 5. Scalability: Can you get by with just vertically scaling your database? If not, does the database support replication, partitioning, or both? 6. Failure modes: How many different ways can the system fail? How easy are the failures to debug? 7. Maturity: For how long has this database been in development? How many companies are using it? How rich is the ecosystem of supporting tools?
- 22. Software engineering at startup - Test-driven development - Document continuously - Active stakeholder participation - Iteration modeling - Prioritization
- 23. References 1. Business model canvas generation 2. Balance scorecard 3. Hello, startup 4. Technology as a patterns 5. Disciplined Agile delivery 6. The art of scalability 7. Scalability patterns
Editor's Notes
- Speed of iteration
- There’s a big difference between building a business and solving interesting engineering problems. There are interesting engineering problems in startups, but very frequently, your business will not succeed or fail based on how well you solve those engineering problems. The exception to this is startups focused on hard scientific problems. For example, I have a friend who has a battery company and his business will succeed or fail based on the scientific breakthroughs they make, as well as how well they run the business. This hard science component is not applicable to 99% of web startups; most web startups succeed or fail based almost entirely on execution, meaning marketing, sales, product, and engineering. We think as engineers that if we can write great code and build something that can scale to a million people that we will be successful and lauded in the community and people will say, “oh, you’re so amazing”, and they’ll want to acqui-hire us for millions of dollars. That’s what we read in TechCrunch and that’s what we hear about at meetups, but it is very very far from reality. Many developers have trouble transitioning from a coding role to a leadership role, such as CEO, CTO, or VP. If you’ve never had such a role, you might expect that being part of the executive team will make you feel important, respec- ted, and powerful. You imagine yourself spending all your time drawing up strategies, giving orders, and moving chess pieces around a board, like a five star general. In reality, you’ll be more of a salesman crossed with a psychiatrist. You’ll spend a lot of time trying to get someone, anyone, anywhere, to care about your company. You’ll also spend lots of time listening to your employees, trying to figure out their needs, dealing with their complaints, and figuring out how to motivate them. You will get to make decisions, but many of them will be painful, risky, and unpopular. And no matter how much you try, you’ll get some of these decisions wrong. Some people thrive in this sort of environment, but if you’re not one of them, a leadership role might not be for you. Some people manage it better than others, but working at a young startup often means you won’t get to see your friends and family as much as you might like and your health may suffer. Startups have ruined marriages, caused mental and physical health problems, and worst of all, even driven some founders to suicide As a founder, you will have to make 10x the sacrifice in exchange for a chance at 10x the reward
- Build the product market fit: 1.Determine your target customer 2.Identify underserved needs of that customer 3.Define your value proposition 4.Specify your minimum viable product (MVP) feature set 5.Develop your MVP 6.Test your MVP with customers Boyd’s Law: speed of iteration beats quality of iteration. It’s a surprising law, but it makes sense when you’re dealing with complicated, unpredictable, and often chaotic systems.
- Putting it all together, if you get the right idea, design, data, and distribution, you’ll be able to make something people want. • An idea is not a design • A design is not a prototype • A prototype is not a program • A program is not a product • A product is not a business • A business is not profits • Profits are not an exit • And an exit is not happiness.
- A tech stack is a tool. It’s a means to build a product, not an end in and of itself. Do not pick a technology because it sounds cool or looks fun Your goal is to be able to scale your tech stack—scale it to more users, more traffic, more data, and more code—by throwing money or hardware at the problem, and not people. If every time your user base doubles, you can just pay for a few more servers and everything keeps working, you’re in good shape. A great example of leverage is the Whatsapp team, which built a tech stack around Erlang that could support 70 million Erlang messages per second, 450 million users, 50 billion messages per day, and 7.2 trillion messages per year.1 And they did this all with a team of just 32 engineers.
- In fact, there is no “best” tech stack. Picking a technology without considering the type of product, the team, and the company culture is like deciding what furniture to buy before you’ve bought a house, set a budget, or figured out who you are going to live with. Context matters. How do you pick the initial tech stack for a startup? Go with what you know. LinkedIn was built with Java because the founding team knew Java; GitHub’s founders were all Ruby developers, so they built the site with Ruby; Twitter used Rails primarily because they had a lot of early employees who were familiar with it; Foursquare started out in PHP because that’s what co-founder Dennis Crowley knew; Pinterest used Python because the founding team was familiar with it It can be fun to learn a new technology that promises all sorts of theoretical benefits, but your goal in the early days of a startup is to learn what your users want, and anything that takes time away from that is a waste. During those early days, your product has few users and little code, so scalability will not be much of a challenge, and all that matters is that you can iterate as quickly as possible. LinkedIn was going through a period of hyper- growth, both in terms of site traffic and the number of employees, and the infrastructure was buckling under the load. I was part of the service infrastructure team and we knew they had to make some significant changes to be able to scale the tech stack to the rapidly growing demands. Presented slide shows the incremental steps LinkedIn followed to arrive at this decision and how they performed the actual migration, including what would happen at each stage of the project if it succeeded or why it would be worth doing even if it was canceled.
- There are certain technologies that are so complicated, error-prone, and time consuming to build yourself, and solved so well in the open source or commercial world that, as a startup, you should never build them yourself. The only reason you would ever build one of these systems from scratch is either a) you’re using it as a personal side project for learning or b) your startup has extremely unique requirements for one of these technologies. The latter case is uncommon.
- For a startup, using open source is usually the best choice, closely followed by using a commercial product. Building infrastructure in-house should be treated as a last resort that you use only when you have no other options. This can be hard to remember, as many developers get excited at the chance to build a complicated piece of infrastructure, and will be quick to claim that no existing technology fits their needs. But given that there are more than 10 million open source repositories to choose from, and developer time is the most scarce and expensive resource at a startup, you cannot afford to spend time reinventing the wheel when there is an off-the-shelf solution readily available.
- The programming language is often the first technical decision you’ll make at a company. It’s also the one that has the most influence on all the other decisions. The “go with what you know” principle means that most startups initially use whatever language the founders know best. However, as a startup grows and evolves, it’s not uncommon to introduce other languages.
- Languages with strong metaprogramming capabilities, such as Clojure and Ruby, make it easy to define custom DSLs. Erlang is particularly effective at building fault tolerant, distributed systems. Assembly and C are usually your only options for low level, real time, or embedded systems. C++ and Python have a huge number of Computer Vision libraries. Matlab, Mathematica, and R come with comprehensive libraries for math, graphing, and statistics. PHP, Ruby, Python, JavaScript, and Java have vast eco- systems of libraries and frameworks for building web applications. For certain problem domains, picking the right language can give you a huge productivity boost because a lot of the code is already written for you. For example, the JVM is well known for having one of the better garbage collectors in the world, while the Ruby VM’s garbage collector is known for numerous performance problems.7 However, neither language can compare performance-wise to languages where there is no garbage collection. If your application cannot tolerate any GC pauses or any CPU or memory overhead, then you may want to use a language with manual memory management, such as C or C++. With concurrency, the most important factors are what concurrency constructs are supported by the language and how it handles I/O. For example, Ruby supports threads, but it has a Global Interpreter Lock (GIL), which means that only one thread at a time can execute. Moreover, most popular Ruby libraries perform synchronous I/O, blocking the thread while waiting for a disk read or a network call to return. The result is that Ruby is not an efficient language for dealing with lots of concurrency. There are workarounds, such as running multiple Ruby processes (e.g. one per CPU core), using non-blocking libraries (e.g. EventMachine), or using a different VM (e.g. JRuby), but they all involve trade-offs and overheads. This is one of the reasons Twitter moved off of Ruby and onto the JVM. The JVM has full support for multithreading with no global interpreter lock. It also has full support for non-blocking I/O and a variety of concurrency constructs, including threads & locks, Futures, Actors, and Software Transactional Memory. The move from Ruby to Scala helped Twitter reduce search latencies by 3x and CPU usage by half Popular languages will have more learning resources, more people you can hire who already know the language, and more open source libraries you can use. Mature languages also come with an ecosystem of productivity tools, such as IDEs, profilers, static analysis tools, and build systems. The more code you reuse, the less you have to write and maintain yourself. Although there are hundreds of programming languages to choose from, there are only a handful of languages that are mature enough and have a large enough community to make them viable choices for a startup. Here is the list as of 2015, ordered alphabetically, based on programming language popularity indexes (TIOBE, LangPop, and RedMonk), the StackOverflow Developer Survey: 1. C family (C, C++, C#) 2. Go 3. Groovy 4. Haskell 5. Java 6. JavaScript 7. Lisp family (e.g. Clojure or Scheme) 8. Perl 9. PHP 10. Python 11. Ruby 12. Scala You can quickly shorten this list by applying three filters: problem fit, programming paradigm, and performance requirements. For example, a startup building computer vision and machine learning systems would limit this list to just three languages based on problem fit: C++, Java, and Python. If that startup preferred static typing, they would knock Python off the list. Finally, if they were building a high performance, real-time system, they would not be able to use garbage collection, so they would be left with C++. If after applying the first three filters, you still have multiple languages to choose from, you should pick the language that makes you the most productive. For example, a startup that is building web applications will most likely find that Java, JavaScript, PHP, Python, Ruby, and Scala are the best fit for this problem. If the team prefers dynamic typing, they might remove Java and Scala from the list. And if a few of them already know Python and found a few Django plugins that will save them lots of time, then Python will be their best choice.
- If your team prefers writing everything in Java, your options are Spring, Play Framework, DropWizard, JSF, Struts. If your goal is to build a RESTful API server, Spring, Play Framework, and DropWizard will be the best fit. And if you know this app will be I/O bound, the non-blocking I/O model of Play Framework makes it the best choice. If after the first three filters, you still have several options, then it’s a ques- tion of picking the framework that best fits your deployment, security require- ments, data, templating, and testing needs.
- Active Stakeholder Participation. Stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques. Good recipe for product excellence overall: 1) Craft missions that everyone in the organization believes in and tie to company goals . 2) Don’t let everyone solve the same mission but ensure anyone who owns a mission can act in any way to make an impact – don’t silo them to a specific code base, platform, or feature/view set. Otherwise, they will try to solve the goal but only with resources at disposal, or only by exerting pixels they can control. 3) Organize agile teams around missions – they inherit goals but can focus on unique tactics. However, you don’t really want a bunch of teams coming up with a cacophony of goals. Companies need to have priorities. Similarly, you don’t want a lot of top-down “here’s what you need to do” – that stifles innovation. 4) Finally, if you don’t have clear goals and each team invents their own goals you have a disaster so remember to spend time ensuring people understand the goals and if need be pin those goals up and over-emphasize them at all hands and in written or video communication.
- Need to insert hyperlink