Download as PDF, PPTX
![Public API design concerns, e.g., URIs
● Tenant independent URIs [api.myapp.com/v1/resource]
○ Clean URI, Common documentation
○ Need some way to identify tenant, e.g., oAuth, headers
○ Issues with caching in proxy
● Tenant specific subdomain [tenant1.myapp.com/v1/resource]
○ Possible to have service level as well as tenant level cookies
○ DNS provisioning overhead (if manual)
○ Wildcard SSL certificates
● Tenant specific URI [api.myapp.com/v1/tenant1/resource]
○ More RESTful
○ Simple to implement](https://image.slidesharecdn.com/saasstartups5-161216120134/85/SaaS-startups-Software-Engineering-Challenges-22-320.jpg)
Uploaded byMalinda Kapuruge
SaaS startups - Software Engineering Challenges
The document discusses the engineering challenges faced by SaaS startups, emphasizing issues such as scalability, security, resource limitations, and compliance requirements. It highlights the importance of understanding these challenges to better prepare software engineers for startup environments and suggests various strategies for managing them. The speaker encourages research into solutions and learning new technologies while navigating the unique constraints of early-stage businesses.
More Related Content
Similar to SaaS startups - Software Engineering Challenges
SaaS startups - Software Engineering Challenges
- 1. SaaS startups Software EngineeringChallenges Dr. Malinda Kapuruge Deakin University - 16/12/16
- 2. Who am I? ● Malinda Kapuruge (Kau) ● A Senior Software Engineer ● An avid reader about SaaS delivery model ● Currently work at a SaaS Startup ● Previous: Zendesk, DiUS, Swinburne, WSO2 kaushalye kaushalye kaushalye kaushalye
- 3. You are herebecause, ● Have an idea for a SaaS application, possibly a startup ● Potentially working for a SaaS startup once graduated ● Curious to know the challenges in the field ● Have no clue how I ended up here
- 4. This talk isabout... The engineering challenges faced by a business in its infancy (startup) that delivers Software as a Service. “As a Software Engineer how do I better prepare myself to find solutions to such challenges?“
- 5. This talk isNOT about... ● How to evaluate the business opportunity? ● How to get funding $$$ (self-funded / crowdsourcing / venture capital)? ● Any good mentors? ● How to promote my business? ● Why startups fail? ● How to find a suitable place for my startup in Melbourne (ask me later)?
- 6. Engineering point ofview (Obviously, challenged by the business)
- 7. SaaS ● A softwaredelivery method ● Multi-tenancy ● On-demand Self service ● Centrally managed ● Network-based access ● Pay per use (time, #users, #features) SaaS (for software users) PaaS (for developers) IaaS (for SysAdmins) SaaS layer Shared resources tenants users Cloudstack
- 8. Startups ● Early stageof business ● Innovative product ● Success is not guaranteed ○ 37% for Information Technology* ● Usually a small team ● Limited ○ funding ○ resources ● Shared workplace ● Have to be ready for exponential growth * http://www.statisticbrain.com/startup-failure-by-industry
- 9.
- 10.
- 11. SaaS startups ● Astartup that delivers Software as a Service ● Melbourne - one of the best startup hubs in world ● A good probability to start / work for a startup
- 12.
- 13.
- 15.
- 16.
- 17.
- 18. Some of thechallenges ● Scalability ● Isolation ● Security ● Limited resources ● Software Provisioning ● Compliance requirements
- 19. Scalability ● Vertical andhorizontal scalability ○ Vertical: Increasing resources for an instance ○ Horizontal: Increasing the number of instances ● Using a PaaS vs IaaS ○ E.g., Deploying app Heroku or Architecting the app on AWS. ● Time to scale ● Stateless applications ● Public APIs
- 20. Scalability > Statelessapplications ● Stateless by design ● Application does not hold / remember state ● Start, stop, clone ● Requests could be routed to different processors ● Scalability, Elasticity, Performance and Reliability ● Complements Containerised architecture and virtualization
- 21. Scalability > PublicAPIs ● Go RESTful ○ Easy to understand ○ Kinda norm these days ● Why? ○ Do not have resources to develop extra features that the tenant needs ○ Slightly varying tenant specific requirements ● Provide better flexibility for tenants ● Use via UI or via API (or use both) UI API UI SaaS
- 22. Public API designconcerns, e.g., URIs ● Tenant independent URIs [api.myapp.com/v1/resource] ○ Clean URI, Common documentation ○ Need some way to identify tenant, e.g., oAuth, headers ○ Issues with caching in proxy ● Tenant specific subdomain [tenant1.myapp.com/v1/resource] ○ Possible to have service level as well as tenant level cookies ○ DNS provisioning overhead (if manual) ○ Wildcard SSL certificates ● Tenant specific URI [api.myapp.com/v1/tenant1/resource] ○ More RESTful ○ Simple to implement
- 23. Resource isolation ● Multi-tenancyis a key characteristic in SaaS ● Sharing underlying resources ● Economies of scale ● Noisy neighbours ● Privacy ● Application isolation ● Data isolation ❏ CPU ❏ Memory ❏ Disk ❏ Network
- 24. Resource isolation >Application level ● Eating my resources ● More like a IaaS layer concern than SaaS ○ Choice of Cloud technology ○ Configurabile strategies ● Isolation strategy? ○ Physical machine ○ VM ○ Container ● Design the application to avoid errors ○ Tenant accounts ○ Users of tenants ○ Threads ○ Queues
- 25. Resource isolation >Data level ● Different schema for different tenants? ○ Varying requirements of tenants ○ Impact on other tenants ● Sharding ○ Horizontal partitioning of tables ○ Each shard in a separate instance ○ Improved performance and scalability ● Co-locating data ○ Data of the same tenant in the same physical hardware ○ Avoids network traffic ○ Faster join operations ● No-SQL ○ Data structure vary between tenants ○ Partial updates
- 26. Resource isolation >Data - Example strategies (#1) Separate DB instances for each tenant ● Suitable for small number of tenants with large number of users/transactions ● Because Contract / SLA ● Better data isolation ● High resource consumption (#2) Shared instance and schema but use tenant specific identifier ● Very easy to implement ● Suitable for large number of small tenants ● Poor data isolation ● Better resource consumption (#3) Same database but different schemas for each tenant ● A mid-way approach compared to #1 and #3 ● Better isolation than #2 ● Better resource consumption than #1
- 27. Security ● SaaS isessentially a web application ● Common threats e.g., ○ Cross-site scripting (XSS), Untrusted data ○ Broken Authentication, Compromised session tokens ○ Cross-Site Request Forgery (CSRF), use browser to perform an unintended operation on another website ● Security breaches are costly to the business ● Strict web application security practices ○ Tokenization ○ SSL ○ Session timeouts ● Seek help from third party security assessors ○ Penetration testing ○ Vulnerability assessment
- 28. Limited resources >Dev effort ● Focus on what you do ○ E.g., my primary business is invoicing. ○ Should I use an existing email notification service? ○ OR Write my own? ● Available options? ○ Do your research to compare the pros and cons ○ Time well-spent ● Look for ○ Flexible pricing models ○ Vendor-lockin issues ○ Scalability (Peak loads) ○ Quality of API, SDK (Reduce development effort and errors) ○ Security vulnerabilities ○ Customer service SaaS layer
- 29. Limited resources >Quality assurance ● Lack of QA staff (may be zero) ○ Lack of quality in Software ○ Competitors ○ Customer satisfaction ● Outsourcing solutions ○ BugWolf ○ 99Tests ● Automated Testing tools ○ TestingBot ○ SauceLabs ○ BrowserStack
- 30. Software provisioning >Understanding agile ● Thinking MVP (minimum viable product) ○ The role of Software Engineer ○ To measure the complexity of delivering different features. ● Feature dependency analysis (technical perspective) ○ Feature X depends on Feature Y ○ Feature X can be better implemented if Feature Y is present ○ Feature X can be better designed based on the feedback of Feature ○ Co-existence of Feature X and Feature Y can cause issues ● Customizability ○ Quick customization to try out market segment ○ Quick demo to show to a potential investors ○ Sandbox environments
- 31. Software provisioning >Build pipeline ● Time to release a feature ● Plan -> Design -> Develop -> QA -> Deploy ● Software in the hand of users ● Feedback loop ● Slower the time to deliver -> slower the feedback ● Identifying bottlenecks ● Repeatable and reliable
- 32. Software Provisioning >Platform / Infrastructure ● PaaS or IaaS ? ● PaaS: e.g., Heroku, Openshift, Engine yard ● IaaS: e.g., AWS, Azure, Digital Ocean ● Do not try to reinvent the wheel, unless absolute necessity ● Go cheap. Spend money as you grow. E.g., Heroku dynos Need a Demo Free dyno 512 MB RAM. $0/month. Sleeps after 30 mins inactivity Have to Deploy MVP Hobby dyno 512 MB RAM. $7/month. After 1 year - High traffic Performance-L dyno 2.5-14 GB RAM. $500/month.
- 33. Pricing solutions ● Payas you go ● Subscriptions ● Separate pricing model from application logic ● Flexibility to change, self-service. ● Additional features, such as coupons, email notifications ● Merchant accounts ● Payment gateways vs 3rd party processors ○ 3rd party processors are less expensive in short term but could be expensive in long term ○ http://www.paymentgatewayaustralia.com/
- 34. Compliance requirements ● Customersof tenants ● Privacy issues ● Data locality issues ● Terms and Conditions ○ Legal issues ○ Professional advice ● Strong encryption mechanisms from the start ● PCI compliance ○ www.pcisecuritystandards.org
- 35. Compliance requirements >E.g., PCI - DSS ● Pay per use is an inherent SaaS characteristic ○ Collecting and storing credit card information ● PCI - DSS (Payment Card Industry - Data Security Standard) ○ A Self-assessment Questionnaire*, e.g., SAQ A-EP ● Levels of merchants ○ Level 1: more than 6 million tx / annum ○ Level 2: 1 to 6 million tx / annum ○ Level 3: 20k to 1 million tx / annum ○ Level 4: upto 20k tx / annum ● Perhaps too late when assessed ○ Penalties ($5,000 to $500,000) ○ Loss of business ($$$$) ● Pay attention when choosing deployment platforms * www.pcisecuritystandards.org
- 36. ● Need tobe introduced very early stages of app / MVP ● Drive design solutions ○ Only 20% of tenants have more than 500 users ○ Only 1% of the users clicked on the feedback survey link ● Understanding usage patterns ○ Tenants ○ Users ● Collected Data -> Another business? ● Use Tools ○ Google analytics ○ MixPanel ○ AWS CloudWatch Analytics
- 37. Other ● Do notunnecessarily restrict the system ○ Currently support only Australian phone numbers ○ Are we unnecessarily restricting ourselves to specific market segment / geographical area? ● Identifying performance bottlenecks ○ Overprovisioning resources ○ Optimizations ○ Saved money could be used elsewhere ● Study competitors ○ Myth: Not my task as a Software Engineer ● Do not hesitate to question the business ○ Myth: Not my task as a Software Engineer
- 38. Conclusions ● Be awareof these challenges ● Research solutions ● Learn new technologies ● Startups -> Limited resources -> Develop strategies ● Compromise. You have to. ● Managing tech debt vs feature push ● Complement business goals: 3 months -> 6 months -> 1 year
- 39.
- 40. References ● http://www.cloudcomputingpatterns.org/software_as_a_service/ ● https://www.owasp.org ●https://startupaus.org/ ● https://www.pcisecuritystandards.org/ ● https://startupvictoria.com.au/ ● https://www.startupmuster.com/