saas startups - software engineering challenges
TRANSCRIPT
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
You are here because,● 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
This talk is about...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?“
This talk is NOT 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)?
SaaS
● A software delivery 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
Clo
ud s
tack
Startups● Early stage of 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
SaaS startups● A startup that delivers Software as a Service● Melbourne - one of the best startup hubs in world● A good probability to start / work for a startup
Some of the challenges● Scalability● Isolation● Security● Limited resources● Software Provisioning● Compliance requirements
Scalability● Vertical and horizontal 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
Scalability > Stateless applications● 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
Scalability > Public APIs● 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
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
Resource isolation● Multi-tenancy is a key characteristic in SaaS● Sharing underlying resources● Economies of scale● Noisy neighbours● Privacy● Application isolation● Data isolation
❏ CPU❏ Memory❏ Disk❏ Network
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
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
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
Security● SaaS is essentially 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
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
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
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
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
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.
Pricing solutions● Pay as 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/
Compliance requirements● Customers of tenants● Privacy issues● Data locality issues● Terms and Conditions
○ Legal issues○ Professional advice
● Strong encryption mechanisms from the start● PCI compliance
○ www.pcisecuritystandards.org
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
● Need to be 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
Other ● Do not unnecessarily 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
Conclusions● Be aware of 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
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/