Today still a lot of service offerings are sold by a flat-rate "all you can eat" subscription model. That’s simple to understand and simple to implement. But is it the right way to sell services? Especially if you could split off add-ons? When you watch companies growing in the cloud you see that tweaking your offering and finding the right business model becomes vital for building a successful business. We have enabled companies in on-premise scenarios to achieve this during the last 25 years. As we have been moving into the cloud and started offering this flexibility to cloud companies (or yet to become cloud companies) we have gone through rebuilding our system for the cloud in the right way. In this talk we want to share with you lessons learnt from building our cloud service. We’ll start off with some fundamental properties of distributed systems and will analyze the impact on the offering. We’ll look at the requirements for such system and will build an architecture to these requirements by including the fundamental mechanics of the cloud. By taking care of the CAP-theorem we’ll find the right decision to adapt the classical scenarios to the cloud.

1. Cloud Provisioning
Building an efficient System in the Cloud
Michael “MiZu” Zunke
CTO SRM, Safenet

2. Agenda
What is the thing to move to the cloud?
Cloud – What‘s different?
– Design Criteria
Our Framework
Details
Recap: Lessons learnt

3. Software Monetization – Classic Product
On-Premise
Copy Protection
Products
Orders / Entitlement /
Production / Activation
Licensing
Tracking
Reporting
End-User Admin

4. Parallels
On-Premise Cloud
Copy Protection Authentication
Products Service Catalog
Orders / Entitlement / Provisioning, Contract,
Production / Activation & Entitlements
Licensing Authorization
Usage Tracking &
Tracking
Billing Mediation
Reporting Monitoring & Reporting
End-User Monitoring
End-User Admin
& Management

5. Some background
The CAP Theorem
Consistency
Partitioning
Availability
Tolerance

6. Eventually Consistent
“Real internet systems are a careful mixture of
Consistency and Availability subsystems”
- Dr. Eric Brewer
Professor, UC Berkley, Co- founder Inktomi
“Eventually Consistent - Building reliable
distributed systems at a worldwide scale demands
trade-offs between consistency and availability”
- Werner Vogels, CTO Amazon.com

7. Checking Cloud Compatibility
License Models / Authorization
• Category 1
• Quasi stateless / autonomous - harmless
• Perpetual
• Expiry date
• Category 2
• Asynchronous - mostly harmless
• Post paid
• Category 3
• Synchronous - strict consistency!!
• Max Concurrent Use
• Depleating

8. Conclusions for our Problem Domain
Some Classic License Models do not SCALE
- Problem: require a globally limited Resource
- This inherently requires STRICT CONSISTENCY!
Classic case for „we always did it like this“ meets
cloud.
Going cloud is not only a technical challenge!
It can require change in offering because of
technology

9. So what did we do?
Work with business owner to find the right solution
Apply what we learnt before – explore how weak
consistency can help.

10. Converting…
Map to Eventually Consistent Approach
No sharp Cut-Off in distributed license resource data!
• Eventually consistent means no strict limits can get
guaranteed. Some ‘over usage’ might happen.
• In case strict limits are required, you will have to accept
slower response times and greater impact on disconnects.
Strict consistency leads to reduced QoS for the end-user.

11. Paradigms of our Cloud Architecture
No Delay!
speed, bandwidth & reaction time of service must not suffer just
because the service is licensed/tracked.
Effects of “slowness”
Amazon: 100 ms delay caused a 1% drop in revenue.
Google: 400 ms delay caused a 0.59% decrease in search requests per user.
Yahoo!: 400 ms delay caused a 5-9% decrease in traffic.
see e.g. http://goo.gl/ADQuR
Autonomous nodes - Local intelligent
caching!

12. Paradigms of our Cloud Architecture
Scale with the customer!
No additional infrastructure because of licensing system.
Stateless modules
Plug into each platform!

13. Sentinel™ Cloud Services in action

14. Sentinel™ Cloud Services in action

15. Sentinel™ Cloud Services in action

16. Sentinel™ Cloud Services in action

17. Sentinel™ Cloud Services in action

18. Sentinel™ Cloud Services in action

19. in Detail
Client Node
- Feature X, TTLx - Login Event
- Feature Y, TTLy - Logout Event
Authenticate
AuthMap Session
Directory
EMS SCC Service
Data Engine
Provision
Contract
Data
Store
Data
Store
Amazon EC2

20. Key Take Aways
Distributed systems require different thinking
• Connections are not granted
• Autonomous components help
Moving to the cloud might have impact on what you
can deliver
• Your cloud offering might have to be different from the classic
• Work with your business owner to get this straight early
Existing Customers might need to be educated
• Customer expectations are driven by what they know
• You might have to lead them thru the same process

21. Questions?
http://sentinelcloud.com

22. References
CAP Theorem
http://goo.gl/37dms - Nice intro from Julian Browne
Eventually consistent
http://goo.gl/yTCpW - Good starting point for consistency
considerations. Blogpost from W. Vogels, CTO Amazon
Google’s timing experiments / WPO
http://goo.gl/ADQuR

23. Cloud Provisioning
Building an efficient System in the Cloud
Michael “MiZu” Zunke
CTO SRM, Safenet