SaaS startupsSoftware Engineering Challenges

Dr. Malinda Kapuruge

Deakin University - 16/12/16

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

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

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

Startups

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

Reasons

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

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

Sources of challenges

Your own success...

Environment changes

Limited budget

Time

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

ThanksAny Questions

?

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/