Software-as-a-Service has become a very popular software delivery method due to its inherent advantages to both the service provider and the consumer. Startups are emerging businesses that usually provide innovative products to win a market share. In the recent past there are many Information Technology startups adopt SaaS as a way to quickly deliver their products to customers. This talk is discusses the software engineering challenges in a SaaS startup environment, so that software practitioners those who do not have experience in such an environment can foresee what to be expected.

1. SaaS startups
Software Engineering Challenges
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 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

4. 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?“

5. 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)?

6. Engineering point of view
(Obviously, challenged by the business)

7. 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
Cloudstack

8. 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

9. Startups
https://www.startupmuster.com/Startup-Muster-2015-Report.pdf

10. Reasons
https://www.startupmuster.com/Startup-Muster-2015-Report.pdf

11. 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

12. Sources of challenges

13. Your own success...

15. Environment changes

16. Limited budget

17. Time

18. Some of the challenges
● Scalability
● Isolation
● Security
● Limited resources
● Software Provisioning
● Compliance requirements

19. 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

20. 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

21. 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

22. 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

23. 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

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 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

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
● 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/

34. 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

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 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

37. 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

38. 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

39. Thanks
Any Questions
?

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/